| Subject | Throttling on Intel network cards slowing Firebird down |
|---|---|
| Author | Maya Opperman |
| Post date | 2010-09-15T08:16:43Z |
Hi,
(Forgive me for lack of info here, but I will try to explain as best I can, with what I know, as this is second hand information)
We had a site where just one of our app's functions, on just one of the client machine's was very slow. The rest were all fine.
After no luck resolving the problem ourselves, we had a technical person go out to the site, and they found some kind of a setting on the Intel network card's driver to throttle the speed, if there was too many connections. The card was apparently using the default setting.
Technical person's explanation of the problem:
"I never came across this problem before in all my years . Basically the client spawns many network requests to the server is individual requests, closing the connection and opening it again. This is almost like a connection per line of data. Somehow you need to change the behaviour to stop it opening and closing a connection for each line of data being request and rather keep using the same connection. This will reduce network overhead and most likely improve performance. "
Question
What I am trying to find out (so I can address the issue) is, is this:
- a network card problem (ie. a bad choice of network card?)
- a firebird design problem? (an upgrade to a newer firebird version perhaps?)
- a firebird settings / configuration problem?
- a problem with the component set I am using? (FIBPlus and Delphi 2010)
- a problem with my app doing something silly?
More Info
Execution of a single large SQL statement that returns many rows, is perfectly fine.
What is slow is this:
- Start Transaction
- execute SQL query to read order master
- execute SQL query to read all order lines
- for each order line, execute SQL query to pick up latest cost price
- Commit Transaction
Each query is still in the same transaction and database remains connected throughout.
Each query is executed using a TpFIBSQL object.
So, there is a lot of small single statements getting executed, but they are all wrapped within the same transaction, using the same connection.
Any idea of where to start looking, would be greatly appreciated.
Thanks
Maya
[Non-text portions of this message have been removed]
(Forgive me for lack of info here, but I will try to explain as best I can, with what I know, as this is second hand information)
We had a site where just one of our app's functions, on just one of the client machine's was very slow. The rest were all fine.
After no luck resolving the problem ourselves, we had a technical person go out to the site, and they found some kind of a setting on the Intel network card's driver to throttle the speed, if there was too many connections. The card was apparently using the default setting.
Technical person's explanation of the problem:
"I never came across this problem before in all my years . Basically the client spawns many network requests to the server is individual requests, closing the connection and opening it again. This is almost like a connection per line of data. Somehow you need to change the behaviour to stop it opening and closing a connection for each line of data being request and rather keep using the same connection. This will reduce network overhead and most likely improve performance. "
Question
What I am trying to find out (so I can address the issue) is, is this:
- a network card problem (ie. a bad choice of network card?)
- a firebird design problem? (an upgrade to a newer firebird version perhaps?)
- a firebird settings / configuration problem?
- a problem with the component set I am using? (FIBPlus and Delphi 2010)
- a problem with my app doing something silly?
More Info
Execution of a single large SQL statement that returns many rows, is perfectly fine.
What is slow is this:
- Start Transaction
- execute SQL query to read order master
- execute SQL query to read all order lines
- for each order line, execute SQL query to pick up latest cost price
- Commit Transaction
Each query is still in the same transaction and database remains connected throughout.
Each query is executed using a TpFIBSQL object.
So, there is a lot of small single statements getting executed, but they are all wrapped within the same transaction, using the same connection.
Any idea of where to start looking, would be greatly appreciated.
Thanks
Maya
[Non-text portions of this message have been removed]