Meilleures pratiques pour résister à l'éclatement du trafic le jour du lancement

Question

Nous travaillons sur un site Web pour un client qui (pour une fois) devrait générer beaucoup de trafic dès le premier jour. Il y a des communiqués de presse, les gens bloguent à ce sujet, etc. Je crains un peu que nous ne nous sentions pas à l'aise dès le premier jour. Quels sont les principaux éléments à surveiller pour garantir (à l’avance, sans données réelles sur le trafic) que vous puissiez rester debout après un grand lancement.

Détails: Il s'agit d'une pile L / A / M / PHP , utilisant un framework MVC développé en interne. Ceci est actuellement en cours de lancement sur un serveur, avec Apache et MySQL, mais nous pouvons le diviser au besoin. Nous sommes déjà en train d'installer memcached et de faire autant de cache que possible au niveau PHP. Certaines des pages sont plutôt gourmandes en requêtes et nous utilisons Smarty comme moteur de template. Gardez à l'esprit qu'il n'y a pas de temps à changer aucun de ces aspects majeurs - c'est juste la configuration. Quelles sortes de choses devons-nous surveiller?

Answer 1

Pour préparer ou gérer un pic de performance, je voudrais d'abord déterminer si vous êtes prêt pour quelques tests de performance simples avec quelque chose comme jmeter .

Il est facile à installer et à démarrer et vous indiquera si vous allez gérer une charge maximale attendue.

Toutefois, compte tenu de vos contraintes de temps, vous devrez également préparer des versions statiques du contenu qui attireront le plus l’attention (telles que les communiqués de presse, le cas échéant). Assurez-vous également que vous utilisez au mieux la mise en cache côté client (une demande de moins à votre serveur peut faire toute la différence). Le Web déjà conçu pour une extensibilité extrêmement élevée et une utilisation efficace de la mise en cache du contenu est votre meilleur ami dans ces situations.

Il existe un excellent podcast sur une évolutivité élevée sur radio d'ingénierie logicielle sur la conception du nouveau site Web Guardian lorsque la situation se sera calmée.

bonne chance pour le lancement

Answer 2

Mesurez d'abord, puis optimisez. Avez-vous fait des tests de charge? Où sont les goulots d'étranglement?

Une fois que vous connaissez vos goulots d'étranglement, vous pouvez décider intelligemment si vous avez besoin de boîtes de base de données ou de boîtes Web supplémentaires. Pour le moment, vous devinez.

En outre, comment vos résultats de test de charge se comparent-ils au trafic prévu? Pouvez-vous gérer deux fois le trafic attendu? 5x? Comment facile / rapide pouvez-vous acquérir & amp; libérer du matériel supplémentaire? Je suis certain que l'exigence commerciale est de ne pas échouer lors du lancement. Assurez-vous donc que vous avez beaucoup de capacité disponible, vous pouvez toujours le libérer après que la charge se soit stabilisée et que vous sachiez ce dont vous avez besoin. / p>

Answer 3

Je voudrais au moins factoriser tout contenu statique. Installez un autre vhost ailleurs et chargez tous les graphiques / css / js dessus. Vous pouvez acheter des cycles supplémentaires pour décharger la portion de ce type de contenu. Si vous êtes vraiment concerné, vous pouvez vous inscrire et utiliser un service de distribution de contenu. Il y a maintenant beaucoup de choses semblables à Akamai et assez bon marché.

Une autre idée pourrait être d’utiliser Apache mod_proxy pour conserver la sortie de la page générée pendant un laps de temps spécifique. APC serait également tout à fait utilisable. Vous pouvez utiliser la capture en mémoire tampon de sortie + la dernière heure de modification des données connexes sur la page, et utiliser la version en cache APC. Si la page n'est plus valide, vous régénérez et enregistrez à nouveau dans APC.

Bonne chance, ça va être une expérience d'apprentissage!

Answer 4

Ayez une période de bêta durant laquelle vous autorisez autant d'utilisateurs que vous le pouvez, mesurez les performances de votre site, résolvez les bogues avant de vous lancer.

Vous pouvez contrôler le nombre d'utilisateurs explicitement dans une version bêta privée ou une version bêta semi-publique de style Google dans laquelle chaque utilisateur dispose d'un certain nombre de références qu'il peut offrir à ses amis.

Answer 5

Je ferais personnellement quelques petites choses

1) Installez une sorte de système de réplication d'équilibrage de charge / base de données

Cela signifie que votre service peut être réparti sur plusieurs serveurs. Vous ne pouvez pas vous permettre d'avoir plus d'un serveur en permanence? Utilisez Amazon E3 - C’est bien pour la mise en place de choses comme celle-ci (activez quelques serveurs supplémentaires pour gérer la charge)

2) Code dans certains " Charge élevée " restrictions

Par exemple, si votre recherche est inefficace, désactivez-la lorsque la charge atteint un certain niveau. "Désolé, nous sommes occupés. Réessayez ultérieurement pour effectuer une recherche"

.

3) Charger le test ... Utilisez quelque chose comme ApacheBench pour tester vos serveurs.

4) Personnellement, je pense que le changement de "Keep-Alive" Les connexions sont meilleures. Cela peut réduire légèrement les performances globales, mais cela signifie qu'au lieu de créer un site qui fonctionne bien pour quelques personnes et que les autres ont des délais d'expiration, tout le monde reçoit un service incohérent s'il atteint ce niveau.

Le format Linux a fait un bon article sur "Comment survivre à un slashdotting" ... que j’ai trouvé utile par le passé. Il est disponible en ligne au format PDF

Answer 6

Premiers pas simples pour renforcer votre site lorsque le trafic est intense.

1) Utilisez un outil peu coûteux, tel que https://browsermob.com/ , pour tester votre charge. site. Au minimum, vous devriez rechercher 100 000 visiteurs uniques par heure. Si vous recevez une annonce sur la page d'accueil de MSN, pensez à pouvoir gérer 500 000 visiteurs uniques par heure.

2) Déplacez tout le contenu graphique / vidéo statique sur un CDN. Edgecast et Amazon sont deux excellents choix.

3) Utilisez Jet Profiler pour profiler votre serveur MySQL afin d’analyser les requêtes lentes. Des changements mineurs peuvent avoir d’énormes avantages.

Answer 7

Envisagez d'utiliser le Varnish - il s'agit d'un serveur proxy inverse en cache (comme squid, mais beaucoup plus) but unique). J'ai couru de très gros sites derrière ça, ça semblait vraiment bien fonctionner.