Wcf ThreadPool and async

There are many different factors that could be in play here. Taking a stab at the remark that changing your instancing model on the service had zero effect (big IF here) then its possible the 'bottleneck' is upstream from the service. Either at the web server, or the client load generator.

You've got several areas to review for tuning: client, web server, wcf service server - that's assuming there are no network devices in the middle. Pick an end and work towards the other end. Since I'm already making an assumption that its not the service, then I'd start at the client and work my way towards the wcf service.

Client
What machine is driving the load against the web server? A laptop? A desktop? A dedicated test agent, or a shared one? The client acting as the load generator for purposes of this test is also susceptible to maxConnections limitation as this is a client setting.

What is the CPU utilization of the client generating load? Could it be that the test driver is just unable to generate enough load to push these boxes? Can you add additional test clients to your test?

Web Server
What does the system.net/processModel element look like in machine.config on the ASP.NET web server? Try setting autoConfig = true. This will allow the configuration to auto size based on the 'size' of the machine its running on.

WCF Service
Review WCF service for any throttling defaults that might be in play and tweak appropriately. See ServiceThrottlingBehavior on MSDN.

Let us know any changes in behavior you might observe (if any) if you make any changes!

Your right, the default is to limit clients to 2 concurrent requests. However, this can be overridden and likely should be for server applications. @RubbleFord mentioned that they've set this to 20 already, which is why it not expressly called out in answers. Thanks for pointing this out, I've emphasized this in my response to help make it clearer. Your probably aware, but just in case, see http://msdn.microsoft.com/en-us/library/1tkaca2y.aspx. Thanks! Z

Zach Bonham 2009-08-22 02:38:13

You're still not thinking of the client as a browser but as an application. The link you posted is specifically for modifying an application's config file, which you *do not have* for an ASP.NET page.This is a case where IE strictly follows the standards-- in this case, RFC2616 < http://www.faqs.org/rfcs/rfc2616.html >, which covers HTTP1.1. In the RFC:Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

JustLoren 2009-08-22 17:26:43

Your right and I think we are both correct. The browser may not have a config file to tweak to overcome this setting - agree 100%. However, most testing agents, and tools, that drive load against a web page do not do so through the browser itself, but at the protocol (http) level. If this testing agent is .NET based (Visual Studio Team Test, custom .net code, etc), then it will be subjected to that limit unless changed. Following that request from test agent to web site, then the request from website to web service is also subject to limit because the site is now a client of the service.

Zach Bonham 2009-08-22 20:54:56

You're only correct if RubbleFord is using a browsing testing agent or tool and he's interested in having his testing agent perform differently than the browser will. As it isn't best practices to have your testing tool perform differently than the browser, I can't see how your solution will ever be applicable.Couple that with the context/wording of Rubble's post, and I'm convinced he's using a standard browser and some form of timing mechanism (such as alert()ing the difference in time from when it all starts to when it all ends).

JustLoren 2009-08-23 14:10:01

Why is it not a best practice to have your testing tool perform differently than a browser? What good is it if it can only perform the duties a user could do? In fact, I don't buy that this is a best practice... most of the testing tools out there I've seen (aside from unit testing tools like Watir/Watin that use the actual browser through OLE automation) don't do this - they receive and parse the HTTP responses manually so that they can be scaled out above normal limits to stress a system. Isn't that the point of load testing?

Anderson Imes 2009-08-23 20:58:47

@JustLoren - without additional information from @RubbleFord, we just hazarding guesses, so its pretty moot. I assume @RubbleFord was using some sort of testing agent because of the description of timings (8 requests/sec), but you know where that gets me. :) The browser does run on the client, and other than sending different headers in the request, it has little impact on the request that runs on the sever. How the browser renders the response is somewhat more of a challenge and can be very browser specific.

Zach Bonham 2009-08-24 00:24:04

@Anderson Imes: Nowhere does the original poster say he's accomplishing server load testing. Instead, he's very specifically concerned about load time on the client. If you're trying to "time" the rendering of the web page, using something that's wildly divergent from a web browser will give wildly inaccurate numbers.@Zach: I guess we both just read the initial post differently. I guess only @RubbleFord can clear it up.

JustLoren 2009-08-24 12:40:11

ansaurus

tags:

views:

answers:

Wcf ThreadPool and async

related questions