No worries! Here's the update on this: I have
*slightly* modified my application based on the
suggestions and insight I received from this list.
When I say "slightly" I mean "a lot", but that sounds
too ominous :)
First, I switched to TWSocketThrdServer without a
hitch (hurray! for Arno's hard work on it). This
introduced a new bottleneck: the database calls
needed to be synchronized, and so it was basically
the same as running on a single thread but with the
additional overhead of thread creation and
synchronization. The end result was that it made my
server slower.
Which brings me to the second change I made: I
re-factored all database requests into a separate
thread and completely de-coupled the other two
working threads from having to perform any database
access or additional management logic; they just post
messages to the new thread with the data they need
stored in the database. This introduce a whole new
level of complexity: that of inter-thread
communications and how to cope with un-received
posted messages if the thread needs to abort
unexpectedly (since the other threads now "send and
forget" and expect the database thread to do its thing).
And this led me to the final change in my
application: The new database thread became the
overall manager of the application: it governs all
other threads, instructs them when to start and stop,
and appropriately deals with anybody's impromptu
demise. So now I have 3 worker threads:
1. Queue Manager: performs all database access,
inter-thread management, application initialization
and recovery, and overall management of the entire queue.
2. Queue Receiver: accepts incoming client
connections and stores their data into the queue,
then post the necessary information to the Manager,
making sure state is always recoverable in case of
failure.
3. Queue Dispatcher: scans periodically the queue
and sends the messages via SMTP, then posts a message
to the Manager announcing their result (whether
success or failure) so that it can update the
database record and remove the message from the
queue. It also receives notifications from the
Manager whenever new messages arrive of higher
priority, so that it can interrupt its current scan
and address those.
Overall, the new design is more elegant and
flexible, and still very stable; but more
importantly, it is now considerably faster than
before (orders of magnitude), and none of the
connection issues that I was encountering are
manifesting anymore. For the sake of comparisson, it
now can take about 30 to 40 seconds to send 1000
messages to the Queue Server. And that's with a
backlog of 50. A backlog of 5 takes a few seconds
more because (at most) a handful of connections need
to be retried (10061 error). A backlog of 10
succeeds without retries and takes roughly the same time.
This means that it was my application design which
was impeding the performance of TWSocketServer, and
not an inherent issue with TWSocket itself (DOH!).
System resources are limited, of course, so in my
opinion our empirical analysis on the usage of the
backlog is still valid: a larger number seems to
affect performance negatively without any overall
gain in availability, especially under heavy stress.
In conclusion, as Arno and Wilfried suggested from
the beginning (and as Francois has always claimed),
TWSocket is fast, efficient and fully capable of
handling thousands of concurrent connections,
provided there are sufficient resources for it, and
that no _extensive_processing_ is competing with the
socket communication. How's that for an endorsement :)
Thanks to all of you who offered help and suggestions.
Cheers!
-dZ.
>------- Original Message -------
>From : Hoby Smith[mailto:[EMAIL PROTECTED]
>Sent : 12/5/2007 12:44:57 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] TWSocketServer and backlog
>
>Hey DZ. Sorry, I didn't mean to drop out of this
email thread. I have just
been slammed for the last week and didn't have a
chance to response to any
of the further posts on this (they were buried in
very long inbox). From
what I see, Wilfried and Arno helped you out more
than I would have anyway.
Also, sorry I misunderstood your initial post about
this. Story of my
life... always coming in to the middle of a
conversation confused and
broke... ;)
BTW, the "pocket calculator" comment was LOL... :)
--
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
