Hello DZ-Jay, So conclusion is that increasing the backlog does: - decrease the performance for accepting connections - decrease the overall performance of the application
Also: - connecting clients should have a range of retry's when refused, eventually with a random small delay. For your application: Seems you have a lot of processing to do. While your code is executing no incoming socket can be accepting. Then maybe execute a certain block (the most time consuming one) in a separate thread ? You can exchange data between threads the most easy is by posting a message where a pointer to the data is in WParam argument. The pointer can be freed in the custom message handler. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Thursday, November 29, 2007, 11:51, DZ-Jay wrote: > Wait, I'm sorry, I perhaps did not explain correctly: It was taking 5 > to 7 minutes for the server to *process* the client's request to > completion, not the connection. My tests, although quick and dirty, > are intended to check the behaviour of my application as a whole, not > just the connection. > For the sake of understanding, here's a brief explanation of my project: > Its an e-mail queue server; it has a listening thread running > TWSocketServer, which will receive requests from my queue client. The > client communicates with a custom line-based protocol, and sends the > message data, which will then be stored in the queue (filesystem) by > the listening thread. A separate thread periodically scans the queue > directories and dispatches the messages to the SMTP server. The client > builds and encodes the entire message on the fly, line by line as the > data is sent, to avoid having the entire thing on memory at once. But > that's not really important to this discussion (I'm just proud of it > :). > A large message may take a few seconds to transmit. My tests all send > the same message: a multi-part message with alternative text and html > parts, and a small (4Kb) binary attachment, encoded in MIME. The whole > thing was about 14Kb (I think, I'm not sure). I was sending 1000 of > these. >> 1. What kind of machine is it? Commodore 64? TS-1000? TRS-80? Just >> kidding... ;) > He, he, he. If it was processing 1000 *connections* in 5 minutes, I'd > say a pocket calculator! >> 2. Is your client class on the server initiating a bunch of additional >> processes, like database lookups or something? > Not the client, but the server is performing some integrity checks, > file IO, and eventually storing a record of the transaction in the > database. The client does indeed build the message on the fly, even > encoding all content as lines are sent to the server (I'm sorry, there > I go again, but I think this is pretty nifty :), but it doesn't start > doing that until after the connection is established and the message > data is going to be sent. > Plus both the server and the client were running on the same > development machine, along with Delphi-hog-my-memory-2006, in debug > mode, with no optimizations. Moreover, the client test app has a > TMemo, displaying the progress, and in my rush to make a quick and > dirty test, the test app does not free the client objects (all 1000 of > them), until it finishes. > So the slowness wasn't unexpected. The point of my previous message > was to show the difference between two tests, when the only variable > was the backlog value: a backlog of 5 took less than half the time to > do the exact same work as a backlog of 500. > The problem that I see is that the TWSocketServer seems to be taking > too long (relatively speaking) to accept the connections. My client > seems to be able to send lots of connection requests before a single > one is established, thus abusing and exceeding the backlog queue. Of > course, it could be my application that is preventing TWSocketServer > from doing its work effectively, and if so, then perhaps I should > consider using a multi-threaded server. I cringe at that thought, > though, because I had so many problems getting TWSocketThrdServer to > run properly (due to my own lack of experience with this sort of > thing). > Any recommendations would be greatly appreciated. > dZ. > On Nov 28, 2007, at 18:47, Hoby Smith wrote: >> Hmmmm... If it is taking your system 5 to 7 MINUTES to process 1000 >> connect >> / disconnect cycles, then something is very wrong. >> >> I would have to rerun my tests, but I am thinking that I was doing > 1K >> connect / disconnects in about 10 to 15 seconds when running both >> server and >> client on a single core P4. Perhaps a little faster using several >> client >> instances at the same time, although the performance maxed quickly on a >> single core CPU. I believe it was much faster on a 4 way Xeon machine >> I >> tested it on. I can get more specific stats for you, if you want them. >> >> But, whatever my specific results were, 5 to 7 MINUTES is just WAY off. >> >> 1. What kind of machine is it? Commodore 64? TS-1000? TRS-80? Just >> kidding... ;) >> >> 2. Is your client class on the server initiating a bunch of additional >> processes, like database lookups or something? >> >> 3. Do you have any problems with other apps on your system running >> slow? >> Perhaps you have a bad driver or resource conflict with your NIC? >> >> Just some thoughts... >> >> Hoby > -- > DZ-Jay [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
