* goraya wrote, On 30-7-2007 18:31:
On Jul 30, 6:45 pm, Jesse Houwing <jesse.houw...@nospam-sogeti.nl>
wrote:
>* goraya wrote, On 30-7-2007 15:23:
>>This is design level discussion about web applications. How I design
application that support 1 million concurrent requests??
Lot's of load balancing, caching and a fat pipe.
But the rest depends on what's behind your webservers. Will you need
database access, external systems, legacy systems? What's the nature of
the data you're accessing, highly dynamic or mostly static or a mix?
Will the site do personalization? Will the contents change based on the
current user? Does it need to be secured?
There are so many factors that come into play, that we need more
information. 1 million concurrent requests is quite enormous. Is that
really the target number? Because if that's true, you'll be looking at
more than 20 million concurrent users at least. What is it you're trying
to do?
Jesse
Thanks for ur reply.
I have a discussion with someone and he was asking me how to have a
web application that facilitate these number of people. I told him
that u should do with load balancing at ur servers. He insisted that
there are other design method that can increase the performance and
help out to facilitate large number of user. I just posted this
discussion here to get more information about this.
If u reffer some some good soure from where I get more information
over web application design, scalability ect.
Its nice to hear from u.
regards
As I said before, there are many things which will have influence on the
scalability of a web application. If you're just serving static content
you're all set with a couple of big raid equipped servers with loads of
memory to cache requests.
But when you're adding dynamic content you'll soon find out that there's
much more than just that. SQL Server can be scales out on it's own. You
can split up the contents into different databases, run in clusters etc
If you need access to legacy systems it's sometimes faster to create a
snapshot of the contents of that system in a modern databases and stream
the changes in as they come.
External services can use both caching and queuing where applicable.
You can find a lot of information in a number of white papers published
by Microsoft and their customers. Many of the companies running these
enormous websites also give presentations on Developer Conferences on a
regular basis. I've been to a presentation of the architecture of
MySpace. They've implemented their own caching strategy in between their
front end webservers that cut and paste parts of pages together to a
complete page from these caches. The caches get fed by another cluster
of webservices which render each part (comment blocks, profiles, forum
topics). The data comes from a number of different databases. One
cluster for profiles, one cluster for comments and each of these
clusters is split up into different smaller clusters based on the id
ranges of each of their main content. So there's a cluster serving
client profiles for client id 1-999999, one cluster serving 1000000 to
1999999 etc.
So your friend is correct to assume there are lot's of ways. But usually
they all come down to clustering, load balancing and skillful design of
the overall application.
One of the key things I've learned from the MySpace presentation is that
they create a new design every couple of years (sometimes even faster).
And when that one stops performing, they look at what they've learned,
redesign, reimplement, deploy and start the cycle again.
Jesse
