OVH Community, votre nouvel espace communautaire.

Performances du chargement des images


Blady
12/12/2013, 16h59
J'ai le même problème, je vais tester cette solution et faire un retour par la suite

Isendel
25/10/2013, 17h12
Super c'est une bonne nouvelle à quelques heures du week-end ^^

roadster
25/10/2013, 14h32
Je reviens comme promis, pour confirmer après un temps d'observation que le problème est résolu.

Merci à tous les participants au sujet.

roadster
23/10/2013, 00h38
Effectivement, boutique et blog on maintenant des performances tout à fait honorables. Merci à tous les participants à ce sujet, et au support OVH pour la solution, pas tout à fait triviale quand même.

@Nowwhat: pour faire du support moi-même dans divers forums, notamment celui consacré à Thelia, je comprends et apprécie ta démarche. Merci à toi pour tes efforts, et pour avoir pris le temps d'expliquer

Nowwhat
23/10/2013, 00h23
Citation Envoyé par roadster
Avec un montage réseau de DocumentRoot (par exemple NFS, SMB, CIFS, FUSE), le noyau peut s'avérer incapable de servir un fichier de ce montage réseau en passant par son propre cache.
Bingo.
Le VPS dans une grappe/cluster utilisent un disque 'commun', l'interface vers ce disque ne permet pas à Apache de contrôler le traitement au bas niveau d'un fichier.
De plus, entre vos 'serveurs' et le 'stockage' il y a bien sur un 'cache' que vous ne pouvez pas 'toucher'.
Plein des trucs qui peuvent conduire à des phénomènes 'pas évident'.

J'ai lancé ce test (une fois !)
Code:
mail:~# wget --no-cache http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
--2013-10-23 00:07:14--  http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
Résolution de www.espritcuir.com (www.espritcuir.com)... 37.187.67.202
Connexion vers www.espritcuir.com (www.espritcuir.com)|37.187.67.202|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 120039 (117K) [image/jpeg]
Sauvegarde en : «980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg»

100%[==================================================================================>] 120 039     --.-K/s   ds 0,007s

2013-10-23 00:07:14 (15,9 MB/s) - «980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg» sauvegardé [120039/120039]

mail:~#
Je présume que ça marche maintenant .... 0,007 sec me semble OK.

Avec mon FF j'avais pas de soucis sur ton site, je le trouve même rapide. Image, ou pas.

