Last post Jul 09, 2010 01:30 PM by RobHood
Jul 08, 2010 02:42 AM|walterh|LINK
Hi All, we have this web service that sends JSON code to an iPhone application.
Each time the app makes a request, the web serice accesses the database, grabs corresponding xml data, transforms it to JSON code and then sends it back to the app.
the xml data gets updated approximately every minute, you can assimiliate this process with a sport app of which you can watch live game commentaries.
Now the iPhone app is going to implement a refresh button which a user can proactivly hit it against the service to fetch the latest data.
So we need to implement something that is capable of handling multiple requests that could occur at the same time or in a very short period of time.
Does anyone have any suggestions?
Jul 08, 2010 05:20 AM|RobHood|LINK
Your question is wide; I am not sure if you are asking infrastructure wise, load balancing wise... I will answer from your web service structure wise.
Of course your web service will be hosted on a server, IIS; the server can handle multithreading; each call is a new thread; a thread can be divided into several threads running on several machines; so to handle your load, you have to have an idea about
how many hit you will have per second/minute...
Another aspect to look into is bottlenecks; it may be your disk access, or your database... Usually with high traffic, it is better to put some high demanding data in the server cache, so the application does not have to go fetch on the disk or the database
the same data for each request. Better to put data in a dictionary; that will make the access to it faster... but you have to pay attention to operations (Add/Modify key/Delete) on your data structure... Choose a data structure that fits your case.
For more information, help me understand your case better.
Jul 08, 2010 10:39 PM|walterh|LINK
Thanks for replying.
Yes, it's regarding to the web service structure.
Sorry, I didn't mention it in the first thread.
We did implement caches to handle data requesting, however as imaginable as it is the refresh button could produce massive of data requests in a very short period of time, say, an impetuous user could hit 5 times in 1 second the refresh button in order to
retrieve the latest data even there's not any.
We are unsure if there's a way that's better at handling such senario than cache. Any idea?
Jul 09, 2010 01:30 PM|RobHood|LINK
an impetuous user could hit 5 times in 1 second the refresh button
You can disable your refresh button until result is received.
a way that's better at handling such senario than cache
Cache is the best solution till date; but you can make the cache implementation better. First, the choice of web farm is important; some of them have advanced infrastructure that can handle your caching requirements. If you need some more info on this, let
Another aspect is sometimes worth the trouble is multi-threading. It can boost the performance and makes later fine tunning much easier. Let's say you create a thread that translates xml to json, another one to get the raw data, another one for authenticatication...
after looking at some statistics, the task that is taking the longuer time can be dedicated to a seperate machine or at least you can dedicate a CPU for the thread running that task.