[EMAIL PROTECTED] wrote:
>> ------- Original Message -------
>>> From    : Arno Garrels[mailto:[EMAIL PROTECTED]
>> 
>>> 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.
> 
>> That's indeed the fastest way since the thread must
> not wait.
> 
> However, if the main thread notified the slave
> threads to quit, the last thread that quits may post
> messages (before receiving the WM_QUIT message) to
> the first one and fail, which will cause the memory
> in the message to not be freed (until the application
> finally quits).  I don't know if this is a real
> concern, though.

When the process died the memory is given back to the 
OS anyway, so no problem. PostMessage() will return 
False on failure, in this case the memory can be
released by the calling thread.

> 
>> 1 - Stressing a server with 100 connection attempts per second is
>> most likely not a real world scenario, except upon DoS
> attacks.
> 
> I agree.  However, 
> 

It's easy to "DoS" any server ;-) 

>> 2 - Run your stress tester against IIS or other servers, I found that
>> they were not able to accept more clients per
> second than my server.
> 
> I'm sure this is true.

>> 3 - I played with different designs.
> 
> Which would you consider to work best?

Hard to tell, a good compromise is using TWSocketServer given
any lengthy task is run in worker threads. I think separating
socket IO work from other tasks by using worker threads for those
tasks considered "lengthy" is the way to go. The definition of 
"lengthy" however is another story then. <g> 

--
Arno Garrels 


>    -dZ.
> 
>> Sent    : 11/29/2007 1:52:38 PM
>> To      : twsocket@elists.org
>> Cc      :
>> Subject : RE: Re: [twsocket] TWSocketServer and backlog
>> 
>  >DZ-Jay wrote:
>> On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote:
>> 
>>> Hello DZ-Jay,
>>> 
>>> So conclusion is that increasing the backlog does:
>>>    - decrease the performance for accepting
> connections
>>>    - decrease the overall performance of the
> application
>> 
>> This seems to be the conclusion of mine and Huby's
> tests.
> 
> Strange, I never noticed something like that.
>> Perhaps I should run the TWSocketServer on its own
> thread, and post
>> messages from the clients to the queue manager thread to do the work?
>> Although this seems too complex and expensive.  It
> almost looks like
>> each client should run on its own thread... :(
> 
> I'm that sure:
> 
> 1 - Stressing a server with 100 connection attempts
> per second is most
> likely not a real world scenario, except upon DoS
> attacks.
> 2 - Run your stress tester against IIS or other
> servers, I found that
> they were not able to accept more clients per second
> than my server.
> 3 - I played with different designs.
>     a) Listening sockets in one thread, client
> sockets in another thread(s).
>        This introduces a new problem, clients are
> accepted very fast,
>        however the listening thread must synchronize
> with the client
>        thread(s) which may take longer than with
> current TWSocketServer,
>        I worked around by posting just the socket
> handle to the thread
>        which was fast, however also rather
> complicated to handle all
>        the client stuff/pool in the threads.
>     b) Listening sockets in one thread, one thread
> per client.
>        AFAIR without a thread pool accepting clients
> was slower than
>        with TWSocketServer.
>     c) I even hacked together a server that used M$
> overlapped sockets,
>        this was a rather disapointing discourse since
> performance was
>        the same as with (a).
> 
> The goal is to accept clients as fast as possible,
> once they are
> connected it won't hurt to let them wait some
> milliseconds.
> 
> Before you rewrite your application I suggest you
> code some test
> apps. with different designs and compare their
> performance.
> 
> --
> Arno Garrels
> 
>> 
>> dZ.
>> 
>> --
>> 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
-- 
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