-1

I was searching about the capacity of a web server in terms of how it can handle heavy traffic of server request, http request, even database queries or whatever you call them. I understand that a web traffic on a server can be measured by RPS(Request per Second) and as for example FB(Facebook) has a high-scalable datacenter which can handle hundred millions of request per second. Base on the article below under the typical load for a server. https://wrongsideofmemphis.wordpress.com/2013/10/21/requests-per-second-a-reference/

Assuming that for a normal server it would handle 2000 RPS. So what I would like to know is if the traffic request goes beyond the limit let's say 3000 RPS comes into the server. Would the server automatically crashed? or it will not crash but the excess requests will just be processed on the following tick of the second time clock?

Thanks...

4
  • It depends on the kind of application we are talking about. Database overload can easily make your server stop answering any requests at all, while a simple CPU overload would just make it slower. Your question is too broad, you should specify what technologies you use in your frontend/backend. There is no "universal" answer in your case...
    – Anubioz
    Jul 30, 2016 at 3:52
  • Sorry, but you are wrong in so many ways in your comment, that I wouldn't recommend to do any conclusions anytime soon. There is no such thing as "a generic web-application", f.e. you can call a joomla blog and a sharepoint server "web applications", but there is absolutely nothing common about them, besides they both can be accessed from your browser. And there is no amount of hardware that would make a badly designed application work fast.
    – Anubioz
    Jul 30, 2016 at 4:19
  • Right, I got your point now. I was only thinking that when the server crashed it will shutdown the whole thing on it but as you said that once the web server overloads its request then it will just suffer from hanging up the application by not responding on them or will make slower in some instances. Thanks
    – timmack
    Jul 30, 2016 at 4:25
  • Their behavior really depends on how those services are configured. It can crash/restart/hang/start serving cached content/reboot/shutdown/send sms/edit dns/anything. There is no "default behavior" when it comes to overloads to a whole application, while overloading a single component of it (i.e. database) will be defined by how this particular component behaves (considering its default behavior was unaltered)
    – Anubioz
    Jul 30, 2016 at 4:29

2 Answers 2

1

In a perfect world, for a basic static content web server

If the web server is configured and tuned properly within the limits of the OS and hardware it will be fine. No crashing, slowness, reboots, etc... Incoming connections will just hang because the server will not attempt to bite off more than it can chew. They will eventually be processed or timeout depending on how much time goes by.

This is a best case scenario for any overloaded server, even complex web application services. Unfortunately, with all the possible complexities things can crash, get slow, etc... when unforeseeable traffic/traffic patterns/whatever occur. But hopefully these services can be configured/tuned in advance to help prevent that from happening.

Your question is too broad to answer further than this

1
  • @timmack Instead of commenting 'thanks', please consider accepting the answer by ticking the check next to it.
    – grooveplex
    Aug 1, 2016 at 12:04
-1

The server will become slow, possibly to the point of not being able to manage it, depending on which device is the bottleneck.

The best conceptual model for thinking about this problem is to think of a computer as a series of processing units (aka servers, or centers), backed by queues (or buffers). Transactions arrive at the computer on one queue, are processed, and sent on to another queue.

For a web server, a "request" will arrive via the network interface and sit in the network interface buffer. The NIC will then process it, and send it to the CPU for further processing. At this point it will be passed on to the application, which means more CPU processing (i.e. straight back to the CPU queue), which then might require disk access (off to the disk queue, to be processed by the disk), back to the CPU, and finally back to the NIC.

The amount of work that each processing unit can handle (per second) is determined by the average time (in seconds) to process each transaction (Service Time). So if it takes 10ms on average for the CPU to handle a web-request, then the CPU can handle 100 RPMs (1000ms/10ms). If more than 100 RPMs were to arrive at the CPU, then the queue would start to grow, and it would keep growing until the TPS dropped back down below 100.

The actual time to process each request (Response Time) is given by: Service Time + Time waiting in the queue.

When there is no traffic and the server is completely idle, a request will pass right through without waiting in any queues, so Response Time = Service Time.

In your question, if the amount of traffic is 150% of capacity, then the queue will grow until it is eventually full. All processing queues have a limit, either determined by the amount of RAM in the box, or hardware queues in the case of NICs. At this point, Response Time will depend on the maximum length of the queue - a very long queue means very long wait times. If the queue length grows to be longer than the buffer can handle, then any incoming transactions will be dropped and will need to be resent.

If you try to log into the server at this point, then your login packets might get dropped as well. That would cause severe slowness in trying to access the server. If you need to establish a RDP connection then you will find that very slow and perhaps unusable.

The server itself won't crash, but if RAM is getting used by incoming requests, then the Out-Of-Memory Manager (OOM Killer on linux) will start to terminate applications. That could make it look like the server has crashed. Apache often uses a lot of memory in these situations as each incoming request uses a separate process, with its own memory requirements.

1
  • What's the reason for the downvote? Aug 3, 2016 at 11:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .