Re: ThreadPool and IoCompletionPorts
From: Henning Krause (newsgroup.no_at_spam.infinitec.de)
Date: 06/07/04
- Next message: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Previous message: Raymond Lewallen: "Re: select sql is very large and slow"
- In reply to: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Next in thread: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Reply: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 7 Jun 2004 19:05:55 +0200
Have you measured the Processor Queue Length in both scenarios? That would
be quite interesting.
Greetings,
Henning Krause
==========================
Visit my website: http://www.infinitec.de
Try my free Exchange Explorer: Mistaya
(http://www.infinitec.de/?page=products)
"Angelos Petropoulos" <Angelos_Petropoulos@Yahoo.co.uk> wrote in message
news:ks59c05oc5pou4gukvmtroj844j6ajkvu6@4ax.com...
> OK, I have some findings and some further questions. First of all, I
> would like to post a link to a winsock 2 article, covering completion
> ports, that I hadn't seen before today:
>
> http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/
>
> Now, after a lot of searching and reading I found the reason behind my
> performance problem. The code to reproduce it is quite simple, this is
> what the server (in an example where the server receives and the
> client sends) code would look like this:
>
> private void BytesReceived(IAsyncResult ar) {
> SocketAndBuffer socketAndBuffer = (SocketAndBuffer)
> ar.AsyncState;
> int noOfBytesReceived = socketAndBuffer.Socket.EndReceive(ar);
> socketAndBuffer.Socket.BeginReceive(socketAndBuffer.Buffer, 0,
> socketAndBuffer.Buffer.Length, SocketFlags.None, new
> AsyncCallback(this.BytesReceived), socketAndBuffer);
> }
>
> Perfectly innocent code that does nothing but receive from the socket.
> It works, as a matter of fact it works so well that even after the
> client closes the connection (socket.Close()) this loop keeps on going
> with EndReceive returning 0 bytes read and not throwing a
> SocketException. This is where my performance problem lied, the
> constant and instant return of 0 bytes from the socket caused the CPU
> util to rocket.
>
> Now that I have solved this problem I feel more confident about IO
> Completion Ports, but I still have some questions.
>
> In the light of this, new to me, information I went ahead and fixed my
> test apps that I used before to measure performance. The server code
> now looks like this:
>
> private void BytesReceived(IAsyncResult ar) {
> SocketAndBuffer socketAndBuffer = (SocketAndBuffer)
> ar.AsyncState;
> int noOfBytesReceived = socketAndBuffer.Socket.EndReceive(ar);
>
> if (noOfBytesReceived != 0) {
>
> socketAndBuffer.Socket.BeginReceive(socketAndBuffer.Buffer, 0,
> socketAndBuffer.Buffer.Length, SocketFlags.None, new
> AsyncCallback(this.BytesReceived), socketAndBuffer);
> }
> }
>
> and the client code looks like this:
>
> while (counter < 1000) {
> counter++;
> socket.Send(bytesToSend, 0, bytesToSend.Length,
> SocketFlags.None);
> Thread.Sleep(10);
> }
>
> The theory behind it is very simple, have a client send a string every
> 10ms and have the server read from the socket using BeginReceive. With
> 40 clients connect to the server the CPU util would touch 41% every
> now an then, but hover at about 21%.
>
> Using exactly the same client code and instead of using BeginReceive
> creating a new thread that called Receive() resulted it better
> performance. To be exact, the maximum CPU util recorded was 32% and
> the average was 15%.
>
> I then thought of making the test even more brute force and I removed
> the 10ms delay in the client. All the server code remaining exactly
> the same, using individual threads for each client resulted in a 65%
> CPU util with one client and 99% CPU util with 2 clients. Not very
> promising. Using completion ports however resulted in an average of
> 30% CPU util even with 10 clients! Quite remarkable!
>
> So why is it that individual threads per client are faster in the
> first test but slower in the second? Shouldn't the use of completion
> ports be beneficial, especially when the number of clients is high?
>
> Regards,
> Angelos Petropoulos
>
> On Sun, 6 Jun 2004 23:11:05 +0200, "Henning Krause"
> <newsgroup.no@spam.infinitec.de> wrote:
>
> >Hello,
> >
> >> Have you tried testing the scenario of a continuous stream of
> >> information like in the case of downloading the contents of a file
> >> (i.e. constantly calling BeginReceive)?
> >
> >No.... Only one BeginReceive..EndReceive. Then finish.
> >
> >>
> >> Also you say that context-switches went from ~500 to ~1500. Did you
> >> mean to say from ~1500 to ~500?
> >
> >No, no... I had about 500 context-switches when the system was idle. And
> >when the program ran, context switches went up to about 1500 per second.
> >
> >Greetings,
> >Henning Krause
> >==========================
> >Visit my website: http://www.infinitec.de
> >Try my free Exchange Explorer: Mistaya
> >(http://www.infinitec.de/?page=products)
> >
> >
>
- Next message: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Previous message: Raymond Lewallen: "Re: select sql is very large and slow"
- In reply to: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Next in thread: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Reply: Angelos Petropoulos: "Re: ThreadPool and IoCompletionPorts"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
