Comment faire face à l'explosion des visites ?

[Josh Parker]

Bonjour,

J'ai ouvert un site au public qui était privé et ne rapportait rien. Après une bonne campagne, ça intéresse tout le monde.

Du coup on commence à voir les limites de notre serveur, ça rame.

Mes compétences techniques s'arrêtent actuellement à :
- Optimisation du site web (Xhtml, taille des pages globalement, lignes de codes)
- Serveur dédié haut de gamme chez un prestataire

Comment faire pour avoir un site qui ne ramouille pas à 5/10/30000 connexions par jours ?

Un peu bêbête je me demandais s'il ne fallait pas avoir un serveur pour mettre les script, un autre les images, le troisième les pages web....

Comment font les bons pros ?

Merci d'avance de la courtoisie dont vous ferez preuve à mon encontre

[skippyzrnr]

Déja une bonne optimisation de tes scripts et requetes peut aider à faire baisser la charge demandée a ton serveur pour le même nombre de visites. Si ca ne suffit toujours pas tu peux répartir tes applications entre différents serveurs.

[cedric_g]

Si tes pages sont basées sur du contenu stocké en base de données, tu peux utiliser un système de cache (comme Cache Lite) : ça accélère pas mal les choses et soulage bien le serveur...

[Josh Parker]

Oui j'ai remarqué que la feuille de style en bossant une journée dessus pour la réduire de moitié avec des cascades et des raccourcis à augmenter la rapidité de mon site par 2 alors qu'elle ne faisait que 13Ko et qu'elle est passé à 8Ko. Uniquement parce qu'il y a moins de ligne de codes à lire.

Ca me rassure de lire ça.

Le gros inconvénient c'est l'affiliation : ça plombe complètement le chargement.

[skippyzrnr]

Le gros inconvénient c'est l'affiliation : ça plombe complètement le chargement.

Et ca malheuresement tu pourras rien y faire.
Il parait que certain script de stats flinguent pas mal les performances aussi...

[kmenslow]

Le gros inconvénient c'est l'affiliation : ça plombe complètement le chargement.

Et ca malheuresement tu pourras rien y faire.
Il parait que certain script de stats flinguent pas mal les performances aussi...

Faire en sorte que le code de l'affiliation soit lu en dernier.

[Topsitemaker]

SI l'affiliation est en iframe, il y a rien à faire

Si c'est le chargement d'une image, tu mets une image transparent d'un pixel de la taille de la bannière puis à la fin de ta page téléchargé tu remplaces le pixel transparent par la vraie bannière à l'aide d'un script javascript.

[zim3]

C'est quoi comme affiliation?

Si c'est du xml que tu parses à la volée, tu peux cacher le résultat (une journée, une demi journée, une semaine)

Si c'est du xml+images, tu peux toujours cacher les images également.

[ltressens]

Exemple d'architecture d'un site à très forte audience :

