| Subject | Re: [firebird-support] Firebird fast on one machine (2 seconds) - slow on another (> 2 hours) |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2011-01-21T23:44:50Z |
On 1/21/2011 2:40 PM, drjimwalsh1 wrote:
systems.
fbserver.exe is the "superserver" which handles multiple connections
that share a cache. By default that cache is quite large
fb_inet_server.exe is the "classic" version in which each connection
is a separate process. When running locally, the connection is made
by the actual client process. When handling remote connections, each
new connection starts a copy of fb_inet_server on the system with the
database. The fb_inet_servers don't share caches. So at the very
least, that system is running in a tcp/ip local loopback, and each
connection has a small cache.
Second, even that doesn't explain the difference between ~2 seconds and
~2 hours. It's possible that the slow system is missing some (all?)
indexes or that the indexes are inactive. Query RDB$INDICES to see
if the expected indexes are present and activated.
Good luck,
Ann
By the way, classic can be a very good solution in some cases,
especially on a multi-processor system. The superserver is
multi-threaded but runs only one thread at a time to avoid
interlocking data structures ... well also because it was
designed at a time when multi-processors were out of favor.
>First, you're running two different types of Firebird on the two
> On machine A, the time from when I launch the app until the time that the results appear in the 3 grids is around 2 seconds, almost instantaneous.
> Firebird server: version 2.1 (fbserver.exe version 2.1.3.18185)
> Firebird ODBC driver: version 2.00.00.148
>
> On machine B, the time to complete that same task takes over 2 hours.
> Firebird server: version 2.5 (fb_inet_server.exe ver 2.5.0.26074)
> Firebird ODBC driver: version 2.00.00.150
>
systems.
fbserver.exe is the "superserver" which handles multiple connections
that share a cache. By default that cache is quite large
fb_inet_server.exe is the "classic" version in which each connection
is a separate process. When running locally, the connection is made
by the actual client process. When handling remote connections, each
new connection starts a copy of fb_inet_server on the system with the
database. The fb_inet_servers don't share caches. So at the very
least, that system is running in a tcp/ip local loopback, and each
connection has a small cache.
Second, even that doesn't explain the difference between ~2 seconds and
~2 hours. It's possible that the slow system is missing some (all?)
indexes or that the indexes are inactive. Query RDB$INDICES to see
if the expected indexes are present and activated.
Good luck,
Ann
By the way, classic can be a very good solution in some cases,
especially on a multi-processor system. The superserver is
multi-threaded but runs only one thread at a time to avoid
interlocking data structures ... well also because it was
designed at a time when multi-processors were out of favor.