I’ve always been a big fan of fast cars. A 500-horsepower V8 engine with turbo boost? Just hush and take my money! Not enough? How about my house? In an ideal world, that would be me at the car dealership.
As a web developer, I’m beginning to realize that fast cars aren’t the only thing I’m obsessed with. Fast servers are my new love language. So what really makes these servers fast? Let’s talk about something called FastCGI.
FastCGI is a web server protocol that allows for faster communication between your web server and your application. It does this by keeping application processes alive between requests instead of starting a new request each time.
It’s not everything a server needs to be fast, but it’s a huge part of the equation. Stick around to learn more about FastCGI and why it’s so important in a web server and beyond.
-
Navigate This Article:
The Basics of FastCGI
FastCGI is pretty much an upgrade of the old CGI. Back in the day, CGI was a way for web servers to run scripts and generate dynamic content. But then, it had a big flaw: every single request made the server create a new process.
It’s like opening a new program every time there’s a new server request. The problem here was that servers were getting quickly exhausted.
Think of a situation where you have tons of visitors to your website. Opening a new program for each request would quickly break the server’s back.
And you know what happens when servers get exhausted? They begin to experience all sorts of issues. The most notable one is reduced processing speed.
That’s when websites would become annoyingly slow. Then the bounce rates increased. Sales declined. It was frustration galore.
Enter FastCGI, a savior. It fixed this issue by keeping the processes alive, or “persistent.”
FastCGI vs. CGI
We’ve already seen that FastCGI is a better version of the older CGI. To prove this point, I’ll review the key differences between these two.
Key differences:
- CGI creates a new process for each request, which slows down the servers. FastCGI, on the other hand, tends to avoid this by keeping processes running in the background.
- Since FastCGI reuses processes, it reduces the overhead of creating and destroying them. Since there’s no need to clear out excess stuff, communication between the server and the process is much faster.
- FastCGI can handle way more traffic than CGI. That’s obviously because it doesn’t need to start from scratch with every user request.
To sum it all up, FastCGI is like keeping your business doors open to the public. You don’t need to hire a security guard to respond to the door every time there’s a knock. Instead, whoever wants to enter just goes through the door and heads straight to the queue.
How FastCGI Works
To broaden your understanding of CGI, I’ll briefly explain how it works.
Persistent Application Processes
The phrase “persistent” in this context simply means keeping processes alive and running. In this case, the so-called persistence happens in the background.
If you’ve ever picked anyone up from the airport, you know exactly what I mean. First of all, nine times out of ten, they’re never on time. But you just can’t pull up at the pickup area and turn off your car’s engine while waiting to pick up your loved one.
You’ll likely get a ticket for that. If you’re lucky enough not to get ticketed, you’ll likely create unnecessary traffic. Then the honking starts. The frustration I talked about earlier follows next. In some cases, unnecessary road rage might ensue.
Here’s another scenario. Say you’ve arrived at the airport and your loved one, in their usual fashion, hasn’t yet made it to the pickup area. You don’t turn off your vehicle. Instead, you drive around to buy more time.
You keep the car running while at it. That way, you won’t need to restart it when your loved one finally shows up. That’s persistence right there.
Connection to the Web Server
FastCGI also handles connections with the web server. Keep in mind that creating a single connection actually benefits both the user and the server.
For some perspective, the single connection is like the server’s spokesperson. It makes sure that all questions (requests) travel through a single channel.
For the user, a single line of connection means faster speeds. That’s because the server isn’t getting distracted by other lines.
For the server, it means a lower chance of delays. Unfortunately, delays are what traditional CGI is known for.
Handling Requests
Because FastCGI handles user requests, it delivers responses faster than older versions of this program.
Let’s say you’ve filled out a contact form on a website. When you click on the submit button, that’s a request you’ve submitted to the server.
It’ll then process the request and respond either with a “thank you” message or something similar. Then, the server will notify the other side of a new message.
You can imagine what would happen without CGI. Yes, the server will receive your request. No doubt about that. But then it’ll lose its mind trying to process different requests at the same time.
Maybe you’re requesting a free quote. Someone else wants to connect with a customer service representative. Another visitor wants to leave a review. All these are happening at the same time.
Processing all these requests, and many more, can be chaotic. It’s even worse if the server has to open a new process every time there’s a new request.
Advantages of FastCGI
FastCGI has a lot of advantages, many of which are tied to what to expect from fast web servers. Here’s what I’m talking about:
Improved Performance
What makes FastCGI particularly stand out is the fact that there’s no need to constantly create new processes for each request. That’s because this protocol keeps processes alive and recycles them. Here, recycling basically means redirecting new requests to an already running process.
You don’t even need expert knowledge of servers to understand just how starting new processes can affect performance. In real life, you can use your phone as an example.
When your phone’s battery life is down to five percent, it can still last a couple of minutes and sometimes even hours if you don’t mess it with. Now try restarting the phone 10 to 15 times and see what happens.
Chances are, each restart will drain a lot of power from the phone’s battery. Phones, and servers, for that matter, usually have many processes going on in the background.
The more the restarts, the slower the performance.
Better Resource Utilization
Since FastCGI reuses existing processes, it doesn’t really need a lot of system resources. I’m talking about things like CPU, memory, and storage.
Don’t forget that system resources cost money. So it’s not just a matter of adding them when needed. You’ll need to do the math to determine if you can afford them.
To show you exactly what I mean, think of an online jewelry store as an example. Not everyone visiting the website will buy something. Some are just window shopping. Or is it browser shopping?
Others are probably benchmarking. A small fraction of them are likely web developers looking for design inspiration. Some really like your products or services but find them expensive. As a result, they decide to shop elsewhere.
My main point here is that not all traffic to your website will convert. However, each visitor still takes up system resources. Similarly, sometimes we upgrade server resources because we want to keep our websites and applications up and running when it matters the most.
You don’t want your website to crash when it’s supposed to make the perfect first impression. FastCGI can help you take advantage of your system’s resources better than its CGI counterpart.
Scalability
FastCGI offers persistent processes and reduced overhead, which make it easier for applications to scale. That’s particularly great for websites or apps that expect high traffic.
Think of an eCommerce store running a sale as an example. You anticipate an increase in sales when you run these offers. Of course, the higher the traffic, the higher your chances of converting it into sales.
And since you’ve hosted your website on a scalable platform, you won’t have to worry about manually adjusting the server’s resources to meet the increased demand.
The same applies when there are sudden traffic spikes. Because the server doesn’t get bogged down in creating processes from scratch, it can manage many simultaneous requests without breaking down.
Language Flexibility
The good thing about FastCGI is that it can work with many different programming languages. If you’re a web developer, you know how important that is. You want to work with something that’ll get along with whatever programming language you’re using.
The last thing you want to deal with is compatibility issues pre- or post-launch. Whether you’ve built your website or app using PHP, Python, Ruby, or another language, rest assured that FastCGI will work just fine.
Common Use Cases for FastCGI
Contrary to popular belief, FastCGI isn’t just a protocol that powers up websites and applications. Here are some common use cases.
High-Traffic Websites
Let’s begin with high-traffic websites because that’s the most common use case here. I’m referring to websites that get a lot of visitors at the same time, like news sites or eCommerce platforms.
As we’ve seen throughout this article, this protocol makes sure that the server can handle many concurrent users without slowing down or crashing.
Application Performance and Search Engine Optimization
There are certain web applications that deliver dynamic content, such as WordPress, Django, and other CMS platforms. Since FastCGI handles requests faster, that alone results in faster content delivery.
Many studies have shown that humans have a short attention span. Internet users, to be more specific, won’t wait longer than three seconds for a web application to load.
Using FastCGI can help reduce the chances of a high bounce rate (the rate at which visitors leave your webpage upon clicking on it).
The biggest issue with visitors leaving just seconds after opening a webpage is that it signals to Google and other major search engines that you’re not offering valuable content. The argument here is that if your website or application were that valuable, then visitors wouldn’t have a reason to leave just seconds after arriving.
What happens next is that search engines will begin to push your website or application further down the search results. At the same time, they’ll begin to prioritize websites with lower bounce rates.
Shared Hosting Environments
Shared hosting is the most common and affordable type of hosting out there. However, the biggest challenge with shared servers is that they tend to receive a lot of requests since there are many customers sharing the same hardware.
If, for example, one server has 100 customers and each customer has a website or app that attracts 30,000 average monthly users, you’re looking at about 3,000,000 monthly visits in total. And that’s not all; each visit also comes with many different types of requests.
When I talk about server requests, I’m not referring to the number of visits to a website or application. A server request is any action the user takes while on the platform. For instance, if they click on a news article, they’re submitting a request to the server to fetch it.
So what happens if a news article goes viral? Or a video on YouTube? The server may get millions of requests. The so-called “hug of death” is a very real phenomenon, where websites featured on major news outlets or by popular influencers get overwhelmed by the boost in traffic.
Since FastCGI reuses processes and reduces the load on the server, it can comfortably handle these requests without the server slowing down or crashing.
Later on, you’ll also learn how caching helps process requests faster.
Setting Up FastCGI
Getting FastCGI up and running requires some configuration. Here’s what to do.
Web Server Integration
First, you’ll need to enable FastCGI on your web server. However, how you go about it depends on the type of web server you’re working with.
- Apache: On Apache, for instance, you can enable it by installing the `mod_fastcgi` module.
- Nginx: On Nginx, you’ll use the `fastcgi_pass` directive in your server block to route requests to a FastCGI server.
- Lighttpd: Lighttpd also supports FastCGI out of the box. That said, you’ll still need to tweak its configuration file to define the FastCGI handlers.
Other languages, such as Python and Ruby, have their own ways of working with FastCGI. But you’ll likely need to use FastCGI-compatible frameworks or modules.
Configuring Applications
Applications built with certain programming languages, such as PHP, may need a specific setup to work with FastCGI. A common example is PHP-FPM, a FastCGI Process Manager.
You can use it to configure groups of persistent processes, also known as “pools.” It can also handle requests and specify settings.
Speaking of specified settings, we know that CGI keeps processes alive. That sounds good, but not for every situation.
Say you have an online store that’s still pretty new. No one, except you, your family, and maybe close friends, knows about it.
Your chances of receiving thousands of visits in the first few days or even months are pretty low. For this reason, reserving server resources isn’t really a good idea. It’s actually a waste of resources if you come to think of it.
When you reserve these resources, they become idle. Their job is to swing into action only when needed. And as they sit idle, the active resources may struggle to sustain the website.
Load Balancing and Caching
There’s no doubt that FastCGI helps servers handle high traffic. But that doesn’t mean it won’t break its back if the load is too heavy.
To keep this protocol working as it should, we use a technology called load balancing. This technology spreads the incoming requests across multiple FastCGI processes. That way, it prevents overloading a single FastCGI.
Caching is also another option here. By caching responses from FastCGI processes, the server can serve repeated requests faster and won’t need to rerun the same operations.
Challenges and Drawbacks
The performance benefits aside, you may bump into some drawbacks and challenges when using FastCGI.
Complexity in Setup
Setting up FastCGI isn’t as easy as traditional CGI. That’s because you must configure both the web server and the application to communicate properly. Otherwise, you’ll just have a system that processes requests and submits them to a server that doesn’t even understand what’s going on.
Additionally, in order to tune settings like process pools and memory limits, you should first understand how the application will behave under load.
You don’t want to set very high memory limits that the app will likely never achieve. You also don’t want to keep it too low and risk not allocating enough resources. And when you’re a beginner, figuring this out can be quite a challenge.
Debugging Issues
You may also have a rough time debugging issues. It’s like keeping a bunch of apps open on your phone instead of closing and reopening them every time you need them.
If one of the apps freezes, you likely won’t even realize it right away because it’s still technically running in the background. The next time you try to use it, it’s unresponsive. Next thing you know, you’re stuck wondering what went wrong. That’s the kind of problem developers can run into with FastCGI.
Then there’s also the issue of “hanging” processes and unresponsive requests. These mostly happen because FastCGI processes stay running between requests.
If a process gets stuck halfway through a task, it might still look like it’s working, but it actually won’t be doing anything useful. And since it’s hanging around between requests, the issue can keep popping up again and again. That makes it even harder to know what’s really wrong with it.
Logging and monitoring can help solve this issue. You’ll need to keep detailed logs of the app’s performance and then use them to spot when a process starts acting up.
Memory Leaks
So far, you know that a FastCGI process uses memory to handle a request. The memory used to process the request might be just a tiny bit of the server’s total memory.
But the real problem comes in when these tiny bits of memory begin to pile up. Over time, the server starts running out of memory. If you don’t understand what’s happening, that’ll surprise you. And believe me, I get it.
I mean, isn’t FastCGI meant to make your server process requests faster? How come CGI, something that’s associated with great processing power, suddenly slows down your system? “Make it make sense!” You say — don’t worry, I will.
One thing you need to realize is that once these tiny bits of memory continue to pile up undetected, the server might get sluggish or even crash. They are piling up because FastCGI doesn’t open new processes for every new request.
If your faucet lets out tiny drips, that may not be a problem. But if the drainage system is clogged, these drips will quickly fill the sink. With time, the water will spill over and cause flooding. The fix? Restart the processes regularly or set memory limits. Otherwise, you may be just one spill away from causing a flood.
FastCGI: The Protocol Every Server Needs
Perhaps the biggest lesson we’ve learned from FastCGI is that computers are actually more organized than we think they are. Who would have thought that these machines would have a communication protocol?
Memory? Yes. Storage? Sounds necessary. But a communication protocol?
I don’t even have one in my relationship. We sometimes talk over each other until someone finally decides to be the bigger person and listens.
So next time you visit a website or app that loads incredibly fast, chances are the server chose to be the bigger person by following a communication protocol called FastCGI.