Premiers jours en ligne: comment ne pas tuer votre site

14

Supposons que vous ayez ce nouveau site sophistiqué, avec beaucoup de données (comme de grandes images), et que vous êtes sur le point de le mettre en ligne. Si vous faites "trop" de publicité, les premiers jours, le site sera submergé de demandes.

Comment puis-je atténuer ce risque?

J'ai pensé à

  • mise en ligne progressive, comme SO et SF: beta "privée", beta publique, publique
  • autoriser X Connexions sessions simultanées, donc l'utilisateur connecté a toujours une bonne expérience du site, et les autres ont un joli message d'excuses

Je ne peux pas:

  • acheter plus de serveurs, car après les premiers jours, le site aura beaucoup moins de trafic :)
performance  website  optimization  traffic 
— mathieu
source
6
Dans mes 15 ans de sites de développement et de publication. C'est ce que tout le monde pense ... mettre un nouveau site sur le we et boom! Cela n'arrive presque jamais. Habituellement, c'est l'inverse que vous obtenez moins que prévu. Mais bon, trop d'utilisateurs est un BON problème d'avoir;)
— Chad Grant
1
j'ai eu ce problème, et ce n'est pas un endroit très agréable pour être ...
— Gabriel Solomon

Réponses:

11
  1. Cachez autant que vous le pouvez. Toutes les pages créées dynamiquement doivent être mises en cache afin que les utilisateurs obtiennent une version statique. Dans les composants de page qui interrogent la base de données doivent également être mis en cache.
  2. Essayez d'utiliser un service externe comme Amazon S3 pour diffuser des images et du multimédia (ou préparez-le à être utilisé si le site subit soudainement une tonne de trafic).

La mise en ligne progressive peut fonctionner pour SOF et SF car ils avaient déjà une publicité et une demande intégrées, en raison de la popularité des blogs de Jeff et Joel. Si vous ne disposez pas d'une base d'utilisateurs presque garantie comme ils le faisaient, la mise en ligne progressive pourrait être fatale.

J'éviterais de limiter par des sessions simultanées, car il est difficile de définir la fin d'une session causée par l'inactivité. Si un utilisateur part pendant 15 minutes et essaie de recharger sa page, uniquement pour obtenir un message d'erreur - vous venez de perdre un utilisateur.

— Yaakov Ellis
source
Je voulais dire des séances, mais mes doigts signifiaient des connexions. Corrigée.
— mathieu
5

Quelle planification a été nécessaire pour votre modèle de données? Avez-vous conçu un schéma qui vous permettra d'augmenter votre volume de requêtes sans tri coûteux, colonnes binaires ou jointures complexes? Avez-vous réglé votre backend de base de données (en supposant que vous en ayez un)?

Comment servez-vous vos «grandes images»? Pouvez-vous diviser cela en un processus de serveur Web distinct, même un domaine distinct?

Avez-vous testé votre système en charge? Des outils comme ApacheBench et Siege sont inestimables.

Est-ce que toute votre configuration est en svn? Votre déploiement est-il automatisé? Vous en serez ravi lorsque vous devrez déployer notre application sur le 2ème serveur.

— Dave Cheney
source
J'étais d'accord avec les tests de charge, nous avions un site Web que nous avons ignoré les tests parce que nous étions dans un délai serré et que nous sommes revenus sur le cul. Et j'ai dû faire quelques bricolages pendant que le site était en ligne pour réduire la charge du serveur à un état gérable (nous avons atteint 200% sur la charge du processeur avec un serveur dédié à 4 processeurs)
— Gabriel Solomon
1

Un système d'invitation peut parfois être un bon moyen de contrôler l'utilisation d'un site par les utilisateurs. Distribuez un certain nombre d'invitations au début, afin que le site ne soit pas submergé. Donnez ensuite à chaque utilisateur quelques invitations à passer aux autres, en augmentant lentement le nombre d'utilisateurs sur le site. De cette façon, vous n'obtiendrez pas trop de personnes sur le site au début, et vous n'obtiendrez pas un pic de trafic massif.

L'inconvénient, bien sûr, est que vous pouvez refuser de nombreux utilisateurs au début qui n'ont pas d'invitations et qui ne reviendront pas plus tard. À moins que vous n'ayez un très bon site que les gens sont très excités à utiliser, cela pourrait être une mauvaise décision. Cela dépend vraiment du site. De plus, vous auriez en fait besoin d'un temps de développement supplémentaire pour ajouter un système d'invitation.

— Rich Adams
source
1

Je m'assurerais que vous disposiez d'une solide infrastructure de surveillance avant le lancement. Vous devez disposer de données sur lesquelles baser vos décisions - cela signifie mesurer la charge du processeur sur les serveurs, vérifier que votre charge est répartie uniformément sur les boîtes et que si quelque chose fond, vous savez de qui il s'agit.

Savoir où se situe le problème réduira considérablement le temps de réponse. J'ai vu trop de sites se lancer sans surveillance d'aucune sorte, avec l'intention qu'il soit mis en place plus tard ... après que l'incendie soit éteint. C'est profondément faux.

— Tim Howland
source
1

Vous voudrez peut-être examiner l'hébergement tiers de contenu statique tel qu'Amazon S3. En fonction de votre application, il peut être utile d'en cloud également (autant que je déteste le mot à la mode) à l'aide d'Amazon EC2.

— Adam Gibbins
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.