Scalability should be the primary concern in the ever-evolving landscape of technology and business. It helps increase the ability of the system without decreasing the performance.
Previously, we have discussed 5 things toxic to scalability. In this article, we will go deeper into five more things that can pose a threat to scalability. Let’s explore them below.
5 More Things Deadly to Scalability
Here are the rest of the 5 things that are deadly to scalability:
1. Slow Disk I/O – RAID 5 – Multi-tenant EBS
Disk is the grounding of all your servers and the base of their performance. True with larger and larger main memory, much is available in the cache, a server still needs to constantly read from disk and flush things from memory. So, it’s a very very important component to performance and scalability.
What’s Wrong with Raid 5?
Raid 5 was designed to give you more space, using fewer disks. It’s often used in a server with few slots or because ops misunderstand how badly it will impact performance. On a database server, it can be particularly bad.
All write see a performance hit. What’s worse is if you lose a disk, the RAID though technically still online, will perform SO SLOWLY as to be offline. And a rebuild takes many hours. Worse still is the risk to lose another drive during that rebuild. What if you have ordered a drive and it takes a couple of days?
RAID 10 is the solution. Mirror each set of two drives, then stripe over those. Even with only four slots available, it’s worth it. Good read performance, good write performance, and protection.
What the Heck is Multi-Tenant?
In the cloud, you share servers, networks & disks just like you do apartments in a building. Hence the name. Amazon’s EBS or elastic block storage, extends this metaphor, offering you the welcome flexibility of a storage network. But your bottleneck can be fighting with other tenants on that same network.
Default servers do have this problem; however, AWS has addressed this serious problem with a little-known but VERY VERY useful feature called Provisioned IOPS. It’s a technical name but means you can lock in reliable disk I/O. Just what the scalability doctor ordered.
2. Using the Database for Queuing
MySQL is good at a lot of things, but it’s not ideal for managing application queues. Do you have a table like JOBS in your database, with a status column including values like “queued”, “working”, and “completed”? If so, you probably use the database to queue work in your application.
It’s not a great use of MySQL because of locking problems that come up, as well as the search and scans to find the next task.
Scalability becomes key to your business, as your customer base grows. But it doesn’t have to be impossible. Disk I/O, caching, queuing, and searching are all key areas where you can make a big dent, in a manageable way. Juggle your technical debt too, and you’re golden!
3. Using Database for Full-Text Searching
Oracle has full text search support, why shouldn’t we assume the same in MySQL? Well MySQL *does* have this, but in many versions only with the old MyISAM storage engine. It has it’s set of corruption problems, and isn’t really very performant.
Better to use a proven search solution like Apache Solr. It is built specifically for search, includes excellent library support for developers of most modern web languages and best of all is easy to SCALE! Just add more servers on your network, or distributed globally.
For folks interested in the bleeding edge, Fulltext is coming to Innodb crash safe & transactional storage engine in 5.6. That said you’re still probably better off going with an external solution like Solr or Sphinx and the MySQL Sphinx SE plugin.
4. Insufficient Caching at all Layers
Cache, cache, and cache some more. Your webservers should use a solid memcache or other object cache between them & the database. All those little result sets will sit in resident memory, waiting for future web pages that need them.
Next use a page cache such as varnish. This sits in front of the webserver, think of it as a mini-webserver that handles very simple pages, but in a very high-speed way. Like a pack of motorbikes riding down an otherwise packed freeway, they speed up your web server to do more complex work.
Browser caching is also important. But you can’t get at your customer’s browsers, or can you? Well not directly, but you can instruct them what things to cache. Do that with proper expiration headers. Have your system administrator configure Apache to support this.
5. Too Much Technical Debt
Technical debt can bite. As you’re developing a new idea, you’ll build prototypes. As those get deployed to customers, change gets harder, and past things you glossed over because problems.
One team leaf, and another inherits the application, and the problems multiply. Over time you’re building your technical debt as your team spends more time supporting old code and fixing bugs, and less time building new features. At some point a rewrite of problem code becomes necessary.
Frequently Asked Questions (FAQs)
What Are the Risks of Scaling Too Quickly?
Scaling too quickly may help you develop a product quickly, but the product won’t provide value to customers as it will have little demand. The focus on the primary target audience and their needs in quick scaling is insufficient. As a result, there is always a high risk of failure.
What Is Lack of Scalability?
Lack of scalability means a system or technology can’t handle increased workloads without decreasing its performance. The lack of scalability limits the growth of a company within a small period.
What Is the Cause of Scalability Failure?
There can be several causes of scalability failure. In most cases, these issues arises form database limitations, application code, and other hardware resources.
To keep growing and performing well, businesses and developers need to focus on things that might slow them down. As scalability is the key to improving the system’s ability while keeping good performance, you need to focus on things that are deadly to scalability and eliminate them to get the best result. We hope you’ve found this guide helpful in determining things that you should avoid in scalability. If you have any confusion in your mind, feel free to ask in our comment section below and we’ll try to help you as long as we can. Thanks for reading!