G
goraya
This is design level discussion about web applications. How I design
application that support 1 million concurrent requests??
application that support 1 million concurrent requests??
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
J
Jesse Houwing
* goraya wrote, On 30-7-2007 15:23:
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
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
G
goraya
* goraya wrote, On 30-7-2007 15:23:
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
J
Jesse Houwing
* goraya wrote, On 30-7-2007 18:31:
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
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
G
goraya
* goraya wrote, On 30-7-2007 18:31:
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
Hi
Thank you for reply. As u said in your reply "but usually they all
come down to clustering, load balancing and skillful design of the
overall application".
What are the elements of skillful design?? This may a silly question
for u but I m quite new to design, especially for the designing of
large scale web application with dynamic contents.
Regards
J
Jesse Houwing
* goraya wrote, On 31-7-2007 10:22:
Well skillful design means that you try and solve all the bottlenecks
you can find, don't overdesign, because that's hard to refactor when
your app needs to be changed due to new information. Make the app
layered so you can cluster & load balance on each layer. Try to cache as
much as possible, make sure you design your pages, usercontrols etc to
allow for that.
And that's only the start. For more information go through the
Whitepapers on the Microsoft websites. You're bound to find more
information on how they fixed the problems they had. And how they weiged
one solution over the other.
Jesse
Hi
Thank you for reply. As u said in your reply "but usually they all
come down to clustering, load balancing and skillful design of the
overall application".
What are the elements of skillful design?? This may a silly question
for u but I m quite new to design, especially for the designing of
large scale web application with dynamic contents.
Regards
Well skillful design means that you try and solve all the bottlenecks
you can find, don't overdesign, because that's hard to refactor when
your app needs to be changed due to new information. Make the app
layered so you can cluster & load balance on each layer. Try to cache as
much as possible, make sure you design your pages, usercontrols etc to
allow for that.
And that's only the start. For more information go through the
Whitepapers on the Microsoft websites. You're bound to find more
information on how they fixed the problems they had. And how they weiged
one solution over the other.
Jesse
B
Bob Johnson
RE:
<< What are the elements of skillful design?? This may [be] a silly
question.. >>
Skillful design almost always comes down to keeping things simple and
sticking with the fundamentals. I have worked extensively with beginners
over the years, and have been hired many times to help solve problems
created by beginner programmers. The common theme I see amongst their
terrible products is that they make things overly complex or somehow get
away from well known and well documented fundamentals. Database design is by
far the easiest place to go wrong with respect to good design. Thanks in
large part to MS Access (which makes it very easy to go wrong), many
beginners think of a database as being a spreadsheet. They never take the
time to learn relational database design and the "normal forms" of which the
first 3, at a minimum, should be adhered to. With the database completely
screwed up (because they essentially implement a "spreadsheet design" rather
than a normalized design) the very foundation of the system they are
building is completely unstable, lending itself to massive data integrity
problems and runtime performance problems. Then proper application layering
doesn't happen (again, because MS Access encourages beginners to bind the UI
directly to the underlying table structure).
I could go on and on. But those two issues (database design and application
layering) are lost on most beginners. Learn the fundamentals. Stay with
them. Wandering off into the "creative realm" without first nailing down the
fundamentals and adhering to well-documented standards and best practices
will almost guarantee (IMHO) that you're making a major mistake and that you
are going to screw up performance, data integrity, extensibility, etc.
-"Bob"
<< What are the elements of skillful design?? This may [be] a silly
question.. >>
Skillful design almost always comes down to keeping things simple and
sticking with the fundamentals. I have worked extensively with beginners
over the years, and have been hired many times to help solve problems
created by beginner programmers. The common theme I see amongst their
terrible products is that they make things overly complex or somehow get
away from well known and well documented fundamentals. Database design is by
far the easiest place to go wrong with respect to good design. Thanks in
large part to MS Access (which makes it very easy to go wrong), many
beginners think of a database as being a spreadsheet. They never take the
time to learn relational database design and the "normal forms" of which the
first 3, at a minimum, should be adhered to. With the database completely
screwed up (because they essentially implement a "spreadsheet design" rather
than a normalized design) the very foundation of the system they are
building is completely unstable, lending itself to massive data integrity
problems and runtime performance problems. Then proper application layering
doesn't happen (again, because MS Access encourages beginners to bind the UI
directly to the underlying table structure).
I could go on and on. But those two issues (database design and application
layering) are lost on most beginners. Learn the fundamentals. Stay with
them. Wandering off into the "creative realm" without first nailing down the
fundamentals and adhering to well-documented standards and best practices
will almost guarantee (IMHO) that you're making a major mistake and that you
are going to screw up performance, data integrity, extensibility, etc.
-"Bob"
G
goraya
Thank You Jesse and Bob.