I’m sorry, but this is going to be one of those long rants of mine.
The problem with 408
This is (sadly) a typical scenario: A client, or other luser of the interwebs, notices that a website shows HTTP error 408 instead of their favorite content. Oh no! “the remote server returned an error: (408) request timeout!” He or she then asks the web developer to make the bad error go away.
The “seasoned” web developer looks at the error logs, and notices an error: something to do with timeouts. Having no idea what it means, he or she googles the error, and voila! an article gives “the” solution for this type of error. It looks something like this:
Locate your nginx config file, or your
— some random “technical” article on the webphp.inifile, and increasemax_execution_time(or some variation thereof).
Usually the article will also include some helpful info on how to locate these files, and how to restart the server after you’re done editing them (as if you shouldn’t know this already).
Let’s think for a moment about what has happened here
Web servers (usually Apache, Nginx, etc) are configured by default to wait for the back-end (usually PHP) for about 15 or 30 seconds. If the script doesn’t respond in that time, the web server kills the script and sends the user on their merry way with an HTTP status code of 408.
When you increase that timeout limit, what you tell the server is that you’re OK with HTTP requests taking more than 30 seconds. Really? Are you really OK with this?
Do this right now: Count slowly from 1 to 30, to get a feel of what half a minute is like. Would you wait that long for a website to load? Unless you’re working for a government website, I’m guessing you probably care about SEO at least a tiny bit.
So please, next time you see a web script timing out, don’t just blindly increase timeout limits. Dig a little deeper in your log files, do some tests, debug a little. Does the issue occur with all scripts or just with some? What do the PHP-FPM logs say? Are the worker threads up and running? What’s the memory situation like on your server? Maybe add a few debug prints in your script, or do some profiling?
If you’re on a CMS like WordPress, try disabling some plugins. Switch to another theme. Tinker with your caches. Try to isolate the component that causes the issue.
Conclusion
I don’t know what’s wrong with your server. But I know it shouldn’t be taking over half a minute to respond to an HTTP request. So please, do your job as an engineer, and look for the root cause of the issue.
Same goes for maximum memory, worker threads count etc. Don’t just increase numbers at random. Look at your traffic first. What amount of worker threads do you need? What do your scripts need in terms of resources? You know that these things use CPU and memory, right?