Thread: ODBC driver over network very slow
We are running an application that uses psqlodbc driver on Windows XP to connect to a server and for some reason the download of data from the server is very slow. We have created a very simple test application that inserts a larger amount of data into the database and uses a simple "SELECT * from test" to download it back. The INSERT of 10MB takes about 4 seconds, while the SELECT takes almost 5 minutes (with basically nothing else running on both the network and the two computers). If we run the PostgreSQL server on the local machine so that the network is not used, both actions are very fast. Do you have any idea what could be the cause of this behavior? Are there any driver settings/other drivers we should use? We are currently using psqlodbc version 7.03.02.00, but it seems that other versions we tried show the same behavior. We have tweaked the various driver settings but the times remain basically unchanged. Any ideas or hints are warmly welcome. regards Milan
Milan Sekanina <milan@sde.cz> writes:
> We are running an application that uses psqlodbc driver on Windows XP to
> connect to a server and for some reason the download of data from the
> server is very slow. We have created a very simple test application that
> inserts a larger amount of data into the database and uses a simple
> "SELECT * from test" to download it back. The INSERT of 10MB takes about
> 4 seconds, while the SELECT takes almost 5 minutes (with basically
> nothing else running on both the network and the two computers). If we
> run the PostgreSQL server on the local machine so that the network is
> not used, both actions are very fast.
I seem to recall having seen similar reports not involving ODBC at all.
Try searching the mailing-list archives, but I think the cases we solved
involved getting rid of third-party add-ons to the Windows TCP stack.
regards, tom lane
> Milan Sekanina <milan@sde.cz> writes: > > We are running an application that uses psqlodbc driver on Windows XP to > > connect to a server and for some reason the download of data from the > > server is very slow. We have created a very simple test application that > > inserts a larger amount of data into the database and uses a simple > > "SELECT * from test" to download it back. The INSERT of 10MB takes about > > 4 seconds, while the SELECT takes almost 5 minutes (with basically > > nothing else running on both the network and the two computers). If we > > run the PostgreSQL server on the local machine so that the network is > > not used, both actions are very fast. > > I seem to recall having seen similar reports not involving ODBC at all. > Try searching the mailing-list archives, but I think the cases we solved > involved getting rid of third-party add-ons to the Windows TCP stack. IIRC there was a TCP related fix in the odbc driver related to performance with large buffers. I'd suggest trying a newer odbc driver first. Merlin dave page wrote ([odbc] 500 times slower) > > My collegue spent some time to dig the following case and it > looks like > Nagle algorithm and delayed ACKs related problem. > In psqlodbc.h > #define SOCK_BUFFER_SIZE 4096 > > I changed that value to 8192 and driver works fine for me. > I am not sure why this change helps. Err, no neither am I. Why do you think it's got something to do with Nagle/delayed ACKs? The only thing that instantly rings bells for me is that the max size of a text field is 8190 bytes at present (which really should be increased, if not removed altogether), which won't fit in the default buffer. But then, I wouldn't expect to see the performance drop you describe with a 4096 byte buffer, only one much smaller.
I was hesitant to jump in on this because I am new to PostgreSQL and haven't seen this problem with _it_, but I have seen this with the Sybase database products. You can configure Sybase to disable the Nagle algorithm. If you don't, any query which returns rows too big to fit in their network buffer will be painfully slow. Increasing the buffer size can help with an individual query, but it just reduces the scope of the problem. What you really want to do is make sure that TCP_NODELAY is set for the connection, to disable the Nagle algorithm; it just doesn't seem to be appropriate for returning query results. How this issue comes into play in PostgreSQL is beyond my ken, but hopefully this observation is helpful to someone. -Kevin >>> "Merlin Moncure" <merlin.moncure@rcsonline.com> 06/30/05 9:10 AM >>> > My collegue spent some time to dig the following case and it > looks like > Nagle algorithm and delayed ACKs related problem. > In psqlodbc.h > #define SOCK_BUFFER_SIZE 4096 > > I changed that value to 8192 and driver works fine for me. > I am not sure why this change helps. Err, no neither am I. Why do you think it's got something to do with Nagle/delayed ACKs?