Subject | Re: [ib-support] Re: Slow connection..It's a bug...... |
---|---|
Author | Helen Borrie |
Post date | 2002-06-11T16:02:19Z |
At 04:57 PM 11-06-02 +0200, you wrote:
**never** observed it, not in IB 5.6, not in IB 6.x, nor in any of the
Firebird builds. The issue I'm aware of with the IB local client on
Windows is that it's not thread-safe.
Using the following setups I have sub-second connection speeds in all cases
with Firebird 1.0. The Windows server is NT SP 6a running on a slowish
Celeron (434 MHz, 384Mb), the Linux server is RedHat 7.2 on a 850Mhz AMD
Duron, 512 Mb.
1. Delphi application using TIBODatabase, local connection (protocol
cpLocal, path y:\gdb_6\ibobase\ibobase.gdb)
2. Same application using TIBODatabase in Kylix, connecting with cpTCP_IP
to localhost:/data/ibobase/ibobase.gdb (copy of same database running on Linux)
3. IB_SQL (uses native IBO IB_Connection) connecting to local server by
local loopback, cpTCP_IP, path dev:y:\gdb_6\ibobase\ibobase.gdb
4. Another instance of same, simultaneously.
5 and 6, two more instances of 3 & 4, this time with localhost as server.
And the same across the network in either direction - IBO-Kylix client to
Windows server, Windows client to Linux server.
There's nothing special about these server setups, except that I have loads
of temp space configured; and the NT machine has two large chunks of
pagfile.sys configured on separate physical disks. I have SMB running on
the Linux box for convenience, although I wouldn't do that under production
conditions. Looking at my NT taskbar right now, I have two large WinHelp
files open, I'm running Delphi 6, Eudora, I'm connected to my dialup ISP, I
have 4 instances of IB_SQL, MSN Messenger and a graphics program.
I'm sure you guys are looking at configuration and/or environment problems
- or maybe your servers just don't have enough "grunt" to take all those
instances of gds32.dll, local or loopback client connections competing with
the server and the database cache for resources.
Also, make sure you have zapped IPX/SX from your protocol stack.
Are there any multi-processors involved? Is your database server serving
other applications?
If you are using IBO, do you have GetServerDefaults or schema caching
activated? That will slow down the initial connection (or the only
connection, if it is one connection per client), since that involves
network traffic and/or disk i/o, before the connection makes itself visible
to the actual application.
If you are using a lot of table components for your applications and are
opening them all in your FormCreate, then that will dog your connection
time, too.
heLen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________
>hello,I don't believe this "Slow connection...It's a bug..." thing. I've
>i have the same problem, its horrible ....
>
>A connection to the firebird 1.0 database can need 10 seconds, only the
>connect!
>i have a user named p.e.: xuser, and all my clients connect with xuser and
>his password ...
>i use: IBODatabase
>
>with following:
>
>CharSet = WIN1252
>server = xserver
>path = d:\xxxxx.gdb
>pagesize = 8192 (the same, as the db is created)
>
>the rest is standard, as IBOdatabse it gives ....
>then the time between: database.connected:= true, and the result could range
>from
>2 till more as 10 seconds, this is very courisoly ...
>
>(in the beta 2 Firebird release (last before 1.0) i don't have this problem)
**never** observed it, not in IB 5.6, not in IB 6.x, nor in any of the
Firebird builds. The issue I'm aware of with the IB local client on
Windows is that it's not thread-safe.
Using the following setups I have sub-second connection speeds in all cases
with Firebird 1.0. The Windows server is NT SP 6a running on a slowish
Celeron (434 MHz, 384Mb), the Linux server is RedHat 7.2 on a 850Mhz AMD
Duron, 512 Mb.
1. Delphi application using TIBODatabase, local connection (protocol
cpLocal, path y:\gdb_6\ibobase\ibobase.gdb)
2. Same application using TIBODatabase in Kylix, connecting with cpTCP_IP
to localhost:/data/ibobase/ibobase.gdb (copy of same database running on Linux)
3. IB_SQL (uses native IBO IB_Connection) connecting to local server by
local loopback, cpTCP_IP, path dev:y:\gdb_6\ibobase\ibobase.gdb
4. Another instance of same, simultaneously.
5 and 6, two more instances of 3 & 4, this time with localhost as server.
And the same across the network in either direction - IBO-Kylix client to
Windows server, Windows client to Linux server.
There's nothing special about these server setups, except that I have loads
of temp space configured; and the NT machine has two large chunks of
pagfile.sys configured on separate physical disks. I have SMB running on
the Linux box for convenience, although I wouldn't do that under production
conditions. Looking at my NT taskbar right now, I have two large WinHelp
files open, I'm running Delphi 6, Eudora, I'm connected to my dialup ISP, I
have 4 instances of IB_SQL, MSN Messenger and a graphics program.
I'm sure you guys are looking at configuration and/or environment problems
- or maybe your servers just don't have enough "grunt" to take all those
instances of gds32.dll, local or loopback client connections competing with
the server and the database cache for resources.
Also, make sure you have zapped IPX/SX from your protocol stack.
Are there any multi-processors involved? Is your database server serving
other applications?
If you are using IBO, do you have GetServerDefaults or schema caching
activated? That will slow down the initial connection (or the only
connection, if it is one connection per client), since that involves
network traffic and/or disk i/o, before the connection makes itself visible
to the actual application.
If you are using a lot of table components for your applications and are
opening them all in your FormCreate, then that will dog your connection
time, too.
heLen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________