CAsyncSocket slow ??

[FrankJensen]

I made a quite simple AsyncSocket project. One server program, connecting to a SQL database on the server, and one client program, receiving and displaying data.

What I do, from the client side, is to request data from the server, and the data sends one record from the database in plain text. The socket and the SQL database stays open, and the client now just requests NEXT, NEXT etc. until EOF.

All records are received. But its quite slow. Only 4-5 records apear a second. Running both server and client program on same computer improved this, but it still takes much longer than expected - the database have many rows, but each row do not contain much data.

Removing the NEXT handshake, and just send out everything, makes the transfer stop after a short while. Like some kind of overflow somewhere. No error messages apear, and everything seems to be sent, its just not received.

Basically, what I want to do, is to have all SQL code and calculations on the server, so that the client just displays the result. Cause some of the calculations I do, is much, much faster on the server directly, than tru the network - well, not at the moment, but that was the plan, making use of timeconsuming calculations over a relative slow network, and with a slow client computer (compared to a super-server).

[hoxsiew]

Without seeing any code, it's impossible to diagnose. I'd suspect the bottleneck should be SQL server; coming from a Unix/Oracle environment, I was shocked at how slow SQL server is compared to Oracle. However, even your numbers sound way too slow. I suspect something in either your DB interface, or in the socket interface.

CAsyncSocket has a lot of issues, but it is a decent wrapper to get you started. Most programmers end up writing their own class wrappers, or just using the winsock API directly once the basics of socket operations are understood. That said, I don't think it is any of the CAsyncSocket nuances causing your slowdown.

Your transfer stopping short is probably due to the winsock stack "chunking" your data throughput. Are you checking your recv() return value? It may not be the same as the value in the server's send() function. You have to check it against what you expect, and keep calling recv() until all the bytes are received.

[MikeAThon]

I tend to agree with hoxsiew. Your slow transfer rate was almost certainly caused by the NEXT handshake. As one indicator, the 4-5 per second rate is suspiciously close to the 200 msec value of delayed-ACK.

Removal of the NEXT handshake probably exposed a different coding error, one that didn't previously show itself often because of the shortness of each record. As mentioned by hoxsiew, this coding error (if it exists) would involve failure to inspect the returned value from recv(), to confirm that you have received all bytes that were expected.

Mike

PS: Post again if all this seems to make sense given your code, and if you have a question on how to determine the number of bytes that are "expected"