OpenStreetMap seems to have 10-20 per second

Wikipedia seems to be 30000 to 70000 per second spread over 300 servers (100 to 200 requests per second per machine, most of which is caches)

Geograph is getting 7000 images per week (1 upload per 95 seconds)

Not sure anyone is still interested, but this information was posted about Twitter (and here too):

The Stats

• Over 350,000 users. The actual numbers are as always, very super super top secret.
• 600 requests per second.
• Average 200-300 connections per second. Spiking to 800 connections per second.
• MySQL handled 2,400 requests per second.
• 180 Rails instances. Uses Mongrel as the "web" server.
• 1 MySQL Server (one big 8 core box) and 1 slave. Slave is read only for statistics and reporting.
• 30+ processes for handling odd jobs.
• 8 Sun X4100s.
• Process a request in 200 milliseconds in Rails.
• Average time spent in the database is 50-100 milliseconds.
• Over 16 GB of memcached.

When I go to the control panel of my webhost, open up phpMyAdmin, and click on "Show MySQL runtime information", I get:

This MySQL server has been running for 53 days, 15 hours, 28 minutes and 53 seconds. It started up on Oct 24, 2008 at 04:03 AM.

Query statistics: Since its startup, 3,444,378,344 queries have been sent to the server.

Total 3,444 M
per hour 2.68 M
per minute 44.59 k
per second 743.13

That's an average of 743 mySQL queries every single second for the past 53 days!

I don't know about you, but to me that's fast! Very fast!!

That is a very open apples-to-oranges type of question.

You are asking 1. the average request load for a production application 2. what is considered fast

These don't neccessarily relate.

Your average # of requests per second is determined by

a. the number of simultaneous users

b. the average number of page requests they make per second

c. the number of additional requests (i.e. ajax calls, etc)

As to what is considered fast.. do you mean how few requests a site can take? Or if a piece of hardware is considered fast if it can process xyz # of requests per second?

Note that hit-rate graphs will be sinusoidal patterns with 'peak hours' maybe 2x or 3x the rate that you get while users are sleeping. (Can be useful when you're scheduling the daily batch-processing stuff to happen on servers)

You can see the effect even on 'international' (multilingual, localised) sites like wikipedia

less than 2 seconds per user usually - ie users that see slower responses than this think the system is slow.

Now you tell me how many users you have connected.

You can search "slashdot effect analysis" for graphs of what you would see if some aspect of the site suddenly became popular in the news, e.g. this graph on wiki.

Web-applications that survive tend to be the ones which can generate static pages instead of putting every request through a processing language.

There was an excellent video (I think it might have been on ted.com? I think it might have been by flickr web team? Does someone know the link?) with ideas on how to scale websites beyond the single server, e.g. how to allocate connections amongst the mix of read-only and read-write servers to get best effect for various types of users.

I have a customer that uses our software on a commercial web app servers. The software runs on 40 servers. The software is a 10 year old Java API.

4000 TPS.