La maggior parte dei problemi più comuni di scalabilità dei siti Web

Vorrei aggiungere a quella cosa molto comune - l'ottimizzazione nel posto sbagliato. Ho visto tonnellate di articoli in giro che discutono le differenze di nanosecondi nei costrutti di sintassi PHP, ma molto meno che discutono su come progettare correttamente l'infrastruttura di caching per un'applicazione. Così come è stato già notato, test. Ma non solo test - profile e scoprire cosa esattamente è lento - è legato alla CPU? I / O vincolato? Legato alla memoria? Sono le query del database che ti portano giù, sta leggendo i file, sono i calcoli? Puoi eliminarlo o ripristinarlo in modo che funzioni più velocemente? Ecc. Non iniziare con "Usiamo NoSQL perché è più veloce". Cominciamo con "vogliamo fare questo e quello, quali sarebbero i colli di bottiglia? Come li eliminiamo? Come si comporterebbe se otteniamo tempi di 100 utenti?" Senza conoscere meglio il carico di lavoro e l'app, è difficile dire qualcosa di concreto, ma vorrei iniziare pensando a cosa è possibile memorizzare nella cache e come ridurre il filesystem / database / ecc. accessi e soprattutto modifiche (poiché anche quelle invaliderebbero le cache).

La trappola della scalabilità più comune non sta facendo i test di carico nelle prime fasi. Se imposti test che simulano qualcosa di simile al carico previsto all'inizio dello sviluppo, sarai in grado di rilevare e correggere eventuali ostacoli tecnologici o architetturali alla scalabilità prima che diventino troppo costosi da risolvere.

Alcuni buoni esempi di ridimensionamento con PHP: Tumblr , Flickr , Netlog

Il consiglio comune fornito sulla scalabilità:

• Rendilo semplice!
  Non esagerare o acquistare soluzioni personalizzate per i produttori.
• Architettura a zero condiviso
  Mantieni il tuo stato nel database e fuori dai server delle applicazioni (evita anche i dati di sessione sul server). In questo modo puoi facilmente aggiungere altri server di app, se necessario.
• Concentrarsi sulla memorizzazione nella cache front-end (file statico)
  Utilizzare un proxy inverso e successivamente su una CDN. Qualsiasi cosa non debba essere fornita dal server dell'app è meno carica su quel server.
• Misura il sistema reale
  Costruisci nel monitoraggio per sapere dove sono i colli di bottiglia. Assicurati di poter prevedere il carico futuro in base alle curve di crescita.
• Prestare attenzione al design del DB
  Adattare le query, utilizzare memcached per evitare qualsiasi interrogazione e frammentare i dati tra le istanze quando si esaurisce lo spazio di attesa su un'istanza DB (monitor per sapere ciò in anticipo) .

Alcune insidie:

• NoSQL vs SQL è un'aringa rossa.
  Tutti i big guys stanno eseguendo il loro core su database SQL. Usa NoSQL se sei sicuro che abbia senso, ma non usarlo presumendo che risolva i problemi di ridimensionamento. Non lo farà.
• Fai attenzione agli ORM.
  Sono pesanti sullo stato del server dell'app (contraddicono l'architettura shared-nothing) e richiedono che tu capisca non solo come regolare le query SQL, ma come regolare l'ORM su cima alle query SQL (in altre parole, semplificano solo le cose se le prestazioni non contano). Dai preferenza alle query disegnate a mano e all'uso liberale di memcached.
• Sistemi di templating / routing pesanti sul server. Mantieni il server deliberatamente leggero.
• Non preoccuparti delle prestazioni del codice riga per riga.
  Puoi sempre accedere e correggere gli hotspot in un secondo momento (usa xdebug o strumenti di profilazione simili). Avere un'architettura scalabile conta MOLTO più delle prestazioni del codice, quindi investi di conseguenza le tue capacità intellettuali.

L'unico vero modo per dire se hai problemi di scalabilità è testarlo, quindi prova presto, prova spesso come Michael Borgwardt dice .

Oltre a ciò, un motivo comune per cui i sistemi non scalano è a causa della contesa delle risorse. E questo di solito si mostra nel database --- cercando di leggere e scrivere allo stesso tempo. Quindi potresti pensare di utilizzare un approccio CQRS che disconnette il lato di lettura (Query) dal scrivi (Comando) lato.

Sii pronto a cogliere tutto. Se puoi partizionarlo su più host, sei molto più vicino a costruire qualcosa che può scalare.

Progettare anche per il caso di un milione di utenti e ridimensionare. Non progettare per 1.000 utenti e scalare.

Onestamente PHP e MySQL non sarebbero la mia scelta per farlo. Provare a fare i dati shared in MySQL è un dolore al collo.