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.