Scaling Up: Baby Steps (a.k.a. Asking The Right Questions)

Before we actually get started hacking on our code, let’s make sure we’ve got the right questions asked and answered. We’re going to need some resources, the help of others in our organization, and probably some understanding of the current system structure before we’re successful in our goal.

Some of these questions may seem mundane, and others will be extremely important. But we must ask and receive answers to all of them, so let’s get started.

What is my bottleneck? This is the first, and most important question you need to ask yourself. If your bottleneck is the file system, optimize your code. If it’s the database, optimize your queries. The only real case in which an application should be scaled is due to load. When the load reaches or exceeds what the server can handle, and you’ve optimized your code, meaning the bottleneck is the server itself, then its time to scale.

Too many people make the mistake of scaling instead of optimizing. This is a dangerous mistake, because if your bottleneck is anything besides the server, scaling your application will not resolve the issue. It may even make it worse. Make sure you’re scaling for the right reasons!

Do I have the unconditional support of my management? Scaling up is one thing if the management backs it and sees it as important; it’s a whole other task if they do not. Make sure you’ve presented your case to them and that they’re behind it, as you’re going to need resources to accomplish this process.

What does my current application look like? Do you have a diagram of how the application is supposed to work? It doesn’t need to be picture-perfect UML, but you should have some idea of what the application looks like before you get started.

Why am I scaling this application? There’s a general consensus amongst developers that overly focusing on speed and scalability leads to disaster, but not focusing on these things also causes significant problems down the road. If you’re right now in the beginning stages of application development, scaling the application is probably not your chief concern; making it work is your main priority. However, if you have a functional application and you’re facing increasing load, scaling is something you’ll want to consider.

You’ll also want to take a close look at the reasons why your current setup is inadequate. Perhaps it’s because your application was featured on Facebook and your user base expanded from 1,000 a day to 100,000 per day. But perhaps there are performance enhancements that you haven’t made yet that would help reduce the load and in turn, the amount of equipment you’ll need to scale properly.

What do I want the setup to look like when I’m finished? Make sure that you have a clear impression in your mind of what the scaled application will look like. Lay out what severs you need, how many web servers, load balancers, database servers, memcached servers, etc. This is a vital step.

What services already exist that might make my scaling project moot? Can you use existing web services or “cloud” services? How about Akamai or Amazon’s EC2? This goes right into the next question…

How long will I need to remain scaled up? If you’re running a particular campaign or push that will draw lots of traffic, followed by a drop off in visitors, it might be wiser to use a cloud solution that can scale quickly and contract just as quickly, rather than investing in architecture yourself.

These questions will help determine the best way to scale, and also help produce the best way to accomplish that task. Make sure you’ve got answers to these questions before you get started.

Next, we’ll take a look from within, at our server configuration, and our own setup to see if there are ways we can improve the performance of our application and reduce the costs associated with adding new hardware.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

There are currently no comments.

Copyright © 2023 by Brandon Savage. All rights reserved.