Hello DZ-Jay,

So conclusion is that increasing the backlog does:
   - decrease the performance for accepting connections
   - decrease the overall performance of the application

- 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]

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

Reply via email to