Le mot simplet n'est pas été à ça place
Nous, les lecteurs, on travaille avec les données que TOI tu as fourni.
De plus, avec 2 semaines d'expérience, ou 12 années, souvent on bloque sur ces propres questions, il nous faut une reset dans la procédure d'analyse.
Et comme d'hab, ceux qui te donnent les premiers réponses visent large (moi, à l'occasion), pour te 'provoquer' de donner plus d'info.
Jusqu'à qu'on trouve ....
(J'ai dépassé de loin l'age de traiter quelque de la sorte sans le connaitre - mais mes expériences avec " l'écrit " peuvent laisser quelques des fois doutes, ça, j'en conçoit )

CenT
22/10/2013, 18h55
Citation Envoyé par roadster
J'ai lu sur le sujet (ici http://httpd.apache.org/docs/current...enablesendfile) après avoir remarqué des status HTTP 206 (Partial content) sur le chargement des images. Je n'ai pas remarqué ces informations à propos de EnableSendfile :



Je suppose qu'un VPS entre dans au moins un de ces cas.

En tout cas, après ajout de la directive "EnableSendfile off", le problème semble résolu Je surveille, et je vous tiens au courant.
Salut,

Cette solution est la bonne, le support OVH me l'avais communiquer il y a quelques mois.

roadster
22/10/2013, 18h01
Ca roule, rendez-vous dans quelques jours (je me met un rappel pour être sûr de revenir conclure )

Isendel
22/10/2013, 17h42
Pour l'instant pour moi aussi ça tient la route, j'attends quand même quelques jours pour crier victoire.

roadster
22/10/2013, 16h49
J'ai lu sur le sujet (ici http://httpd.apache.org/docs/current...enablesendfile) après avoir remarqué des status HTTP 206 (Partial content) sur le chargement des images. Je n'ai pas remarqué ces informations à propos de EnableSendfile :

sur certains systèmes cependant, ou sous certains systèmes de fichiers, il est préférable de désactiver cette fonctionnalité afin d'éviter certains problèmes opérationnels :

Certains systèmes peuvent présenter un support sendfile défectueux que le système de compilation n'a pas détecté, en particulier si les exécutables ont été compilés sur une autre machine, puis copiés sur la première avec un support sendfile défectueux.

Sous Linux, l'utilisation de sendfile induit des bogues lors de la récupération des paquets de vérification TCP (TCP-checksum) avec certaines cartes réseau lorsqu'on utilise IPv6.

Sous Linux sur Itanium, sendfile peut s'avérer incapable de traiter les fichiers de plus de 2 Go.

Avec un montage réseau de DocumentRoot (par exemple NFS, SMB, CIFS, FUSE), le noyau peut s'avérer incapable de servir un fichier de ce montage réseau en passant par son propre cache.
Je suppose qu'un VPS entre dans au moins un de ces cas.

En tout cas, après ajout de la directive "EnableSendfile off", le problème semble résolu Je surveille, et je vous tiens au courant.

Isendel
22/10/2013, 16h39
Les premiers tests semblent ok chez moi mais j'en essaie d'autres...

Isendel
22/10/2013, 16h26
La réponse du support :
Pour ce soucis je vous conseil de mettre la régle suivante dans la configuration de apache :
EnableSendfile off
dans /etc/apache2/apache2.conf

Une fois le redemarrage de apache fait vous ne devriez plus avoir de soucis de wget.

Tu en penses quoi ? Je suis en train de lire la doc...

roadster
22/10/2013, 14h34
Il est codé comment ton script
C'est un shell tout bête: il appelle un script PHP sur le VPS, qui génère une liste de fichiers. Chaque fichier de la liste est ensuite chargé via http par wget -o /dev/null

Isendel
22/10/2013, 13h22
Je te tiens au courant sans faute !
Il est codé comment ton script de chargement des images ? Je te conseillerai un script d'appel des pages peut-être (même si je n'ai pas ce genre de script tout prêt en ma possession) parce que j'ai remarqué que la latence se produit aussi sur les feuilles de styles, les fichiers js... ce qui est logique et peut-être tout aussi gênant au chargement de la page.

roadster
22/10/2013, 12h49
Bon, ben on verra si quelqu'un daigne se pencher sur le problème chez OVH, là je suis en limite de compétence. En attendant, je vais mettre mon script de chargement des images en cron.

Je tiens tous les logs et fichiers de conf à disposition, si ça intéresse quelqu'un.

Merci de me tenir au courant Isendel. Tu crois que ce serait utile que j'ouvre un ticket moi aussi, avec les éléments que j'ai posté dans le sujet ?

Isendel
22/10/2013, 12h16
Je pense que si on gère des "gros sites" on ne voit pas forcément passer le problème car une fois le cache généré tout va bien, mais quand on est en face de développement ou même de production pour un petit site, c'est vite gênant car le cache qui plus est ne dure même pas une journée, le problème se reproduit parfois entre le matin et l'après-midi chez moi.

PS : Désolé pour les multiposts mais ça bouillonne dans ma tête à propos de ce sujet et j'aimerai bien trouver la solution depuis le temps que je me bas et que je cherche "quasiment" seul je suis heureux de voir quelqu'un d'autre aller dans mon sens...

