Non ho un quadro di riferimento in termini di ciò che è considerato "veloce"; Me lo sono sempre chiesto ma non ho mai trovato una risposta diretta ...

OpenStreetMap sembra avere 10-20 al secondo

Wikipedia sembra essere da 30000 a 70000 al secondo distribuito su 300 server (da 100 a 200 richieste al secondo per macchina, la maggior parte delle quali sono cache)

Geograph riceve 7000 immagini a settimana (1 caricamento ogni 95 secondi)

Non sono sicuro che qualcuno sia ancora interessato, ma questa informazione è stata pubblicata su Twitter (e anche qui ):

Le statistiche

• Oltre 350.000 utenti. I numeri reali sono come sempre, molto super super top secret.
• 600 richieste al secondo.
• Media di 200-300 connessioni al secondo. Picchi fino a 800 connessioni al secondo.
• MySQL ha gestito 2.400 richieste al secondo.
• 180 istanze di Rails. Utilizza Mongrel come server "web".
• 1 MySQL Server (una grande scatola da 8 core) e 1 slave. Lo slave viene letto solo per statistiche e rapporti.
• 30+ processi per la gestione dei lavori occasionali.
• 8 Sun X4100s.
• Elabora una richiesta in 200 millisecondi in Rails.
• Il tempo medio trascorso nel database è di 50-100 millisecondi.
• Oltre 16 GB di memoria cache.

Quando vado al pannello di controllo del mio host web, apro phpMyAdmin e faccio clic su "Mostra le informazioni di runtime di MySQL", ottengo:

Questo server MySQL è in esecuzione per 53 giorni, 15 ore, 28 minuti e 53 secondi. È iniziato il 24 ottobre 2008 alle 04:03.

Statistiche delle query: dal suo avvio, 3.444.378.344 query sono state inviate al server.

Totale 3.444 M
all'ora 2,68 M
al minuto 44,59 k
al secondo 743,13

Si tratta di una media di 743 query mySQL ogni secondo negli ultimi 53 giorni!

Non so voi, ma per me è veloce! Molto veloce!!

personalmente, mi piacciono entrambe le analisi fatte ogni volta .... richieste / secondo e tempo medio / richiesta e amo vedere anche il tempo massimo di richiesta oltre a quello. è facile capovolgere se hai 61 richieste / secondo, puoi semplicemente girarlo a 1000 ms / 61 richieste.

Per rispondere alla tua domanda, abbiamo eseguito noi stessi un enorme test di carico e abbiamo riscontrato che varia su vari hardware Amazon che utilizziamo (il miglior valore era la CPU media a 32 bit quando è sceso a $$ / evento / secondo) e le nostre richieste / secondi variava da 29 richieste / secondo / nodo fino a 150 richieste / secondo / nodo.

Fornire un hardware migliore ovviamente offre risultati migliori ma non il miglior ROI. Ad ogni modo, questo post è stato fantastico perché stavo cercando alcuni paralleli per vedere se i miei numeri erano nel campo da baseball e condividevano anche i miei nel caso in cui qualcun altro stesse cercando. Il mio è puramente caricato più in alto che posso.

NOTA: grazie a richieste / seconda analisi (non ms / richiesta) abbiamo trovato un grosso problema di Linux che stiamo cercando di risolvere dove linux (abbiamo testato un server in C e java) blocca tutte le chiamate nelle librerie socket quando sotto troppo carico il che sembra molto strano. Il post completo può essere trovato qui in realtà .... http://ubuntuforums.org/showthread.php?p=11202389

Stiamo ancora cercando di risolverlo poiché ci dà un enorme aumento delle prestazioni in quanto il nostro test va da 2 minuti e 42 secondi a 1 minuto e 35 secondi quando questo è risolto, quindi vediamo un miglioramento delle prestazioni del 33% ... per non parlare, peggio è l'attacco DoS più lunghe sono queste pause in modo che tutte le CPU scendano a zero e interrompano l'elaborazione ... secondo me l'elaborazione del server dovrebbe continuare di fronte a un DoS ma per qualche motivo si blocca di tanto in tanto durante il Dos a volte fino a 30 secondi !!!

AGGIUNTA: Abbiamo scoperto che in realtà si trattava di un bug di race condition jdk ... difficile da isolare su grandi cluster, ma quando abbiamo eseguito 1 server 1 nodo dati ma 10 di questi, potevamo riprodurlo ogni volta e poi guardavamo il server / datanode in cui si è verificato. Il passaggio da jdk a una versione precedente ha risolto il problema. Eravamo su jdk1.6.0_26 credo.

Questa è una domanda molto aperta dalle mele alle arance.

Stai chiedendo 1. il carico medio di richieste per un'applicazione di produzione 2. cosa è considerato veloce

Questi non sono necessariamente correlati.

Il numero medio di richieste al secondo è determinato da

un. il numero di utenti simultanei

b. il numero medio di richieste di pagina che fanno al secondo

c. il numero di richieste aggiuntive (es. chiamate ajax, ecc.)

Quanto a ciò che è considerato veloce .. intendi quante poche richieste può accettare un sito? O se un componente hardware è considerato veloce se può elaborare xyz # di richieste al secondo?

Tieni presente che i grafici della percentuale di risultati saranno modelli sinusoidali con "ore di punta" forse 2x o 3 volte la frequenza che ottieni mentre gli utenti dormono. (Può essere utile quando pianifichi che le attività di elaborazione batch giornaliere avvengano sui server)

Puoi vedere l'effetto anche su siti "internazionali" (multilingue, localizzati) come wikipedia

di solito meno di 2 secondi per utente, ovvero gli utenti che vedono risposte più lente di questa pensano che il sistema sia lento.

Ora dimmi quanti utenti hai connesso.

Puoi cercare "analisi effetto slashdot" per i grafici di ciò che vedresti se qualche aspetto del sito diventasse improvvisamente popolare nelle notizie, ad esempio questo grafico su wiki .

Le applicazioni web che sopravvivono tendono ad essere quelle che possono generare pagine statiche invece di inviare ogni richiesta attraverso un linguaggio di elaborazione.

C'era un video eccellente (penso che potrebbe essere stato su ted.com? Penso che potrebbe essere stato dal team web di flickr? Qualcuno conosce il collegamento?) Con idee su come scalare i siti web oltre il singolo server, ad esempio come allocare le connessioni tra il mix di server di sola lettura e lettura-scrittura per ottenere il miglior effetto per vari tipi di utenti.