Many years ago, developers saw a growth in traffic on the web and were appalled by how most websites poorly handled the spike. Moore's Law was still in effect, web servers were becoming faster every year, but software wasn't keeping up. So in response, Dan Kegel created a little place on the internet where developers could find the configurations needed to handle at least 10,000 concurrent connections.
To the best of my knowledge his article was written in 1999, and the web was very light weight in comparison. But with the dotcom going on, website were bloated with unnecessary fat. The C10k article was published right when the world needed it.
In 2016, the hardware is fantastically faster. The software, is just as amazing. YouTube serves billions of requests using Apache, MySQL and Python, some very common tools. Facebook also uses open source applications available to all of us to serve an unimaginable amount of content.
Software and hardware can handle way over 10,000 connections without a sweat. Yet, most website crash at the sight of 100 concurrent connections. It's hard to browse any small website featured on reddit or hackernews. The moment they are featured, they go out of service.
Most websites are hosted on shared platforms using CMS like Wordpress. Their owners have little to no technical background, and rightfully so. You don't have to be a developer or webmaster anymore to run a web space. Wordpress lowered the barrier of entry and everyone can own a very sophisticated website. The problem is, all those on shared hosting can't handle 100 concurrent users without crashing.
It's not a hardware problem since we've been enjoying doubling speeds every couple years for a few decades. It's not the software because the same tools are used to handle much more connections else where. The problem is still configuration.
A few years a go, I had a post going viral on reddit. The moment it reached 1000 concurrent connections, the server went out in flames. Every few minutes I would restart the server to allow a few more requests to go through before it crashed again.
My blogging engine had a few bugs that contributed to its downfall, but it certainly wasn't the only factor. There is nothing complex about fetching data from a database then displaying it on a page. Serving a few JPEGs here and there shouldn't compromise the whole operation. Yet here I was with a dead server.
Configuration
Unlike Dan Kegel's article, I don't think we still need to redesign the internals of the applications to better handle traffic. The good folks maintaining Apache, Nginx, PHP, MySQL, Python, and the many more, have done a good job optimizing the software. All we need now is to use this combinations of tools a little better to configure our servers by default.
Every web application has two distinct part. One dynamic, and the other static. The dynamic part puts all the information necessary to render a page together then serves that content. Naturally this part requires more CPU cycles. The static part consist of just serving files as they are to the user, with no changes.
In the optimal scenario, these two parts would be completely independent from each other. Making the user download scripts and assets, no matter how large they are shouldn't penalize the dynamic part that requires a lot more CPU cycles. So let's clearly separate them.
It is no longer a debate, nginx is better suited to serve static files. In known platforms like WordPress, Joomla, or Drupal, it wouldn't be too difficult for a shared hosting company to identify the folders that serve static files and serve them quietly using nginx. For the dynamic part, a version of wordpress baked with Memcached (or simply a plugin) would make it much faster, and easier on the CPU.
I recently used a WordPress plugin for editing images. It poses as an in browser image manipulator, but in the backend it resizes large images into smaller ones that fit the view and still look good. The non technical user uploads a picture from their phone directly into their website. What they don't know is that with those nice cameras we have today, an image can range from 2 to 6 megabytes. This is a burden for both the server and the user that has to download it. This plugin makes the image smaller by default, turning it into a couple hundred kilobytes. If the user really wants to serve a 6 megabytes file, then they can change the settings to do so. But the default is optimized for best performance.
When we give the user a one click install option to install wordpress, we are making the majority of decisions for them. We chose the best web server, the best database, the best OS, yet we don't configure it optimally for C10k. It is time to make strong and opinionated defaults.
By default the server should make the most of the CPU, RAM, and network. The casual user will enjoy the best of technology and the developers will get to tweak the settings to their own liking.
So yes. In 2016, we have the hardware for C10k, we have the software for C10k. We even have the right configuration to make it possible. Now what we need to do is to make those configurations the default.
Did you like this article? You can buy me a coffee.
Share your insightful comments here.
Comments(4)
Lewis Cowles :
I Love what you are saying. I'm pretty sure WP cannot C10k on a single cheap server.
Ibrahim :
You are right Lewis, it still can't. But It could with the right configuration.
mrpsycho :
so... what is solution? or what is topic about? just for words?
Ibrahim :
The last paragraph is the solution:
To make the default settings the most optimal.
Let's hear your thoughts