[Top] [All Lists]

Re: productivity?

2011-08-23 07:46:38

Peter J. Holzer wrote:
I don't see how this can make a difference. TIME_WAIT is 240 seconds
(per RFC, some implementations use shorter defaults). If your ephemeral
ports are limited to the range 1024-4999 (which used to be popular), you
are limited to (5000-1024)/240 = 16.6 connections per second. Putting in
a sleep(0) doesn't change this, lowering TIME_WAIT or extending the
range of ephemeral ports does. (Waiting for the other side to close the
connection does, too - but unless I'm missing something moving the
problem to the other side doesn't help if you want to communicate with
the other side). I'm with Carl here - if you need to send 17+ mails per
second, it's much better to reuse connections than to permanently close
and reopen them.

Devil details.

I mentioned the poor man's poke because I seen it too often when a port to windows is done and it WINTEL fundamentals are not very well understood. You got hardware interrupts (networking and disk) services where bottlenecks occur and other worker threads to cooperate with, so poking as a poor man's way to wake up other workers without losing must of your own time. Its not the 100% Wintel Way, but it can used. I might use it to help wake up hardware related concepts. Timing is everything, yet it needs to be understood how it can give you unpredictability. Windows is not an RTOS (Real Time Operating System) where such timing predictions are guaranteed. For example, it is often misunderstand what the actually elapse time are.

      Sleep(0)  15 ms,  return immediately
      Sleep(1)  15 ms,  Thread is Queued
      Sleep(21) 20 ms,  Thread is Queued
      Sleep(36) 45 ms,  Thread is Queued

etc, in other words for robust well understood system, you must have a understanding the CPU Quantum size and the whole timing paradigm under Windows. I have seen huge huge monster debates when unix thinking simply doesn't apply in Windows because they thought there was a 1 ms resolution with timing, they get hung on on Linux or other *nix timing slicing granularity (1ms vs 15ms) and believe that it equally applies to Windows - it doesn't and those that continue to think so continue to have problems or just live what they have achieved.

16.6 cps is very slow.

Was ASYNC or SYNCH used? Threads? Sequential programming? You can blast 16 threads and you can't use reuseability. You also need to take in account that Windows also have caching too. So opening and closing is not as wasteful as you think.

As I noted to Carl off list, I just did a quick test using our internal SmtpStress tool that can blasting X threads with Y messages per thread, and without changing the license limit of 25 concurrent connections on our SMTP server test machine, I was able to blast 25 message under 1 second. It wasn't even a full second. Changing our logs to microseconds was all part of this profiling done early this year. And I know more connections were possible because using X=50, there were a 25 421 server responses.

Note: That is another thing in RFC5321, it doesn't explicitly say that 421 can be used at the connection point. It mentions 554, but that requires you to hold the connection until the client issues a QUIT.

Finally, I do think, what you touched base with, a half-close shutdown needs to be check if this is needed. Why? Because when the Download/Upload speeds differences became dramatic, all of a sudden applications such as IE, Apache and so many others, including our own Wildcat! Web Server began to experience timing and synchronizations problems. The infamous IE "Page Not Found" problem was directly related to servers not using Half-Close socket Shutdown. It was all because the of that final ACK was lost. I specially recall reluctantly trying Sleeps() to try to get it to work, but what worked here, didn't work there. The solution was to use half-close shutdowns.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>