Scalability questions....

[smerf]

For the sake of argument, let's say I wrote an application that made
extensive use of web services. And, again for the sake of argument, let's
assume that the app became very popular and millions around the globe used
it daily.

I know how to write a webservice attached to a backend database for use by a
few people. But how do I write a data intensive webservice that can be
scaled to service thousands or millions of people?

How do you code in scalability? How do you scale up a webservice from a
single, hosted webserver to whatever it takes to handle thousands of
simultaneous requests? Do you add more webservers? If so, how and how do
they all service the same address?

As for the SQL Server backend... How do you scale the SQL Server backend to
handle millions of requests for such a webservice? There must be a limit to
the simultaneous requests a single instance of SQL server can handle - so
how do handle going from 50 users online to 500,000 users online?

I want to build an app for use online, but I don't want to box myself in -
just in case.....

 

[Bryan Phillips]

These are my rules of thumb:

1. Hardware code is faster than software code (i.e. hardware SSL is
faster than software SSL).
2. Use best practices starting at the server layer.
3. Don't rely on sticky sessions. Each client should be able to be
serviced by a different server on each roundtrip.
4. Make the calls as much as pass-through as possible.
5. Use caching where possible.
6. Do load testing.

BTW, SQL Server can handle many users if setup correctly. I worked for
a company that hosted WinAmp for a month back in the dotcom days. We
averaged 60 MB/sec of bandwidth and used SQL Server to log and analyze
the downloads.

Bryan Phillips
MCSD, MCDBA, MCSE
Blog: http://bphillips76.spaces.live.com

 

[smerf]

These are my rules of thumb:

1. Hardware code is faster than software code (i.e. hardware SSL is
faster than software SSL).
2. Use best practices starting at the server layer.
3. Don't rely on sticky sessions. Each client should be able to be
serviced by a different server on each roundtrip.
4. Make the calls as much as pass-through as possible.
5. Use caching where possible.
6. Do load testing.

BTW, SQL Server can handle many users if setup correctly. I worked for a
company that hosted WinAmp for a month back in the dotcom days. We
averaged 60 MB/sec of bandwidth and used SQL Server to log and analyze the
downloads.

Was that on a single server? Specs?

I am designing my app to be session-free (no loitering). You log in, get
verified, get data, get disconnected. The web server used otSQL Server
being used should not matter.

The clients will with the data locally and the rare data change should be
made via a single call to log the change on the servers at the time of the
local change (real time data updates). All SQL Servers should get the
update when it is submitted.

Is there a way to just throw hardware at the problem? I've heard of web
server load balancers made by Cisco for that kind of thing - I have no
specifics on them.

But, what about the database? How would you replicate the database among
multiple SQL Servers in real-time? How would you balance the calls from the
web servers to the SQL Servers?

I just want to make sure I have a plan in place. The last app I made was
made for 5 users (according to the specs I was given, only 5 managers would
use it). Within 1 week (just 5 days) they had over 2500 people on the
system (opened it up to subordinates). That was NOT in the specs I was
given.

Luckily, I kept the code fast and clean and we didn't need to change
anything to accomodate the users. The .Net app, the web server and the
Oracle backend worked great.

That app will not come close to the scale needed for the app I am coding
now. It will be open to internet users - so the scale could become very
large, very quickly.

Thanks for your help!

Smerf

 

[smerf]

WOW! What happened to my message? Looks like it got garbled on the way to
USENET, so here are some fixes for the screwed up message....

Was that on a single server? Specs?

I am designing my app to be session-free (no loitering). You log in, get
verified, get data, get disconnected. The web server used otSQL Server
being used should not matter.

The web server being used or the SQL Server it hits should not matter. No
session data is needed. All that is needed to submit a data change is a
username/password and the data being changed.

The clients will with the data locally and the rare data change should be
made via a single call to log the change on the servers at the time of the
local change (real time data updates). All SQL Servers should get the
update when it is submitted.

The clients will work with the data locally...

Thanks again!

Smerf

 

[Bryan Phillips]

The database setup was SQL Server 2000 on a single box with RAID 1+0.
Much of the database was updated only once per week so I moved those
tables to a separate database, removed all the unused free space on the
database pages, and made it read-only. Making a database read-only
disables locking and performs tremendously fast. Also, since multiple
database files were being used, it increased the number of threads that
would be spawned to find data.

The best site for all these tips is
http://www.sql-server-performance.com .

Bryan Phillips
MCSD, MCDBA, MCSE
Blog: http://bphillips76.spaces.live.com

 

[Chris Dunaway]

For the sake of argument, let's say I wrote an application that made
extensive use of web services. And, again for the sake of argument, let's
assume that the app became very popular and millions around the globe used
it daily.

I know how to write a webservice attached to a backend database for use by a
few people. But how do I write a data intensive webservice that can be
scaled to service thousands or millions of people?

How do you code in scalability? How do you scale up a webservice from a
single, hosted webserver to whatever it takes to handle thousands of
simultaneous requests? Do you add more webservers? If so, how and how do
they all service the same address?

As for the SQL Server backend... How do you scale the SQL Server backend to
handle millions of requests for such a webservice? There must be a limit to
the simultaneous requests a single instance of SQL server can handle - so
how do handle going from 50 users online to 500,000 users online?

I want to build an app for use online, but I don't want to box myself in -
just in case.....

I think your question requires much more discussion than can be
provided in a newsgroup post, but check out these links:

This link is Chapter 4 and talks about the actual deployment:

http://msdn.microsoft.com/library/en-us/dnbda/html/apparchch4.asp

This link is for the whole book:

http://msdn.microsoft.com/library/en-us/dnbda/html/apparchch1.asp

It is dated December 2002 so some of it may need revising, but I think
it could help you.

Chris

 

[Guest]

In addition, only you and your team can identify where your application’s
scalability bottlenecks are or will be. As pointed out in the references
Chris posted, some servers are clusterable. The clustering of servers allows
for load balancing of services. But in addition to clustering your servers
to improve quality of service you can also grid-enable your own services.
What we often see in a web services situation is that web application
builders provide a service that is computationally intensive; this may be the
creation of a PDF file, transformation of data, etc... These processes don’t
take long individually, however, when the requests are received in bulk, they
can cripple the web server. One solution to this problem is to move the
computations off the web servers and onto a back-end compute grid.

I do work for a grid computing company called Digipede Technologies. What I
like about the Digipede Network is the Digipede Framework SDK which allows a
developer to easily add the power of remote compute nodes to an application.
The Digipede Network is built on the .NET Framework which allows the product
to distribute .NET objects, so you can use the OOP methodologies you are
already comfortable with.

To find out more about the Digipede Network you can visit
http://www.digipede.net. It is very easy to request a product evaluation and
we also have a Developer Edition that is free to qualified developers.