Isendel
22/10/2013, 12h05
Moi ça donne ça c'est pas terrible je trouve :
Code:
wget http://www.monsite.com/images/google-maps.png
--12:02:39--  http://www.monsite.com/images/google-maps.png
           => `google-maps.png'
Résolution de www.monsite.com... 5.135.148.153
Connexion vers www.monsite.com|5.135.148.153|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 35,341 (35K) [image/png]

100%[=================================================================================================================================================>] 35,341        16.98K/s

12:02:42 (16.94 KB/s) - « google-maps.png » sauvegardé [35341/35341]
3 secondes pour 35ko on pourrait arrondir à 2 secondes en enlevant le temps de connexion... mais 16ko/sec de débit c'est nul !!!

J'attends la réponse du ticket incident il y a un soucis là...

Isendel
22/10/2013, 11h57
Je pensais aussi à Firefox au départ mais c'est facile à infirmer, ça le fait sur tout navigateur et effectivement une fois chargé la première fois ça rentre à la normale, mais ce qui est bizarre c'est que parfois ça reprend sur la page suivante, parfois non, mais si c'est un cache externe au VPS, un autre internaute l'a peut-être déjà généré.

roadster
22/10/2013, 11h45
J'ai fait un petit script sur mon dédié SP qui charge via wget toutes les images situées sur le VPS, et bien sûr, ça résoud le problème de performances, les images se chargent maintenant normalement.

Il y a donc un cache quelque part, ailleurs que sur le VPS.

Isendel
22/10/2013, 10h33
Moi j'ai exactement le même problème pour lequel j'essaie d'avoir des réponses depuis l'achat de mon VPS (il y a un mois maintenant).
Aléatoirement un site va être extrêmement lent à charger alors qu'un autre au même moment sur le même VPS sera nickel. Puis plus tard ce sera encore un autre site et ainsi de suite...
Ça fait plus penser à un problème de bande passante/et-ou/mise en cache et moi je suis en R3 non modifiée.
J'ai un ticket ouvert en court de traitement ce matin même pour tenter de résoudre ce soucis. Beaucoup de gens se plaignent de problèmes similaires, je pense qu'il y a autre chose...
Je te tiens au courant si j'en sais plus.

roadster
22/10/2013, 10h33
Hum! Hum! avec Firefox --> Adresse introuvable
Oups. Typo, désolé : la bonne adresse est http://www.espritcuir.com

J'ose penser que le problème pourrait se poser au niveau de ton Firefox sur ton PC.
J'ai investigué cette piste aussi. Du coup, je suis passé sur un de mes dédiés SP OVH, et j'ai fait un coup de wget:

Code:
wget --no-cache http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
--2013-10-22 10:29:40--  http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
Résolution de www.espritcuir.com... 37.187.67.202
Connexion vers www.espritcuir.com|37.187.67.202|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 120039 (117K) [image/jpeg]
Sauvegarde en : «980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg»

100%[============================================================================================>] 120 039     24,7K/s   ds 5,1s
117 Ko, 5,1 secondes !

Je recommence immédiatement après:

Code:
wget --no-cache http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
--2013-10-22 10:30:41--  http://www.espritcuir.com/client/cache/produit/980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg
Résolution de www.espritcuir.com... 37.187.67.202
Connexion vers www.espritcuir.com|37.187.67.202|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 120039 (117K) [image/jpeg]
Sauvegarde en : «980_580____1__portefeuille-frandi-23463g4-medium_2028.jpg»

100%[============================================================================================>] 120 039     --.-K/s   ds 0,01s
0,01s => normal !

C'est reproductible à tout les coups. La première fois, l'image est très longue à se charger (pourtant, c'est un fichier statique dans un répertoire tout bête, aucun traitement n'est effectué dessus). La seconde fois, le délai de chargement est normal.

Il semblerait donc que l'image aie été mise en cache quelque part. Mais ou ?

Gaston_Phone
22/10/2013, 10h22
Par contre, pour http://www.espritcuir.com les images se chargent très rapidement avec mon Firefox.

J'ose penser que le problème pourrait se poser au niveau de ton Firefox sur ton PC.

Gaston_Phone
22/10/2013, 10h20
Citation Envoyé par roadster
Pour les curieux: http://www.espricuir.com
Hum! Hum! avec Firefox --> Adresse introuvable.

Avec Safari aussi.

Gaston_Phone
22/10/2013, 10h18
Citation Envoyé par Nowwhat
Donc ce "Cloud" scan toutes tes requêtes http, filtre le client Web 'Firefox' et instaure une traitement spécial ? Uniquement CE image, toutes les requêtes de FF ?
Coté ton web server, pousse les logs plein ouvert pour voir si cette demande est traité autrement.

Je opte plutôt pour un mod_XXX qui foire - un cache qui se plante.

Dommage que t'as pas montré un lien d'exemple ... personne pourrait tester. Ni même 'OVH'.
Citation Envoyé par roadster
Bien sûr que non. Merci de ne pas me prendre pour un simplet, j'ai un diplôme d'ingénieur en informatique et 23 ans d'expérience du métier (ce n'est pas pour frimer, mais juste pour situer l'étendue de mon désarroi face au problème).
Je suis du même avis que Nowwhat.

roadster
22/10/2013, 10h16
Alors en ne conservant que le minimum de modules Apache (alias, authz_host, dir, fcgid, mime, ssl, suexec), le problème persiste.

roadster
22/10/2013, 09h35
Donc ce "Cloud" scan toutes tes requêtes http, filtre le client Web 'Firefox' et instaure une traitement spécial
Bien sûr que non. Merci de ne pas me prendre pour un simplet, j'ai un diplôme d'ingénieur en informatique et 23 ans d'expérience du métier (ce n'est pas pour frimer, mais juste pour situer l'étendue de mon désarroi face au problème).

"Cloud", c'est l'offre OVH: un "VPS Cloud 2".

un cache qui se plante
C'est possible aussi. Mais ce n'est sans doute pas un cache sur lequel j'ai une maitrise.

un mod_XXX qui foire
C'est possible. Je vais les désactiver un par un pour voir si le problème est causé par un module Apache.

Pour les curieux: http://www.espricuir.com

Nowwhat
22/10/2013, 08h00
Bonjour,

Donc ce "Cloud" scan toutes tes requêtes http, filtre le client Web 'Firefox' et instaure une traitement spécial ? Uniquement CE image, toutes les requêtes de FF ?
Coté ton web server, pousse les logs plein ouvert pour voir si cette demande est traité autrement.

Je opte plutôt pour un mod_XXX qui foire - un cache qui se plante.

Dommage que t'as pas montré un lien d'exemple ... personne pourrait tester. Ni même 'OVH'.

roadster
22/10/2013, 01h12
Hello,

Je viens de terminer l'install d'un VPS Cloud, en Debian Squeeze, avec ISP Config 3. C'est une config que je maitrise très bien sur un dédié classique.

J'y ai installé une boutique Thelia, et un Wordpress, auparavant hébergés sur un mutualisé OVH. La aussi, je maitrise les deux outils, qui sont correctement configurés.

Tout fonctionne parfaitement, sauf un truc: le chargement des images. Il s'agit d'images statiques toutes bêtes, des JPEGs de quelques dizaines de Ko.

Avec Chrome et Firefox, le chargement de ces images et extrêmement lent, et n'aboutit parfois jamais. Avec IE (10), le chargement est immédiat (~250 ms).

J'utilise l'URL directe vers le fichier, donc aucun traitement n'est effectué: Apache a juste à servir l'image, point.

Je n'arrive pas à comprendre ce comportement. Il n'y a rien d'anormal sur le serveur, les logs sont normaux, mais l'image n'arrive pas correctement. En mutualisé, ce problème n'existait pas.

Ce qui se passe avec Firefox: après presque 20 secondes, l'image n'est pas chargée.



Et la même image, dans IE, c'est bouclé en 250ms.



Je sèche sur pied, après avoir vérifié moulte fois les confs, les logs, etc.

Serait-il possible que ce soit dû à un bug des VPS Cloud ?

[EDIT] La solution ici : http://forum.ovh.com/showpost.php?p=575694&postcount=17