WCF - Solution Architecture

Question

0.00/5 (No votes)

See more:

Hi there,
I am working on a project in which a WCF service will be consumed by iOS apps. The number of hits expected on the webserver at any given point in time is around 900-1000. Every request may take 1-2 seconds to complete. The same number of requests are expected on every second 24/7.

This is what my plan:

1. Write WCF RESTful service (the instance context mode will be percall).
2. Request/Response will be in Json.
3. There are some information that needs to be persisted in the server - this information is actually received from another remote system - which is shared among all the requests. Since using a database may not be a good idea (response time is very important - 2 seconds is the max the customer can wait), would it be good to keep it in server memory (say a static Dictionary - assume this dictionary will be a collection of 150000 objects - each object consists of 5-7 string types and their keys). I know, this is volatile!
4. Each request will spawn a new thread (by using Threading.Timers) to do some cleanup - this thread will do some database read/write as well.

Now, if there is a load balancer introduced sometime later, the in-memory stored objects cannot be shared between requests routed through another node - any ideas?

I hope you gurus could help me by throwing your comments/suggestions on the entire architecture, WCF throttling, object state persistence etc. Please provide some pointers on the required Hardware as well. We plan to use Windows 2008 Enterprise Edition server, IIS and SQL Server 2008 Std edition database.

Thanks in advance!

Posted 9-Feb-12 5:15am

Rajeshjoseph

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2012-02-09T07:03:00

The item #4 is an invitation for a failure.

For a high-availability service, unpredictable number of threads is a big no-no. Besides, you already spawn a separate thread for some clean-up, why also a timer. A timer is even worse than thread in terms of reliability. Did you ever try to handle the situations where a timer event if fired when a handle triggered by a previous event is still running? This is solvable, but hardly worth the effort.

By the way, if you need to poll a database periodically or something, I have an improved schema combining timer and thread, where the timer merely sets the shared EventWaitHandle. Please see my past solution:
Polling Database with Timer[^].

This post also illustrates perhaps the best approach to threads on a server: you create just on thread "per-purpose" in the very beginning of the run time and throttle it with some thread synchronization object (in this case, in instance of EventWaitHandle) to keep it sleeping until there is a task for it.

In this way, the number of threads during run-time is not changed. The number of threads is either fixed or defined by configuration data and is kept fixed after the threads are created in the very beginning. Remember that the creation of a thread is also pretty expensive.

Another approach based on this idea is the blocking queue used to inter-thread communicate. Please see my Tips & Tricks article: Simple Blocking Queue for Thread Communication and Inter-thread Invocation[^].

—SA