Primi giorni online: come non uccidere il tuo sito


14

Supponiamo di avere questo nuovo sito di fantasia, con molti dati (come immagini di grandi dimensioni) e che stai per metterlo online. Se fai "troppa" pubblicità, durante i primi giorni, il sito sarà sopraffatto dalle richieste.

Come posso mitigare questo rischio?

Ci ho pensato

  • andare a vivere gradualmente, come SO e SF: beta "privata", beta pubblica, pubblica
  • consentire X connessioni sessioni contemporaneamente, quindi l'utente connesso ha ancora una buona esperienza del sito e gli altri hanno un bel messaggio di scuse

Non posso:

  • acquista più server, poiché dopo i primi giorni il sito avrà molto meno traffico :)

6
Nei miei 15 anni di sviluppo e siti di rilascio. Questo è quello che pensano tutti ... metti un nuovo sito su di noi e boom! Non succede quasi mai. Di solito è il contrario che ottieni meno del previsto. Ma eh, troppi utenti sono un BUON problema da avere;)
Chad Grant,

1
ho avuto quel problema, e non è un posto molto piacevole per essere ...
Gabriel Solomon,

Risposte:


11
  1. Cache il più possibile. Tutte le pagine create dinamicamente devono essere memorizzate nella cache in modo che gli utenti possano ottenere una versione statica. Nella pagina i componenti che interrogano il db devono anche essere memorizzati nella cache.
  2. Prova a utilizzare un servizio esterno come Amazon S3 per pubblicare immagini e contenuti multimediali (o fallo pronto per l'uso se il sito viene improvvisamente colpito da un sacco di traffico).

Andare a vivere gradualmente può funzionare per SOF e SF perché avevano già pubblicità e domanda integrate, a causa della popolarità dei blog di Jeff e Joel. Se non hai una base di utenti quasi garantita come loro, andare a vivere gradualmente potrebbe essere fatale.

Eviterei di limitare le sessioni simultanee, poiché è difficile definire la fine di una sessione causata dall'inattività. Se un utente parte per 15 minuti e tenta di ricaricare la propria pagina, solo per ottenere un messaggio di errore: hai appena perso un utente.


Intendevo sessioni, ma le mie dita significavano connessioni. Corretto.
Mathieu,

5

Quanta pianificazione è andata nel tuo modello di dati? Hai progettato uno schema che ti consentirà di aumentare il volume delle query senza ordinamenti costosi, colonne binarie o join complessi? Hai ottimizzato il backend del tuo database (supponendo che tu ne abbia uno)?

Come servite le vostre "grandi immagini"? Puoi dividerlo in un processo server Web separato, anche in un dominio separato?

Hai caricato testato il tuo sistema? Strumenti come ApacheBench e Siege sono inestimabili.

Tutta la tua configurazione è in svn? La tua distribuzione è automatizzata? Ne sarai contento quando dovrai distribuire la nostra applicazione sul secondo server.


ho concordato con i test di carico, avevamo un sito Web in cui abbiamo saltato i test perché eravamo in una scadenza molto stretta e che è tornato e ci ha dato il culo. E ho dovuto fare qualche aggiustamento mentre il sito era attivo per riportare il server a uno stato gestibile (abbiamo raggiunto il 200% sul carico della CPU con un server dedicato a 4 CPU)
Gabriel Solomon,

1

Un sistema di invito a volte può essere un buon modo per controllare l'adozione da parte dell'utente di un sito. Distribuisci un certo numero di inviti all'inizio, in modo che il sito non venga sopraffatto. Quindi dai a ciascun utente alcuni inviti per passare ad altri, aumentando lentamente il numero di utenti sul sito. In questo modo non riuscirai ad avere troppe persone a colpire il sito all'inizio e non otterrai un picco enorme di traffico.

Il rovescio della medaglia ovviamente è che all'inizio potresti allontanare molti utenti che non hanno inviti e che potrebbero non tornare in seguito. A meno che tu non abbia un sito davvero buono che le persone sono molto entusiaste di usare, questa potrebbe essere una brutta mossa. Dipende davvero dal sito. Inoltre, dovresti effettivamente avere un po 'di tempo di sviluppo aggiuntivo per aggiungere un sistema di invito.


1

Mi assicurerei che tu abbia installato una solida infrastruttura di monitoraggio prima del lancio. È necessario disporre di dati su cui basare le proprie decisioni: ciò significa misurare il carico della CPU tra i server, verificare che il carico sia distribuito uniformemente tra le caselle e che se qualcosa si scioglie, si sa quale fosse.

Sapere dove si trova il problema ridurrà drasticamente il tempo necessario per rispondere. Ho visto il lancio di troppi siti senza monitoraggio di alcun tipo, con l'intenzione che verrà installato in seguito ... dopo che l'incendio si è spento. Questo è profondamente sbagliato.


1

Potresti voler esaminare l'hosting di terze parti di contenuti statici come Amazon S3. Potrebbe essere utile, a seconda dell'applicazione, anche offuscare alcuni (tanto quanto odio la parola d'ordine) utilizzando Amazon EC2.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.