Web server vs database server scaling

Every user interaction with a website, such as loading a page, clicking a button, or submitting a form, generates a request to the web server. These interactions are frequent and often involve static assets (like images, CSS, and JavaScript files), rendering HTML, and processing logic. As the number of users increases, the web server has to handle a rapidly growing number of these requests.

While many web requests may involve querying the database, they don't always result in database interactions. For example, pages with static content, content cached in memory, or content generated by the web server without requiring a database query won’t proportionally increase the database load. Additionally, many web requests might use the same data that can be cached on the web server, reducing the number of database queries.

Only dynamic content that requires data retrieval or storage will result in database queries. Since not all web interactions require new data from the database, the database load doesn't increase as rapidly as the web server load.

Initially, it's easier and more effective to scale web servers horizontally to handle increased traffic. The database server can handle a significant amount of load on its own due to its ability to manage data consistency, and because you can optimize performance through caching and other techniques. Once the traffic and data operations reach a certain threshold, you will need to consider scaling your database server as well.

The confusing 508 status code

Recently, UptimeRobot notified me that our site is down with HTTP status code 508 - Loop detected. The site recovered on its own after five minutes. On another occasion, a user reported seeing the message Resource Limit Is Reached when attempting to access our web app via a browser.

The standard definition of 508 says that it may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol and that it indicates that the server terminated an operation because it encountered an infinite loop. This was initially confusing, as I was not using any WebDAV and  the ini_set('max_execution_time', 300) in my PHP code would end hanging processes, which is consistent with the site recovering after 5 minutes.

Further research revealed that the 508 code could also signify that a Resource Limit Is Reached, a usage specific to CloudLinux environments, which deviates from the standard interpretation. In this case, Uptime Robot was applying the standard definition, whereas our hosting environment attributed a different meaning to the same code.

Ultimately, the issue was traced back to exceeding the maximum number of processes (NPROC) allocated to our web app. I am continuing to investigate the root cause.

Web app connection troubleshooting checklist

Basic:

1. Does your DNS A record point to the correct IP address?
2. Does DNS checker show mostly green marks for your domain and does it show the expected IP address?
3. Does ping <server IP address> get a response?
4. Has at least 4 hours passed since you updated the A record?
5. Does ping <domain name> show the expected IP address and get a response?
6. Is your web server running?
7. Is the web app called by your web server running?

Extra:

1. Check if the correct ports are open and listening.
2. Ensure no firewall rules are blocking access to the web server or specific ports.
3. Review web server logs (e.g., Apache, Nginx) for any unusual entries.
4. Verify that SSL certificates are valid and have not expired.