Are web applications limited by the amount of memory or by the speed of the database server on the server side?

Question

Many web sites mostly only do CRUD (create, read, update, delete) operations to the database for different URLs. Suppose that we have a 3-tier solution with the database server on a dedicated server and the web server on another server. This question is not about the database server, but the web server.

The web server use dynamic content so it execute some code for every request and is communicating with the database server.

What should be the limitations of the web server if the web applications aren't computation-heavy under heavy load? Shouldn't the web application be limited of the speed of the database server? or is it limited by the amount of memory? With the speed of CPUs today I don't think that the web servers CPU speed is the limitation.

For static content web servers like Nginx and Lighttpd the web server almost always use very little memory and are limited by the disk-IO speed. But how is it for dynamic content?

Answer 1

Depends on your setup. Assuming that you have separate servers for DB, separate servers for static files and perhaps separate memcache, then the web tier is definitely CPU bound (unless you're doing something really weird). Of course if you try to combine more than one of these services with the web server, then YMMV.

Note however, that there is question of the C10K problem, and unless you address it properly, web tier will be system resources bound.

Answer 2

It depends.

Firstly, applications are never limited by memory, disk, CPU and so on. Entire systems are. Usually for applications we use a different terminology, like CPU-intensive, memory-intensive and so on. You can also use terms like database-centric.

There are no general answers to your question, unfortunately. A web application that processes videos will be CPU-intensive, whereas a very large website using a in-memory queue or tons of caching would be memory-intensive, etcetera.

When we look at whole systems, instead, the answer becomes a bit more interesting. A bit on background: I've been a senior architect on several large web sites. The way the code is developed, in my experience, is the following:

1. The application is architected keeping in mind whether it's expected to be CPU-intensive or memory-intensive. Also, CDNs like Akamai are planned at this stage.
2. The hardware is planned on a tentative level under the assumptions of the architect.
3. The application is developed according to the architecture without major optimizations.
4. Profiling under load testing is performed. Major bottlenecks are identified and relevant optimizations are inserted the code base.
5. A new load testing round is performed and the hardware is adapted - ideally you want applications without bottlenecks -- the expected bottleneck would be the web server itself (e.g. Apache or IIS dies because of too many connections, independently of the application).
6. Based on the results of 4. and 5. and the traffic estimates, the number of webservers is decided.
7. At this point, since you can scale out web servers, the bottleneck will ultimately be the database server.

As you can see, the answer is not simple. There is no general steadfast rule in these systems and actually significant expenditure is expected in making sure that all possible bottlenecks are eliminated and the web application can withstand the expected traffic with ease.

Answer 3

You mean CPU-bound vs I/O-bound right? Memory access and I/O is the same due to virtual memory implementations and it's not possible to predict if some process is swapped out or not at any given moment.

Web servers are generally I/O bound which means that they spends most of their time waiting for network response from the backend server (database).

Think of it like this:

• If the system would go faster if you upgrade the CPU, then its CPU-bound.
• If better disks or network would make it better, then it's I/O-bound.
• If it swaps a lot, you need more RAM and it is I/O-bound or "buy more RAM-bound" :)

Again, people mostly talk about CPU vs I/O bound. Memory issues are included in the I/O bound concept:

The I/O bound state is considered undesirable because it means that the CPU must stall its operation while waiting for data to be loaded or unloaded from main memory or secondary storage.

Answer 4

Anything can be a bottle neck if it is inaddequate enough. If you lease space at a quality data center, you should be able to take care of the Internet connection and router hardware. Databases can be made to scale with hardware, some software versions (the free version of SQL Server has limitations regardless of hardware) design and performance tuning. Concurrent users on your web server will probably require more memory than anything.

We had a corporate time entry web app that would get over-loaded at the end of the month with everyone playing catch-up and doing edits. The web servers were load balanced. There was 1 db server (known as The Beast), 1-2 application server(s) and the web servers would vary from 2-4. The central office had several desktop application users, so they used up much of the first app server. The rough estimate was 70 concurrent users per web server. Eventually, the web servers evolved into virtual servers, to make it easier to add reduce servers and allocate resources. The database took a beating because this application put everything in the database including the settings for almost every object on every web page (pages were all customizable by analysts).

Answer 5

Please buy and read http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X immediately.

Here are some sources for the book.

http://www.google.com/search?client=safari&rls=en&q=schlossnagle+scalable+internet+architectures&ie=UTF-8&oe=UTF-8

All of your assumptions are wrong.

The bottleneck is the user's desktop.

Once you build enough stuff to get past the desktop download bottleneck, the next bottleneck that shows up is usually server-side memory. But that's easily solved with hardware. After that it's server-side processor time.