Quel hébergement pour un pic à 100k VU / jour ?
47 réponses
| Auteur | Message |
|---|---|
|
Bool
| Olivier 
Inscrit le : 09/05/2005 |
# Le 18/06/2009 à 23:05
L'optimisation frontend la plus importante : c'est 80% du temps de chargement d'une page (seuls 20% sont passés à générer la page côté serveur). C'est bien de passer du temps à gagner 3ms sur sa requete sql, mais passer une demi journée à gagner 600ms sur sa page d'accueil c'est plus productif non? Presque tout le monde est d'accord là dessus, mais là on mélange le confort utilisateur et la stabilité serveur. Bien qu'une amélioration d'un coté soit souvent bénéfique de l'autre, ça n'est pas toujours le cas. Je suis le premier à inviter mes clients à travailler le confort utilisateur, mais il faut re-situer le contexte ici : il s'agit d'un (petit) site qui risque d'essuyer un "énorme" pic de trafic (à son échelle) sur une longue période. L'objectif n'est donc clairement pas le confort pour le moment. Si l'utilisateur n'a pas accès au site, tu crois pas qu'il sera plus gêné que si la page met 5 secondes à s'afficher au lieu des 500ms (fortement) conseillées ? Je me répète : oui réduire les hits statiques inutiles et tirer profit des proxies et autres caches aide, mais chez la plupart de mes clients un hit "dynamique" a un impact serveur (en terme de consommation CPU ou mémoire) entre 20 et 100 fois plus important qu'un hit "statique". Donc quand les ressources serveur viennent à manquer (ce qui risque d'être le cas), je m'attaque d'abord au goulot d'étranglement, à ce qui bouffe 90% des ressources serveur, même si cela ne correspond qu'à 20% (et même moins) du temps de chargement pour l'internaute en condition "normale". Bref, il s'agit de deux problématiques bien différentes, même si on peut parfois faire d'une pierre deux coups. |
|
PyRoFlo
| Florent 
Inscrit le : 09/05/2005 |
# Le 18/06/2009 à 23:18 Olivier a bien résumé. Je prends note de toutes vos remarques mais mon objectif reste le même, à savoir garder le site disponible à tout moment pour chaque visiteur, même si le temps de chargement doit être plus important qu'à la normale. |
|
PyRoFlo
| Florent
Inscrit le : 09/05/2005 |
# Le 15/07/2009 à 22:01 Petit bilan : le serveur était très largement sur-dimensionné, tant mieux. |
|
PyRoFlo
| Florent
Inscrit le : 09/05/2005 |
# Le 15/07/2010 à 23:15 Juste pour info, cette année j'avais prévu de basculer sur Gandi avec 16 parts mais finalement je ne m'en suis pas servi, tout est resté sur le mutualisé chez OVH sans aucun problème ni alerte, ni ralentissement. |
|
MathieuC
| Mathieu 
Inscrit le : 15/07/2005 |
# Le 15/07/2010 à 23:16 |
|
krucial
| Jean Christophe 
Inscrit le : 09/03/2005 |
# Le 16/07/2010 à 02:17 Combien ? JC - Mes sites |
|
PyRoFlo
| Florent
Inscrit le : 09/05/2005 |
# Le 16/07/2010 à 03:12 112k VU / 300k PAP pour le 13 et 76k VU / 250k PAP pour le 14. |
|
allogarage
| Nicolas 
Inscrit le : 14/10/2008 |
# Le 16/07/2010 à 10:34
Bool a dit : Presque tout le monde est d'accord là dessus, mais là on mélange le confort utilisateur et la stabilité serveur. Bien qu'une amélioration d'un coté soit souvent bénéfique de l'autre, ça n'est pas toujours le cas. Je suis le premier à inviter mes clients à travailler le confort utilisateur, mais il faut re-situer le contexte ici : il s'agit d'un (petit) site qui risque d'essuyer un "énorme" pic de trafic (à son échelle) sur une longue période. L'objectif n'est donc clairement pas le confort pour le moment. Je ne crois pas : En faisant juste un audit du site de 3s: il y a 3 fichiers CSS et 10 images CSS qui peuvent être remplacés par 1 fichier CSS et 1 sprite CSS bilan 11 requêtes économisées. Même si ce sont des fichiers statiques, ca fait un gain de 85% et ca prend 10min. Les etags et expire headers mal configurés : au lieu de faire 1 requête, 1 visiteur qui a déjà vu au moins une page va faire quand même plus de 15 requêtes... Guide comparatif des garages automobiles |
)
Répondre
Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.