Le applicazioni Web sono limitate dalla quantità di memoria o dalla velocità del server di database sul lato server?

Dipende dalla tua configurazione. Supponendo di avere server separati per DB, server separati per file statici e forse memcache separati, il livello Web è sicuramente vincolato dalla CPU (a meno che non si stia facendo qualcosa di veramente strano). Naturalmente se provi a combinare più di uno di questi servizi con il server web, allora YMMV.

Nota comunque che c'è una domanda sul problema C10K , ea meno che non lo indirizzi correttamente, il livello web sarà risorse di sistema vincolate.

Dipende.

In primo luogo, le applicazioni non sono mai limitate da memoria, disco, CPU e così via. Tutti i sistemi sono. Di solito per le applicazioni utilizziamo una terminologia diversa, come intensivo della CPU , ad alta intensità di memoria e così via. Puoi anche usare termini come database-centric .

Sfortunatamente non ci sono risposte generali alla tua domanda. Un'applicazione web che elabora i video richiederà un uso intensivo della CPU, mentre un sito Web molto grande che utilizza una coda in memoria o tonnellate di memorizzazione nella cache sarebbe ad alta intensità di memoria , eccetera.

Quando guardiamo interi sistemi, invece, la risposta diventa un po 'più interessante. Un po 'sullo sfondo: sono stato un architetto senior in diversi grandi siti web. Il modo in cui il codice è stato sviluppato, nella mia esperienza, è il seguente:

1. L'applicazione è progettata tenendo presente che è che si prevede che sia ad alta intensità di CPU o ad alto consumo di memoria. Inoltre, CDN come Akamai sono pianificati in questa fase.
2. L'hardware è pianificato a un livello sperimentale sotto le ipotesi dell'architetto.
3. L'applicazione è sviluppata secondo l'architettura senza grandi ottimizzazioni .
4. Viene eseguito il profiling sotto test di carico. I principali colli di bottiglia sono identificati e le ottimizzazioni rilevanti sono inserite nella base del codice.
5. Viene eseguito un nuovo round di test del carico e l'hardware viene adattato - idealmente si vogliono applicazioni senza colli di bottiglia - il collo di bottiglia previsto sarebbe il server web stesso (es. Apache o IIS muore a causa di troppe connessioni, indipendentemente dall'applicazione) .
6. In base ai risultati di 4. e 5. e alle stime di traffico, viene deciso il numero di server Web.
7. A questo punto, dal momento che è possibile scalare i server Web, il collo di bottiglia sarà in definitiva il server del database.

Come puoi vedere, la risposta non è semplice. Non esiste una regola generale costante in questi sistemi e si prevede che una spesa significativa si assicuri che tutti i possibili colli di bottiglia siano eliminati e che l'applicazione Web possa sopportare il traffico previsto con facilità.

Significa legato alla CPU e legato all'I / O, giusto? L'accesso alla memoria e l'I / O sono gli stessi a causa dell'implementazione della memoria virtuale e non è possibile prevedere se alcuni processi vengono scambiati o meno in un dato momento.

I server Web sono generalmente collegati all'I / O, il che significa che trascorrono la maggior parte del loro tempo in attesa della risposta di rete dal server di back-end (database).

Pensa in questo modo:

• Se il sistema andrebbe più veloce se si aggiorna la CPU, allora la CPU è vincolata.
• Se i dischi migliori o la rete lo renderebbero migliore, allora è legato all'I / O.
• Se scambia molto, hai bisogno di più RAM ed è legato I / O o "compra più RAM-bound":)

Ancora una volta, le persone parlano principalmente di CPU vs I / O. I problemi di memoria sono inclusi nel concetto I / O associato :

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.

Qualsiasi cosa può essere un collo di bottiglia se è abbastanza inadeguata. Se si affitta lo spazio in un data center di qualità, si dovrebbe essere in grado di occuparsi della connessione Internet e dell'hardware del router. I database possono essere realizzati in scala con l'hardware, alcune versioni del software (la versione gratuita di SQL Server ha limitazioni indipendentemente dall'hardware) progettazione e ottimizzazione delle prestazioni. Gli utenti concorrenti sul tuo server web probabilmente richiedono più memoria di qualsiasi altra cosa.

Avevamo un'app web per l'ingresso nell'ora aziendale che sarebbe stata sovraccaricata alla fine del mese con chiunque giocasse a recuperare e fare modifiche. I server Web erano bilanciati dal carico. C'era 1 server db (noto come The Beast), 1-2 application server (s) e il server web sarebbe varia da 2-4. L'ufficio centrale aveva diversi utenti di applicazioni desktop, quindi utilizzavano gran parte del primo server di app. La stima approssimativa era di 70 utenti simultanei per server web. Alla fine, i server Web si sono evoluti in server virtuali, per semplificare l'aggiunta di server di riduzione e allocazione delle risorse. Il database ha subito un duro colpo perché questa applicazione ha inserito tutto nel database, incluse le impostazioni per quasi tutti gli oggetti su ogni pagina Web (le pagine erano tutte personalizzabili dagli analisti).

Ti preghiamo di acquistare e leggere immediatamente link .

Ecco alcune fonti per il libro.

link

Tutte le tue ipotesi sono sbagliate.

Il collo di bottiglia è il desktop dell'utente.

Una volta creati abbastanza elementi per superare il collo di bottiglia del download del desktop, il collo di bottiglia successivo che si presenta è solitamente la memoria lato server. Ma questo è facilmente risolvibile con l'hardware. Dopo questo è il tempo del processore sul lato server.