Re: Problem with BackLog (TCP Queue)..

FYI, I changed the registry settings.. I have zero socket errors now..

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpNumConnections"=dword:00fffffe
"MaxFreeTcbs"=dword:000007d0
"MaxHashTableSize"=dword:00000200
"TcpTimedWaitDelay"=dword:000000f0

=============================
Stats..
=============================
Number of hits: 13094
Requests per Second: 109.11

Socket Statistics
--------------------------------------------------------------------------------
Socket Connects: 13099
Total Bytes Sent (in KB): 5966.29
Bytes Sent Rate (in KB/s): 49.72
Total Bytes Recv (in KB): 97789.26
Bytes Recv Rate (in KB/s): 814.86

Socket Errors
--------------------------------------------------------------------------------
Connect: 0
Send: 0
Recv: 0
Timeouts: 0
RDS Results
--------------------------------------------------------------------------------
Successful Queries: 0

Script Settings
=============================
Server: localhost
Number of threads: 200
Test length: 00:02:00

"Chizl" <Chizl@xxxxxxxxxxxxxx> wrote in message
news:ex7jIAZUIHA.5288@xxxxxxxxxxxxxxxxxxxxxxx
First of all thanks for taking the time to respond.. I have some
comments below.

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.t4kn99s48jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
My recollection is that the operation system has its own maximum backlog
value. Trying to set the backlog above this value will result in either
no effect, or setting to the maximum value. In neither case will you get
the backlog you're asking for.

Doesn't that defeat the purpose of the call? I assume this is like
Affinity.. The OS has one setting, but you can override that with an API
for a specific application. The API doens't change the settings
permanent, but it does for the life of the application and that
application only.

One suggestion: in the code you posted, rather than having a thread sit
and loop calling BeginAcceptSocket() over and over, just have the
EndAcceptSocket() callback call it (and do so right away). The way the
code is written now, you are guaranteed a thread switch between accepting
one socket and being ready to accept another, and then of course another
thread switch to accept the next one again. This is going to
unnecessarily inhibit your throughput, artificially reducing the number
of simultaneous connection requests you can process.

I'll look deeper into this, but I got this info from MS.
http://msdn2.microsoft.com/en-us/library/system.net.sockets.tcplistener.beginacceptsocket.aspx

You have other performance-hindering design choices there as well:

* your accept callback really should be doing very little. If you
have some heavyweight processing you want to do when accepting a client,
you should handle that elsewhere if handling a large number of
simultaneous connections is a priority for you. Otherwise, you get stuck
with a thread that's doing something other than accepting connections.

I'm assuming you mean my MyWebServer.AddConnection() call. That's doing
nothing but checking current connections < max connection, then incriment
a counter.

* You should not be creating a new thread for each connection. Use
the async i/o methods for the Socket class instead (e.g. BeginReceive).
Using a thread for each connection you will unnecessarily limit the
maximum number of connections you can handle -- the number of threads any
given process can create is much lower than the number of sockets a
process could theoretically handle -- and at the same hurt performance
because of the constant thread context switches that will be required to
deal with multiple active connections.

The thread I'm creating is after I've released the callback. In VC++
I've tested a spawn of over 2000 threads, your saying in C# that isn't
possible? Based on the examples I've seen with using BeginReceive() it's
holding the receive open longer than I currently am. But I'll look
deeper and see if I can find some better examples.



.

Relevant Pages

  • Asynchronous Socket Server data
    ... The socket server knows what type of data it expects due to the interface ... I can have 1 databuffer only for each datatype to handle multiple connections? ... int bytesRead = handler.EndReceive; ... packetIndex, bytesRead); ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Ping =?ISO-8859-1?Q?kr=E1ft=E9=E9_=3F_Advice_needed_?= =?ISO-8859-1?Q?to_trace_w
    ... He has two telephone extensions leading from the master socket and his ... presume that there is a fault in his extension wiring. ... If it's twisted pair ensure that it's not been connected split pair, in other words the blue white with white blue, orange white with white orange, if you get my drift, & the connections you should use are 2&5 ...
    (uk.telecom.broadband)
  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, although there's not been the usual ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: !EventConnect Problem
    ... the June roll-up is available somewhere, ... The socket is not in a listening state. ... The incoming connection queue has no room for connections. ...
    (microsoft.public.windowsce.app.development)
  • Re: What is the best way to stop a Socket.BeginAccept call?
    ... If you want a graceful exit, then stop accepting new connections, ... close all worker sockets, close the listener socket. ... public void AddSocketToList ...
    (microsoft.public.dotnet.languages.csharp)