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

14

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.

goodguys_activate
la source
1
Regardez: highscalability.com
Casebash
Quelqu'un qui connaît Windows Server App Fabric et la mise en cache peut-il publier quelque chose ici? Je ne suis pas un expert dans ce domaine et je veux en savoir plus.
goodguys_activate
Que voulez-vous savoir sur AppFabric?
Henrik
Il y a quelques conseils sur la façon de mettre à l'échelle un site Web, consultez-le, y compris: niveau de script serveur de niveau frontal Modèle et niveau de conception de base de données Mise à l'échelle horizontale du serveur, Sharding Voir plus: olivetit.blogspot.com/2013/05/…

Réponses:

16

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.

Fishtoaster
la source
13

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;))
Henrik
la source
4

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.

Jé Queue
la source
0

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".

goodguys_activate
la source
1
Cette réponse a plus à voir avec les performances côté client et rien à voir avec l'évolutivité côté serveur.
Ken Liu
Je pensais plus dans le sens d'un niveau intermédiaire regroupant d'autres sources de données via HTTP. Azure Table, OData ne sont que quelques exemples ... Pour vous, c'est toujours le serveur qui indique au navigateur (javascript) ce qu'il doit faire.
goodguys_activate
0

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).

goodguys_activate
la source
2
Euh ... le DNS est-il vraiment un sérieux goulot d'étranglement pour vous? Je pense que ce serait l'une des dernières choses à optimiser.
Fishtoaster
@Fishtoaster - La partie vient d'être modifiée en gras. Je suis à l'origine un administrateur système et la sécurité DNS joue un grand rôle dans la validation SSL. Des problèmes de connectivité et de performances DNS se posent tels que: problèmes de routage BGP vers la SOA, problèmes avec Anycasting (pour les CDN), problèmes de latence, empoisonnement du cache, etc. J'ai écrit un outil d'analyse des meilleures pratiques DNS (niveau filaire) que je mettrai bientôt sur Internet. N'hésitez pas à l'essayer car il couvre la plupart des problèmes de connectivité que j'ai mentionnés. (ou envoyez-moi un e-mail et je vous expliquerai plus)
goodguys_activate
2
Je ne dis pas qu'il n'y a pas de problèmes de performances liés au DNS comme ceux que vous listez. Il me semble simplement que des préoccupations beaucoup plus fondamentales (accès à la base de données, mise en cache des pages, complexité de boucle de code simple, équilibrage de la charge du processus serveur, sélection du point de distribution du matériel, etc.) se poseraient et seraient résolues à plusieurs ordres de grandeur tout en évoluant avant DNS les questions liées à ce problème constitueraient un problème.
Fishtoaster
... Je suis totalement d'accord qu'il y a des choses plus importantes à s'inquiéter, comme vous le mentionnez. C'est peut-être pourquoi cette idée a une note de zéro :) .. mais là encore, je suis le seul à avoir répondu à cette question jusqu'à présent.
goodguys_activate
1
Les performances DNS peuvent certainement être un goulot d'étranglement massif - il pourrait ne pas y avoir beaucoup de différence entre le bon et le mauvais, mais parce que le DNS est touché à chaque appel (ou presque), il peut s'additionner très rapidement. Surtout lorsque vous vous lancez dans des cascades CDN modernes.
Wyatt Barnett
0

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.

msj121
la source