Não tenho um quadro de referência em termos do que é considerado "rápido"; Sempre me perguntei isso, mas nunca encontrei uma resposta direta ...

OpenStreetMap parece ter 10-20 por segundo

A Wikipedia parece ter 30.000 a 70000 por segundo, espalhados por 300 servidores (100 a 200 solicitações por segundo por máquina, a maioria dos quais em caches)

Geograph está obtendo 7.000 imagens por semana (1 upload por 95 segundos)

Não tenho certeza se alguém ainda está interessado, mas esta informação foi postada sobre o Twitter (e aqui também ):

As estatísticas

• Mais de 350.000 usuários. Os números reais são, como sempre, super ultrassecretos.
• 600 solicitações por segundo.
• Média de 200-300 conexões por segundo. Aumentando para 800 conexões por segundo.
• O MySQL processou 2.400 solicitações por segundo.
• 180 instâncias do Rails. Usa Mongrel como o servidor "web".
• 1 servidor MySQL (uma grande caixa de 8 núcleos) e 1 escravo. Slave é somente leitura para estatísticas e relatórios.
• Mais de 30 processos para lidar com trabalhos avulsos.
• 8 Sun X4100s.
• Processe uma solicitação em 200 milissegundos no Rails.
• O tempo médio gasto no banco de dados é de 50 a 100 milissegundos.
• Mais de 16 GB de memcached.

Quando vou para o painel de controle do meu host, abro o phpMyAdmin e clico em "Mostrar informações de tempo de execução do MySQL", obtenho:

Este servidor MySQL está funcionando há 53 dias, 15 horas, 28 minutos e 53 segundos. Ele começou a funcionar em 24 de outubro de 2008 às 04h03.

Estatísticas de consulta: desde sua inicialização, 3.444.378.344 consultas foram enviadas ao servidor.

Total 3.444 M
por hora 2,68 M
por minuto 44,59 k
por segundo 743,13

Isso é uma média de 743 consultas mySQL a cada segundo nos últimos 53 dias!

Eu não sei sobre você, mas para mim isso é rápido! Muito rápido!!

Pessoalmente, gosto de ambas as análises feitas todas as vezes ... solicitações / segundo e tempo médio / solicitação e adoro ver o tempo máximo de solicitação além disso. é fácil inverter se você tiver 61 solicitações / segundo, você pode então inverter para 1000ms / 61 solicitações.

Para responder à sua pergunta, nós mesmos temos feito um enorme teste de carga e descobrimos que ele varia em vários hardwares da Amazon que usamos (o melhor valor foi a cpu média de 32 bits quando caiu para $$ / evento / segundo) e nossas solicitações / segundos variou de 29 solicitações / segundo / nó até 150 solicitações / segundo / nó.

Oferecer um hardware melhor, é claro, dá melhores resultados, mas não o melhor ROI. De qualquer forma, esse post foi ótimo, pois eu estava procurando alguns paralelos para ver se meus números estavam próximos e se compartilhavam os meus caso alguém estivesse olhando. O meu está puramente carregado tão alto quanto posso ir.

NOTA: graças a requisições / segunda análise (não ms / requisição) encontramos um grande problema de linux que estamos tentando resolver, onde o linux (testamos um servidor em C e java) congela todas as chamadas em bibliotecas de socket quando sob muita carga o que parece muito estranho. A postagem completa pode ser encontrada aqui, na verdade .... http://ubuntuforums.org/showthread.php?p=11202389

Ainda estamos tentando resolver isso, pois nos dá um grande aumento de desempenho, pois nosso teste vai de 2 minutos 42 segundos a 1 minuto 35 segundos quando isso é corrigido, então vemos uma melhoria de desempenho de 33% ... para não mencionar, quanto pior é o ataque DoS, mais longas são essas pausas para que todos os cpus caiam a zero e parem o processamento ... na minha opinião, o processamento do servidor deve continuar em face de um DoS, mas por algum motivo, ele congela de vez em quando durante o Dos às vezes até 30 segundos !!!

ADIÇÃO: descobrimos que era na verdade um bug de condição de corrida jdk ... difícil de isolar em grandes clusters, mas quando executamos 1 nó de dados do servidor 1, mas 10 deles, podíamos reproduzi-lo todas as vezes e apenas olhar para o servidor / datanode em que ocorreu. Mudar o jdk para uma versão anterior corrigiu o problema. Estávamos em jdk1.6.0_26, eu acredito.

Esse é um tipo de questão muito aberta, maçãs com laranjas.

Você está perguntando 1. a carga de solicitação média para um aplicativo de produção 2. o que é considerado rápido

Estes não se relacionam necessariamente.

Seu número médio de solicitações por segundo é determinado por

uma. o número de usuários simultâneos

b. o número médio de solicitações de página que eles fazem por segundo

c. o número de solicitações adicionais (ou seja, chamadas ajax, etc)

Quanto ao que é considerado rápido ... você quer dizer quantas solicitações um site pode atender? Ou se uma peça de hardware for considerada rápida se puder processar xyz # de solicitações por segundo?

Observe que os gráficos de taxa de acerto serão padrões sinusoidais com 'horários de pico' talvez 2x ou 3x a taxa que você obtém enquanto os usuários estão dormindo. (Pode ser útil quando você está programando o processamento diário em lote para acontecer nos servidores)

Você pode ver o efeito até mesmo em sites 'internacionais' (multilíngues, localizados) como a wikipedia

normalmente, menos de 2 segundos por usuário - ou seja, os usuários que veem respostas mais lentas do que isso pensam que o sistema está lento.

Agora você me diz quantos usuários você conectou.

Você pode pesquisar "análise de efeito slashdot" para gráficos do que você veria se algum aspecto do site de repente se tornasse popular nas notícias, por exemplo, este gráfico no wiki .

Os aplicativos da Web que sobrevivem tendem a ser aqueles que podem gerar páginas estáticas em vez de colocar todas as solicitações em uma linguagem de processamento.

Houve um vídeo excelente (acho que pode ter sido no ted.com? Acho que pode ter sido da equipe da web do flickr? Alguém conhece o link?) Com ideias sobre como dimensionar sites além do servidor único, por exemplo, como alocar conexões entre a mistura de servidores somente leitura e leitura-gravação para obter o melhor efeito para vários tipos de usuários.