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
