none
Is Socket async send crippled on Windows 7? RRS feed

  • Question

  • Recently we ran into an interesting problem with .Net Socket and wanted to find out if anyone has seen the same issue as well.

    We have an application that uses the Socket class to implement a proprietary protocol for communication with the client. The setup of the test environment is as follows:

    • The application server runs on a Windows Server 2008 R2 Standard host.
    • The load test client runs on Windows 7 (Enterprise).
    • The test client and the application server communicates through TCP socket in a request-response fashion. The request is rather small (about 400 bytes), while the response is big (about 20KB). Each client connection sends a request, waits for the response to come back before sending the next request.

    We wanted to see how the application server scales as the number of client connections increases. We started with one client connection and gradually increased the number of connections. Below are the results:

    • The server TPS was about 10 with one client connection.
    • The server TPS was about 20 with two client connections.
    • The server TPS was capped at around 25 with more than two client connections, regardless of whether the client connections were from the same process or multiple processes on the same machine.
    • In the WireShark trace, we can see delay between the client receiving response packets and sending out the next request packet even though the client code immediately sends the next request after the previous response is received. With 20 client connections, the delay is about 0.75 seconds; with 40 client connections, the delay is about 1.5 seconds. We thought about disabling Nagle's algorithm, but setting Socket.NoDelay to true in the test client did not appear to make any difference.

    To understand the issue we had run more tests in different scenarios, the results are summarized as below:

    1. When the test client runs on Windows 7 and the app server runs on Server 2008, it does not scale and the TPS caps at 25.
    2. When both the test client and the app server run on the same Windows 7 host, it scales well. 
    3. When the test client and the app server run on separate Windows 7 hosts, it does not scale and the TPS caps at 25.
    4. When the test client and the app server run on separate Server 2008 hosts, it scales well.

    Note that the test client that we had problem with used async Socket API - SendPacketsAsync() and ReceiveAsync(). We had an older version of test client that used the sync Socket API - Send() and Receive() and it scaled pretty well in case 1 (client on Windows 7 and server on Server 2008).

    So my questions are:

    1. Are there any parameters that we can tune to increase the client throughput on Windows 7?
    2. Has Socket async API been intentionally crippled on Windows 7 to have limited throughput?

    Monday, June 1, 2015 7:00 PM

All replies

  • Hello Qiu, Wenning,

    >>1.Are there any parameters that we can tune to increase the client throughput on Windows 7?

    In my opinion, the client throughput should be depended on the system configuration, I do not think a .NET api would contain the function. However, there are some measures we can do to improve the performance of the Socket, for detail, please check this article to see if it helps you:Get Closer to the Wire with High-Performance Sockets in .NET.

    Do you check the result is the same if you use other version client as windows8/8.1? If possible, I suggest you could do it, this would help us narrow down to check if your scenario is caused by the system feature or the async api.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, June 2, 2015 2:03 AM
    Moderator
  • Thanks Fred. The only systems that I have access to right now are Windows 7 and Windows Server 2008. Since Windows Server 2008 are used in our production environments, the issue is not a major concern for us at the moment.

    After some more tests, the message size does not appear to be a contributing factor. I had the server just echo back the bytes in the small request message and the problem still exists.

    If Microsoft is willing to dive deeper into this, I probably can strip down our application codebase and create a test suite.

    Tuesday, June 2, 2015 4:24 PM
  • Hello Qiu, Wenning,

    For this issue, I am trying to invoke someone experienced to help look into this case, this may take sometimes and as soon as we get any result, we will tell you.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, June 3, 2015 5:20 AM
    Moderator