Comment faire face à l'explosion des visites ?

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.

 

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

 

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.

 

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.

 

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.

 

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