Question

I would need some help to point me in the right direction.

We want to expose service functionality (which consists of reading + updating a SQL Server database) via WebHTTP end points as per-call services to users.
We don’t want to use SOAP if avoidable, as we have trouble to make this interoperate on other platforms.
This must be scalable to 1000+ users, which, in this scenario, are unlikely to submit many concurrent requests. It is estimated that at any given time there should be max 25 concurrent requests.

(That’s why per-session services were ruled out, since that would meant to keep 1000+ sessions open while only 25 actions are performed.)

By experience with a test service, we find however, that using pure Per-Call WCF services over HTTP perform poorly, with the largest time lapse being the initialization of the SQL server connection.

It’s sort of a similar scenario to what a web server normally would encounter.
Therefore it appeared sensible to use a similar approach as web servers do – for performance reasons they keep a pool of HTTP engines active, and incoming requests are being assigned one of the engines in the pool.

So we want to keep a pool of 25-30 “Business Logic Objects” (i.e. classes with the actual service logic decoupled from mere service interfaces) open which should be instantiated when the service host starts.

Seems that WCF does not have a scenario built in which supports this out of the box.
How would I go about it?

When I am self hosting, I can derive a custom class from ServiceHost and add a Dictionary with the Business objects. This would incur threading issues I guess, which I would have to handle with manual synchronization, correct?

If we decide to host in IIS, how would I do it then, since IIS automatically takes care of creating an instance of the ServiceHost class, and thus I have not much of a chance to throw my own custom host in-between, do I?

Or is this a bad approach altogether. Any other ideas appreciated.

Answer 1

Is there actually a bottleneck with the stateless, session-free approach?

The pool of “business logic objects” doesn’t look like a good idea to me. You’ll face hard-to-debug concurrency issues.

Have you actually tested the following pattern?

• one business logic object per request, shortest lifetime as possible
• one SQL connection per business logic object
• stateless services

By experience with a test service, we find however, that using pure
Per-Call WCF services over HTTP perform poorly, with the largest time
lapse being the initialization of the SQL server connection.

Really, the SQL server connection shouldn’t be a bottleneck because of SQL Server connection pooling.