Que dois-je faire pour faire évoluer un site Web à fort trafic?

Quelles sont les meilleures pratiques à adopter pour un site Web qui doit "évoluer" pour gérer la capacité? Cela est particulièrement pertinent maintenant que les gens envisagent le cloud, mais peuvent manquer les fondamentaux.

Je suis intéressé à entendre parler de tout ce que vous considérez comme une meilleure pratique, des tâches de développement à l'infrastructure en passant par la gestion.

Conception pour l'accès simultané

Autrement dit, pendant que vous codez, prévoyez d'avoir plusieurs threads en cours. Planifiez l'état partagé (souvent juste la base de données). Planifiez plusieurs processus. Prévoyez une distribution physique.

Cela vous permet de distribuer votre système sur plusieurs machines et sur plusieurs processus avec équilibrage de charge. Il vous permet d'avoir des processus redondants en cours d'exécution en cas d'échec, et au cas où vous auriez besoin de modifier le système sur place, vous n'avez pas à tuer tous les services pour le faire.

Quelques éléments à considérer:

• Séparation des côtés lecture et écriture de votre stockage de données.
  
  • CQRS / Sourcing d'événements
  • CQS
  • Passage de messages / Acteurs
• Éviter le processus partagé et l'état du thread
  • Évitant ainsi le verrouillage
  • Vous pouvez éviter cela à travers le système de types en créant vos classes, structures et autres types de données pour qu'ils soient immuables, c'est-à-dire non changeants après la construction. Surtout pour les types de données abstraites complexes, cela fonctionne étonnamment bien (par exemple, l'implémentation de jQuery)
• Ne bloque pas les threads du serveur Web sur IO. Si vous utilisez ASP.Net, utilisez des pages / actions asynchrones avec le modèle APM / bibliothèque de tâches parallèles (TPL)
• Ne pas enregistrer de charges d'état dans le dictionnaire de session utilisateur
  • Cela doit être déplacé entre les threads lorsque des migrations de threads se produisent dans IIS.
  • Avoir un routage intelligent, de sorte que les ressources non sécurisées / statiques ne sont pas servies avec le même cadre d'application (par exemple ASP.Net) qui ajoute des frais généraux. Pensez à avoir différents serveurs Web, par exemple.
• Écriture de code de passage de continuation avec un modèle de flux de travail asynchrone (par exemple, bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Utilisez la théorie des files d'attente pour calculer où vos goulots d'étranglement peuvent se produire
• Utilisez des mises à jour push plutôt que pull pour les modèles de lecture et d'autres états d'application. Par exemple via RabbitMQ / nServiceBus
• Utilisez les «fonctionnalités les moins pertinentes» du gestionnaire http
• Pour les fichiers statiques, utilisez les e-tags et les politiques d'expiration du cache pour permettre à l'infrastructure Web de fonctionner comme il se doit (par exemple avec le proxy Squid)
• (Engagez-moi pour résoudre vos problèmes de mise à l'échelle et obtenir des didacticiels sur place;))

Partager l'architecture Nothing.

Dans cet esprit, et contrairement à ce que vous pourriez penser, ne passez pas immédiatement à une solution de mise à l'échelle. La surcharge hors système par rapport à un appel dans le système ne doit pas être sous-pondérée. Par exemple, il faut BEAUCOUP plus de temps pour établir une connexion DB sur n'importe quelle interface réseau que pour passer un appel local. Budgétisez le temps nécessaire à la gestion, à l'alimentation et aux efforts de réglage pour la mise à l'échelle par rapport aux dollars supplémentaires pour un vrai grand système.

Quoi qu'il en soit, il y a toujours une grande valeur dans les architectures «ne rien partager» et vous pouvez superposer et faire évoluer vos systèmes le moment venu.

Paralléliser les demandes sur plusieurs noms d'hôtes

Une partie de la norme HTTP est une section qui indique que les clients Web demanderont un maximum de 2 sessions par hôte DNS. Voici une solution où vous et votre alias sortez de votre www.domaine.com et obtenez une simultanéité de demande plus élevée, ce qui accélère le chargement de votre page:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Fondamentalement, cela implique de modifier votre gestionnaire HTTP ASP.NET pour alterner les hôtes cibles auxquels vous envoyez des clients, où chaque hôte est un CNAME à "www".

DNS sécurisé, rapide et fiable

J'ai trouvé quelques sites Web à haute capacité utilisant le serveur DNS du registraire, qui n'avait pas de SLA pour la disponibilité ou les performances. De plus, leurs serveurs étaient situés en Inde et la latence à elle seule augmente les chances qu'un usurpateur DNS puisse empoisonner le cache de votre client ou du FAI intermédiaire. Cela entraînerait même la redirection de votre trafic protégé par SSL sans que personne ne le sache.

La vitesse DNS affecte également le temps de chargement initial de votre serveur, avant la mise en cache des enregistrements.

J'utilise DynDNS ou Neustar pour la plupart de mes clients car ils ont une infrastructure DNS assez solide (même si c'est cher et je n'ai aucune autre affiliation avec ces entreprises).

Je pense que la clé va être simple:

Ayez un code simple. Cela signifie quelque chose que vous regardez et comprenez. Lorsque vous développez et changez de serveur, vous devez savoir ce qui se passe. Vous devrez peut-être également ajouter des codeurs qui doivent comprendre rapidement. Les crochets et les fichiers XML qui appellent du code aléatoire qui n'est pas évident sont très mauvais.

Ensuite, vous pouvez tester et trouver les problèmes.

Regardez ici: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

Nous , à essayer stellarbuild de faire en sorte que nos sites échelle sans temps d' arrêt. Cela signifie que vous devez pouvoir savoir ce que fait votre code et où il le fait. Même si vous testez une machine différente, vous ne pouvez pas prendre trop de temps pour évoluer. La plupart des gens ne commencent malheureusement que trop tard. Vous ne pouvez optimiser qu'une fois que vous faites cela à mon avis.