I still think I'm hitting some limit on connections from a windows app
on Windows XP to a web service on Windows Server 2008.  I have read XP
has a 10 connection limit of some kind.  I need to know more about this.

I've asked before but have trouble explaining.  I'll try again.

The main form loops every 200 milliseconds:
launches a thread
displays the counter class's total concurrent threads value


Each thread:
notes the time it starts
increments a counter class
Calls a web service (same info each time)
notes the time it finished and any errors that occured
write the times etc to a log file
decrements a counter class
thread ends.

The web service records the time it receives a request and the time it
receives a request and the total time it took to process it.  it's
always between .1 and .3 seconds.

What I see.  I start the program about 9:42.  The concurrent threads
starts to climb it eventually hit 2000 connections!  I aborted the
program at that point at about 9:50 as it was returning out of memory
and unable to start a new thread messages.  After aborting the program
the threads remained (as they should) I noted this in task mgr too.
They slowly came down to 0 about 10:10.  Through this whole process the
web service says every request it got took an average of .283 seconds to
process and it got requests from 9:42 to 10:05.  The program calling the
web service on the other hand reports it made requests from 9:42 to
9:50. the first few were fast but then they started taking longer and
longer (up to 15 minutes) for the threads to finish.  The thread's sole
purpose is to call that web service sending the same value to it (for
testing) and get the result.

Strangely I tried repeating the test and this time it worked fine
staying at 1 or 2 concurrent connections for a whole hour of testing.

This is quit like in real life with real requests.  I swear that the
problem is that once it hits a certain number of concurrent threads
running it reaches some sort of log jam and request are then being
queued and released to the web service slowly.

I have one additional statement to make.  While it did hit 2000
concurrent connections in that one test.  Problems start when the
concurrent connections go somewhere between 10 and 25.  It's at those
times when the web service says it took .28 seconds to reply and the
calling program says it took 15 seconds to get the reply.  That's a
problem as we need responses in less than a second.  2000 and 15 minutes
is an extreme example.

cj2 wrote:
Show quoteHide quote

Hi,

I think this is not related to the XP concurrent connection limitation.
XP's concurrent connections limitation is 256 for TCP/IP connections, as
far as I know, and when you exceed the limitation, you will receive "TCP/IP
has reached the security limit imposed on the number of concurrent TCP
connect attempts".

I am trying to understand more about your test scenario. From my current
understanding, I do not think the test is similar with a real life
condition. Actually, which peformance we really need to concern is the
server-side performance, right? In this case, the server side webserivce
has a good performance and it always process and reply in less than one
second. The problem is the client's repsonse time is too long to accept
from the log's perspective, right? My concern is that in real life, the
clients that make request calling may be in different computers and even in
different places. But in our test, we put 2000 clients in one process at
one machine. The test way itself will slow the client application because
when we create a thread, the process will allocate a memory snippet for
that thread stack. 2000 threads means that 2000*1M = 2G virtual memory
space. It definitly slow the application. And in each of the thread, we
make loggs to the local drivers. That also cause a lot of time to do IO
operations. So when there are too many threads running together in one
process. The log operation will be very slow. So you will see your clients
too slow. The right way to test in this case is letting different physical
clients consume your webserivce at one time. I believe, as long as your
webserivce reply in one second, all of your clients will get the reply
soon. The performance issue should not exist in real life.

Hope this gives the right direction. Have a nice day!

Best regards,
Colbert Zhou
Microsoft Newsgroup Support Team

Actually. in this case it is close to reality as we do have one
application that repeatedly calls the web service.  The web service is
also handling other requests as well from various sources but over half
of it's calls come from this one app.  In the production app the threads
are answering TCP/IP connections taking the request and sending it to
the web service then taking the web services response and sending it
back to the TCP/IP client.  It allows old systems with code out of our
control to talk to the web service.  For the sake of testing we've taken
the TCP/IP part completely out and just have the test program simulate
the load it would be sending the web service by creating threads that
call the web service and receive it's response.

Again while I mention that the test app ran up to 2000 concurrent
threads this was an extreme example and we normally see responses taking
too long when we get somewhere around 10 to 25 concurrent threads.

In the web service I time from as close to the top of the code as
possible to right before I write the total time it took into the sql
log.  It averages .283 seconds.  In the calling app I note the time
right before the the line where I call the web service and again right
after then write it to a text file.  It says it took minutes.  From my
perspective the calling app makes a call but it takes minutes before the
web service sees it then the web service processed in .283 seconds and
returned the result.  Or the delay is on the other end.  The calling app
makes the request and the web service processes it in .283 seconds then
the return takes minutes.

Or the writing of the total times by the web app to sql is taking
forever as I have to take the end time right before the write to the sql
log which is of course right before the web service returns the results.
  But if writing to sql was the problem I would think we would see
problems with other systems here that are using sql during these times
and we haven't.

Regardless I trap and log all errors and haven't gotten any.  The
process just takes too long.

I know this is a very hard thing to diagnose but if you know of any
limitations I might be running into let me know.  I am just looking for
other ideas.  I'm still testing.


Colbert Zhou [MSFT] wrote:
Show quoteHide quote

Hi ,

If we are using TCP/IP connection in your XP, yes, we have a 256 connection
limitations. You can refer the following link to remove this limitation.
But I do not think the described issue is related to this because you
mention that 10-25 cocurrent threads also causes this problem.
http://www.tech-faq.com/concurrent-connections-limit-in-windows-xp.shtml

Actually, we can use the tool fiddler to listen and trace your client. The
tool can trace all out connections and log the requesting and reponse time.
Please download the fiddler from the following page,
http://www.fiddler2.com/fiddler2/
http://msdn.microsoft.com/en-us/library/bb250442(VS.85).aspx

So that we can detect where the performance bottle-neck is, the client app
itself or the communication time.


Best regards,
Colbert Zhou
Microsoft Newsgroup Support Team

inputbox
How do I create new app with data access?
Concurrency error on update
VB.NET Charting Solution
HTML, CSS and JavaScript in a Gridview
Have thread end if not finished in X seconds
How To :App.Config
is this possible?
Pass a structure to a C++ dll
Duplicated data - how to understand it please?