Hi I'm new to production level web development, so sorry if this is obvious. My site has a potential to have a sudden surge of (permanent) users and I'm wondering what happens if too many users sign up in a short period of time, causing the site to run slowly. Since development takes time, would it just be a case of adding more boxes to the server, or does the site have to be taken down for code improvement? Thanks
+2
A:
Both but code improvement would be the first to target. Writing code that will scale will help you out the most. You can throw more servers at it behind the scenes but you would have to do this less with well architected code that was designed for scalability.
klabranche
2009-10-11 03:08:58
+2
A:
Depends on the technologies your using and how the code you write is written.
Since you tagged sql-server, when it comes to databases in general, you are limited by your locking strategies and your replication architecture a lot of the time. How you design your database and put it into production has big impact. Things that have to happen in any type of serial manner are bottlenecks. Check your execution plans, watch and manage your indexes, and replicate and distribute your systems if you can.
The best way to understand your scalability limitations is through load testing and proper QA.
If you don't do it right, your users are sure to be unhappy when you start 503ing or timing out. :-)
Zac Bowling
2009-10-11 03:09:54
I'm using Linq to SQL and SQL Server 2005. I'm trying to make my project as scalable as possible, but being new to this area makes it tricky. What's the best way to perform load testing, software-wise?Thanks
keyboardP
2009-10-11 03:27:59
Linq to SQL doesn't make it easy to tell what is going on all the time. A layered approach is good here. Entire books on the topic. You can automate your UI to test things from a high level. If you are writing your DB code into a business layer then write unit tests against that code and spin up threads to invoke things concurrently. Also check the SQL you generate with Linq-to-SQL and analyze the execution plan of that query to see your all locks and see if you need some indexes to get rid of any heavy full scans.
Zac Bowling
2009-10-11 03:34:25
+6
A:
Don't worry even very popular sites go through this. Coding well is always a plus, but sometimes even that is not enough. Twitter being an ideal example, they started their messaging on Ruby but had to move to Scala as they became more and more popular.
Since you say you are new, can I suggest getting yourself familiar with caching queries and caching static content? Learning about good indexing practices on SQL server should also be helpful in dealing with a large influx of users.
Jeremy Battle
2009-10-11 03:47:44
That is good advice; in terms of caching, you should look at memcache.
James McNellis
2009-10-11 03:49:22
+1
A:
If the site is developed in such a fashion that you can have multiple servers/data access layers, then scalibilty should not be an issue.
Create the app so that you can loadshed as required, and keep the code as flexible as possible.
But from past experiance. Performance tune once it is required. Write easily understandable and maintainable code, and fix performance issues as the occur.
astander
2009-10-11 04:26:52
+1
A:
The best advice I can give is to test your app and server before you go live, then you can see when you are likely to get problems and how bad they could be.
It is one thing to say 'it will go slow' but once you get past a certain point your app may crash or randomly give users error 500 pages.
Test with automatic scripts tools to stress the site and simulate sign-ups and random users visiting random pages.
If you have SSL make sure your tools simulate lots of different SSL connections rather than just different HTTP requests ( SSL handshakes take extra resources )
IanNorton
2009-10-11 07:34:02