Concurrent pages served.

I recently had a 360 serving 30K requests/hour for a static page with no problems. For dynamic content, I manage a 720 that handles somewhere around 40K requests/hour with minimal load. I've also seen dynamic sites that could barely handle 1 user at a time. It really depends on the efficiency of the code and how well it caches information.

A lot :D

I have lighttpd on a Linode 1080 (actually using only ~700M of RAM, and that's with 64bit everything). On one freaky day, it served 1.8M static files (css, js, gif, jpg) and 60K dynamic pages (php/mysql) per hour.

The static file count could obviously go much much higher if the demand was there, since lighttpd wasn't even sweating at 500 requests per second, and that was all https. Dynamic pages were somewhat limited by the DB (each page involved a dozen queries, including at least one insert/update) but there was also room for more. The application was also of a rather inefficient kind, so it's possible that a well-written and well-cached application can push an order of magnitude more pages per second.

Linode 720. Nginx 0.6.32. A bit more than 2M HTTP requests/day. ~150,000 dynamic requests to a Drupal site running on PHP-FastCGI.

Yeah I am talking about the bad bad Drupal here. Front page listing the last 15 stories (+ a few sidebar items) = 300+ SQL queries!

Need to find time optimising the site :(

@scotty:

Linode 720. Nginx 0.6.32. A bit more than 2M HTTP requests/day. ~150,000 dynamic requests to a Drupal site running on PHP-FastCGI.

Yeah I am talking about the bad bad Drupal here. Front page listing the last 15 stories (+ a few sidebar items) = 300+ SQL queries!

Need to find time optimising the site :(
I just tested the cache module for Drupal with xcache and/or memcache on Lighttpd. This module makes use of not only the opcode cache but the var cache of Drupal. I'd say turning caching on via this way dramatically speeds up things for anonymous users, however you should test carefully if everything is okay.

I agree with Selfishman that it depends on the efficiency of the code and how well it caches information.

Here is my stats and obviously not great compared to what I am hearing

Linode 1080 with apache+memcache+eaccelerator - two tier architecture - 15-19pages per minute which is shameless low than the stats U all shared here.

We tried making it one tier (LAMP on one server) and that just did not improve any stats. I tried lighthttpd but our page request has more dynamic than static.

In any case, I am looking into optimizing the mysql DB. I will share with you all any updates.

I admin a heavily commented wordpress site. have it running on a cluster of 4 linodes for redundancy and scalability. We could run it on a single 720. but if one linode is good…more is better :-)

Site gets about 2 Million pages/day on a typical day, 5 Million or more on a big news day. Site ranks in top 4000 on alexa.

Oh, and its about 15 dynamic requests per second i think…not sure on the static content figures…but its much much higher.

@tazaspice:

I tried lighthttpd but our page request has more dynamic than static.

lighttpd's FastCGI (PHP) performance matches or exceeds that of Apache's mod_php, meaning that you get similar performance for dynamic content and better performance for static content. After all, just because your site is primarily dynamic doesn't mean that you don't have a bunch of static files (images/js/css/etc) to load.

On top of all that, you save a significant amount of memory that can be put towards caching.

Linode 720, Nginx, FastCGI PHP, TYPO3 site, half static, half dynamic

This leaves the load at about 2.5

siege -i -f mydomain.org.access.log -t 20s -d1 -c20

Lifting the server siege...      done.
Transactions:                    695 hits
Availability:                 100.00 %
Elapsed time:                  20.31 secs
Data transferred:               6.15 MB
Response time:                  0.08 secs
Transaction rate:              34.22 trans/sec
Throughput:                     0.30 MB/sec
Concurrency:                    2.58
Successful transactions:         675
Failed transactions:               0
Longest transaction:            0.88
Shortest transaction:           0.00

This leaves the load at about 3.5

siege -i -f mydomain.org.access.log -t 60s -d1 -c33

Lifting the server siege...      done.
Transactions:                   2579 hits
Availability:                 100.00 %
Elapsed time:                  59.96 secs
Data transferred:              21.24 MB
Response time:                  0.27 secs
Transaction rate:              43.01 trans/sec
Throughput:                     0.35 MB/sec
Concurrency:                   11.53
Successful transactions:        2510
Failed transactions:               0
Longest transaction:            2.27
Shortest transaction:           0.00