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 

> 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 

Any recommendations would be greatly appreciated.


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]

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