un load balancer (type pound qui tient jusqu'à 500 req/sec),
des serveurs de cache en arriere du load balancer : ces serveurs servent les pages qu'ils ont en cache (idéallement bcp de ram sur ces serveurs et tout le cache dans un tmpfs, filesystem en ram).
quand la page n'est pas en cache : requete à un serveur de backend (c'est là qu'est rellement ton site).
Ce serveur de backend requete dans un pools de serveurs slaves en lecture seule de ta base de données.
Les slaves sont mis à jour par réplication d'une base de données maitre dans laquelle se font les écritures.

Ca c'est pour le html

Ensuite les images :
ideallement un serveur pour les "petits" éléments : thumbnails, css, js, servis par un lighttpd (plusieurs centaines de req/sec).

pour les plus gros éléments (images lourdes) :
un load balancer en tête, un pool de serveurs de cache avec un reverse proxy genre squid qui tapent dans le serveur maitre pour les images (serveur qui recoit les ecritures).

[Josh Parker]

Exemple d'architecture d'un site à très forte audience :

un load balancer (type pound qui tient jusqu'à 500 req/sec),
des serveurs de cache en arriere du load balancer : ces serveurs servent les pages qu'ils ont en cache (idéallement bcp de ram sur ces serveurs et tout le cache dans un tmpfs, filesystem en ram).
quand la page n'est pas en cache : requete à un serveur de backend (c'est là qu'est rellement ton site).
Ce serveur de backend requete dans un pools de serveurs slaves en lecture seule de ta base de données.
Les slaves sont mis à jour par réplication d'une base de données maitre dans laquelle se font les écritures.

Ca c'est pour le html

Ensuite les images :
ideallement un serveur pour les "petits" éléments : thumbnails, css, js, servis par un lighttpd (plusieurs centaines de req/sec).

pour les plus gros éléments (images lourdes) :
un load balancer en tête, un pool de serveurs de cache avec un reverse proxy genre squid qui tapent dans le serveur maitre pour les images (serveur qui recoit les ecritures).

Ca c'est de la réponse de pro que j'attendais , même s'il va me falloir des semaines pour comprendre ce que tu as dit

[NextGeneration]

Exemple d'architecture d'un site à très forte audience :

un load balancer (type pound qui tient jusqu'à 500 req/sec),
des serveurs de cache en arriere du load balancer : ces serveurs servent les pages qu'ils ont en cache (idéallement bcp de ram sur ces serveurs et tout le cache dans un tmpfs, filesystem en ram).
quand la page n'est pas en cache : requete à un serveur de backend (c'est là qu'est rellement ton site).
Ce serveur de backend requete dans un pools de serveurs slaves en lecture seule de ta base de données.
Les slaves sont mis à jour par réplication d'une base de données maitre dans laquelle se font les écritures.

Ca c'est pour le html

Ensuite les images :
ideallement un serveur pour les "petits" éléments : thumbnails, css, js, servis par un lighttpd (plusieurs centaines de req/sec).

pour les plus gros éléments (images lourdes) :
un load balancer en tête, un pool de serveurs de cache avec un reverse proxy genre squid qui tapent dans le serveur maitre pour les images (serveur qui recoit les ecritures).

Pour bien fixer les idées, je rajouterai que pour ce genre de config, faut injecter un max de pognon :

serveurs sql achetés ( 1600 euro piece pour avoir une bonne bête )
serveurs web idem
équipement de balancing
les serveurs de cache ( c'est cher la ram, quand on l'achete par 8Go )

et pour finir, le housing qui va bien ( 11 ou 12 U = 1/4 de baie ) + la connectivité.

Une belle facture d'un minimum de 6000 € de frais de départ + 700/mois pour le housing.

Les chiffres sont approximatifs mais le total est pas loin de la réalité.

[tofm2]

Exemple d'architecture d'un site à très forte audience :

un load balancer (type pound qui tient jusqu'à 500 req/sec),
des serveurs de cache en arriere du load balancer : ces serveurs servent les pages qu'ils ont en cache (idéallement bcp de ram sur ces serveurs et tout le cache dans un tmpfs, filesystem en ram).
quand la page n'est pas en cache : requete à un serveur de backend (c'est là qu'est rellement ton site).
Ce serveur de backend requete dans un pools de serveurs slaves en lecture seule de ta base de données.
Les slaves sont mis à jour par réplication d'une base de données maitre dans laquelle se font les écritures.

Ca c'est pour le html

Ensuite les images :
ideallement un serveur pour les "petits" éléments : thumbnails, css, js, servis par un lighttpd (plusieurs centaines de req/sec).

pour les plus gros éléments (images lourdes) :
un load balancer en tête, un pool de serveurs de cache avec un reverse proxy genre squid qui tapent dans le serveur maitre pour les images (serveur qui recoit les ecritures).

Pour bien fixer les idées, je rajouterai que pour ce genre de config, faut injecter un max de pognon :

serveurs sql achetés ( 1600 euro piece pour avoir une bonne bête )
serveurs web idem
équipement de balancing
les serveurs de cache ( c'est cher la ram, quand on l'achete par 8Go )

et pour finir, le housing qui va bien ( 11 ou 12 U = 1/4 de baie ) + la connectivité.

Une belle facture d'un minimum de 6000 € de frais de départ + 700/mois pour le housing.

Les chiffres sont approximatifs mais le total est pas loin de la réalité.

Tout cela est rigoureusement exact, mais c'est pour un site à 500k connections/jour, pas 30k comme indiqué au début. Attention à ne pas surdimensionner le truc...

A mon avis déjà, deux serveurs dédiés, un pour le web, l'autre pour le MySQL devraient déjà permettre de voir les choses différement, et surtout d'étudier quelque chose d'encore plus gros, au besoin. N'oublions pas que pour le moment, il n'est que débutant..

Josh Parker, envoie URL, pour avis..