1/10 des images ne se chargent pas!

Sylphide666 · 06/11/2011, 18h23

Bonjour,

Je viens de configurer un nouveau serveur dédié (xeon first http://hosteur.com/serveur-dedie/) avec apache 2.2 sous Debian 6.

Tout semble bien fonctionner, sauf que je ne sais pour quelle raison, des images ne se chargent pas ou très lentement. Voici les cas de figure possibles (avec le résultat correspondant dans la capture wireshark/tcpdump) :

- l'image se charge correctement et rapidement -> http 200 OK
- l'image se charge lentement mais jusqu'au bout -> http 200 OK
- l'image ne charge qu'un bout et plus rien, il faut actualiser plusieurs fois pour voir apparaître la suite -> http 206 partial content (+ retransmission tcp) ou encore "continuation or non-http traffic"

Le cas de figure 3 arrive en moyenne 1 fois sur 10, c'est très gênant! Il me semble que ca apparaît surtout dans les heures où il y a du monde (par exemple 18h). Vous pouvez le voir sur www.rpgsoluce.com en ouvrant une série d'images à la suite dans une news ou une review d'un jeu. Les pages semblent rapides, c'est que les images apparemment.

Voici les pistes que j'ai :
- la "window size value" vaut entre 50 et 70 dans les réponses http su serveur, ce qui me parait très petit. Mais il y a aussi cette valeur quand les images se chargent vite donc je vois pas...
- c'est un peu comme si le trafic était tout d'un coup stoppé par exemple par une règle iptables. Mais j'ai bien mis (iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT et iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT pour ne rien casser)
- La commande "top" me révèle :
Mem: 4063484k total, 3817632k used, 245852k free, 363812k buffers
Swap: 4290552k total, 13792k used, 4276760k free, 2496660k cached
Il n'y a donc pas de problème au niveau de la mémoire (?)
- dans ma config apache2.conf j'ai keepalive on, MaxKeepAliveRequests 300, KeepAliveTimeout 15 et je suppose que c'est mpm_prefork qui est utilisé (rien changé dedans).
- dans le htaccess j'ai bien mis :
RewriteCond %{REQUEST_URI} "/images/"
RewriteRule (.*) $1 [L] pour éviter des tests inutiles sur les images de mon dossier images.

Voilà, celui qui trouve est vraiment bon. Et ca m'aiderait beaucoup! Merci!

Gecko · 06/11/2011, 20h52

Que dis MRTG (ou autre) concernant ta bande passante disponible aux heures de pointes?

_Mac_ · 06/11/2011, 21h36

Le "y a du monde" se traduit par combien de requêtes par seconde ?

La window est très petite, en effet, ça n'aide pas. Rien qu'avec ça, y a un problème sur le réseau.

La latence sur un ping du nom du site est de combien ?

Tu as essayé de désactiver le keep alive ou de réduire le nombre de requêtes traitées par fils ?

Sylphide666 · 07/11/2011, 12h05

Voici la page mrtg que j'ai créée hier : http://www.rpgsoluce.com/mrtg/
Statistiques : www.rpgsoluce.com/awstats.pl?config=rpgs

Je retire ce que j'ai dit sur les heures de pointe, apparemment le problème est toujours là (même à 1h du mat).

Citation:

Tu as essayé de désactiver le keep alive ou de réduire le nombre de requêtes traitées par fils ?

Oui, le keep alive off ne semble pas avoir résolu le problème. Pour le nombre de requêtes, je ne sais pas vraiment comment l'estimer efficacement en sachant que j'ai 4Go de mémoire. Avant il était à 0 (illimité), je l'ai mis à 1000.

Citation:

La latence sur un ping du nom du site est de combien ?

Il me semble toujours autour de 20ms

_Mac_ · 08/11/2011, 10h11

Les stats ne montrent pas grand-chose à part que tu as beaucoup (trop ?) de 404 et de 500. Il faudrait voir dans le fichier d'erreur d'Apache s'il n'y a pas quelques optimisations à faire et quelques pistes sur d'éventuels problèmes.

Pour le reste, je n'ai aucune idée. A part la piste de la window qui est beaucoup trop petite, je ne vois pas. Il faut voir dans la capture réseau s'il y a un "scénario" type qui se dégage : il se peut que la window se réduise progressivement et très vite et que ça amène à des resends. Il y a quelques temps, j'avais rencontré un truc un peu équivalent mais c'était sur des réseaux longues distances avec des latences de 300 ms avec un keep-alive trop court : Apache coupait la connexion avant que la seconde requête du navigateur parvienne au serveur. Résultat : le noyau dropait le paquet car il ne correspondait plus à un socket actif et on voyait plusieurs resend provenir du navigateur jusqu'à ce qu'il lâche l'affaire et affiche une jolie croix rouge. La désactivation du keep-alive était un correctif assez efficace mais "violent" car il a allongé les temps de réaction de l'application mais ce n'était pas gênant dans notre cas.

Sylphide666 · 09/11/2011, 00h47

Citation:

Les stats ne montrent pas grand-chose à part que tu as beaucoup (trop ?) de 404 et de 500. Il faudrait voir dans le fichier d'erreur d'Apache s'il n'y a pas quelques optimisations à faire et quelques pistes sur d'éventuels problèmes.

Oui ce sont probablement des robots ou autre. J'ai essayé de corriger un peu le tir dans le htaccess.

J'avoue que moi aussi je suis à court d'idées, à part de changer d’hébergeur pour une valeur sûre comme 1&1. Ca coûte un peu plus cher mais au moins je pense que côté qualité ce sera plus un problème.

La taille de la fenêtre est toujours très petite, environ 60. Chez les autres sites, je remarque surtout des valeurs proches de 150. Le problème c'est que j'ai aucune idée comment augmenter cette valeur. J'ai pas l'impression que c'est quelque chose qu'on peut facilement modifier en tant que client.

J'ai même essayé de remplacer le mpm_prefork par le worker. Ca n'a pas résolu le problème. Le keep-alive à off non plus. C'est incroyable cette histoire...

_Mac_ · 09/11/2011, 11h14

De ton côté, tu ne peux pas faire grand-chose. A part fouiller sur Internet, je n'ai pas d'idée. Sur Google, avec une recherche sur "debian increase tcp window size" je suis tombé sur ce doc qui peut peut-être t'aider.

Sylphide666 · 09/11/2011, 19h04

J'ai un peu de peine à comprendre... Ce soir le site est ultra rapide avec une window size plus élevée.

J'ai pourtant pas fait de révolution cette nuit à part :
- mettre en place nginx et le stopper pour recontinuer avec apache (il n'avait pas résolu le problème)
- installer le paquet php-fastcgi
- modifier un peu apache.conf (Timeout=100, keepalive on, maxkeepalive 500, keepalive timeout 5
- mise en place de openvpn

Je remarque dans le graph MTRG qu'il y a plus que 40mo de libre depuis quelques jours... sur 4 Go

_Mac_ · 09/11/2011, 21h17

La RAM libre de 40 Mo, ce n'est pas forcément bien grave car le noyau Linux peut en réserver beaucoup par avance. Il faut surtout regarder le swap : il ne doit pas y en avoir.

Sylphide666 · 12/11/2011, 15h48

Bon honnêtement je sais pas d'où ca vient.

On va peut être devoir payer un professionnel pour qu'il se connecte en ssh quelques min et nous règle ce problème (si c'est faisable), qui nous embête depuis des mois.

Merci beaucoup mac pour ton aide au passage

lenono · 21/11/2011, 22h44

Bonjour,

si je puis me permettre une toute petite apparition...

Tes images sont chargées depuis le même domaine que le site web principal, donc ça ralentit les chargements des éléments de tes pages, voir enoie un 206...
M'explique :
site web : http://www.rpgsoluce.com

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Tes images :
http://www.rpgsoluce.com/images/design/divers/boutique.jpg
http://www.rpgsoluce.com/images/logos/ps3/Meikyuu-Touro-Regasist.jpg
D'autres fichiers statiques :
http://www.rpgsoluce.com/rss/articles.xml
http://www.rpgsoluce.com/rss/rpgsSearch.xml
http://www.rpgsoluce.com/images/design/favicon.ico
http://www.rpgsoluce.com/css/jqModal.css
http://www.rpgsoluce.com/css/onglets.css...

Pour une optimisation, tu devrais permettre la parallélisation des chargements de ces données, en les plaçant dans un sous domaine, exemple :.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
http://static.rpgsoluce.com/images/design/divers/boutique.jpg
http://static.rpgsoluce.com/images/logos/ps3/Meikyuu-Touro-Regasist.jpg
http://static.rpgsoluce.com/rss/articles.xml
http://static.rpgsoluce.com/rss/rpgsSearch.xml
http://static.rpgsoluce.com/images/design/favicon.ico
http://static.rpgsoluce.com/css/jqModal.css
http://static.rpgsoluce.com/css/onglets

C'était la 1ère chose.

La seconde : NGINX :
Tu l'installes en frontal, reverse proxy, et tu permettras l'accès direct à tous les fichiers statiques par la règle suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
location ~* ^.+\.(js|css|jpg|jpeg|gif|bmp|png|pdf|zip|rar|flv)$ {
			access_log	off;
			expires	7d;
		}

Tu y gagneras forcément. Ca soulagera Apache (qui à mon avis est dépassé ! Me tapez pas dessus, c'est juste un avis) !

Sylphide666 · 23/11/2011, 23h35

Salut lenono,

Merci pour ta suggestion intéressante, j'ai transféré toutes les images/vidéos dans un sous-domaine mais ca n'a malheureusement pas résolu le problème.

Un technicien/admin de notre hébergeur va nous faire un audit du serveur pour 70€... on verra bien ce qu'il dit.

06/11/2011, 18h23	#1
Sylphide666 Invité de passage Inscription : juillet 2011 Messages : 11 Détails du profil Informations personnelles : Sexe : Informations forums : Inscription : juillet 2011 Messages : 11 Points : 0 Points : 0	1/10 des images ne se chargent pas! Bonjour, Je viens de configurer un nouveau serveur dédié (xeon first http://hosteur.com/serveur-dedie/) avec apache 2.2 sous Debian 6. Tout semble bien fonctionner, sauf que je ne sais pour quelle raison, des images ne se chargent pas ou très lentement. Voici les cas de figure possibles (avec le résultat correspondant dans la capture wireshark/tcpdump) : - l'image se charge correctement et rapidement -> http 200 OK - l'image se charge lentement mais jusqu'au bout -> http 200 OK - l'image ne charge qu'un bout et plus rien, il faut actualiser plusieurs fois pour voir apparaître la suite -> http 206 partial content (+ retransmission tcp) ou encore "continuation or non-http traffic" Le cas de figure 3 arrive en moyenne 1 fois sur 10, c'est très gênant! Il me semble que ca apparaît surtout dans les heures où il y a du monde (par exemple 18h). Vous pouvez le voir sur www.rpgsoluce.com en ouvrant une série d'images à la suite dans une news ou une review d'un jeu. Les pages semblent rapides, c'est que les images apparemment. Voici les pistes que j'ai : - la "window size value" vaut entre 50 et 70 dans les réponses http su serveur, ce qui me parait très petit. Mais il y a aussi cette valeur quand les images se chargent vite donc je vois pas... - c'est un peu comme si le trafic était tout d'un coup stoppé par exemple par une règle iptables. Mais j'ai bien mis (iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT et iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT pour ne rien casser) - La commande "top" me révèle : Mem: 4063484k total, 3817632k used, 245852k free, 363812k buffers Swap: 4290552k total, 13792k used, 4276760k free, 2496660k cached Il n'y a donc pas de problème au niveau de la mémoire (?) - dans ma config apache2.conf j'ai keepalive on, MaxKeepAliveRequests 300, KeepAliveTimeout 15 et je suppose que c'est mpm_prefork qui est utilisé (rien changé dedans). - dans le htaccess j'ai bien mis : RewriteCond %{REQUEST_URI} "/images/" RewriteRule (.*) $1 [L] pour éviter des tests inutiles sur les images de mon dossier images. Voilà, celui qui trouve est vraiment bon. Et ca m'aiderait beaucoup! Merci!
	00

06/11/2011, 20h52	#2
Gecko Membre éprouvé Antoine B Développeur Web Inscription : février 2011 Messages : 106 Détails du profil Informations personnelles : Nom : Antoine B Âge : 27 Localisation : France, Nord (Nord Pas de Calais) Informations professionnelles : Activité : Développeur Web Secteur : High Tech - Multimédia et Internet Informations forums : Inscription : février 2011 Messages : 106 Points : 409 Points : 409	Que dis MRTG (ou autre) concernant ta bande passante disponible aux heures de pointes? __________________ Si ce message vous a aidé, pensez à voter pour lui! Développe vos scripts E-Commerce et autres en PHP N'hésitez pas à me contacter par MP, E-Mail et MSN
	00

06/11/2011, 21h36	#3
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 297 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 297 Points : 8 580 Points : 8 580	Le "y a du monde" se traduit par combien de requêtes par seconde ? La window est très petite, en effet, ça n'aide pas. Rien qu'avec ça, y a un problème sur le réseau. La latence sur un ping du nom du site est de combien ? Tu as essayé de désactiver le keep alive ou de réduire le nombre de requêtes traitées par fils ? __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

08/11/2011, 10h11	#5
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 297 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 297 Points : 8 580 Points : 8 580	Les stats ne montrent pas grand-chose à part que tu as beaucoup (trop ?) de 404 et de 500. Il faudrait voir dans le fichier d'erreur d'Apache s'il n'y a pas quelques optimisations à faire et quelques pistes sur d'éventuels problèmes. Pour le reste, je n'ai aucune idée. A part la piste de la window qui est beaucoup trop petite, je ne vois pas. Il faut voir dans la capture réseau s'il y a un "scénario" type qui se dégage : il se peut que la window se réduise progressivement et très vite et que ça amène à des resends. Il y a quelques temps, j'avais rencontré un truc un peu équivalent mais c'était sur des réseaux longues distances avec des latences de 300 ms avec un keep-alive trop court : Apache coupait la connexion avant que la seconde requête du navigateur parvienne au serveur. Résultat : le noyau dropait le paquet car il ne correspondait plus à un socket actif et on voyait plusieurs resend provenir du navigateur jusqu'à ce qu'il lâche l'affaire et affiche une jolie croix rouge. La désactivation du keep-alive était un correctif assez efficace mais "violent" car il a allongé les temps de réaction de l'application mais ce n'était pas gênant dans notre cas. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

09/11/2011, 11h14	#7
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 297 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 297 Points : 8 580 Points : 8 580	De ton côté, tu ne peux pas faire grand-chose. A part fouiller sur Internet, je n'ai pas d'idée. Sur Google, avec une recherche sur "debian increase tcp window size" je suis tombé sur ce doc qui peut peut-être t'aider. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

09/11/2011, 19h04	#8
Sylphide666 Invité de passage Inscription : juillet 2011 Messages : 11 Détails du profil Informations personnelles : Sexe : Informations forums : Inscription : juillet 2011 Messages : 11 Points : 0 Points : 0	J'ai un peu de peine à comprendre... Ce soir le site est ultra rapide avec une window size plus élevée. J'ai pourtant pas fait de révolution cette nuit à part : - mettre en place nginx et le stopper pour recontinuer avec apache (il n'avait pas résolu le problème) - installer le paquet php-fastcgi - modifier un peu apache.conf (Timeout=100, keepalive on, maxkeepalive 500, keepalive timeout 5 - mise en place de openvpn Je remarque dans le graph MTRG qu'il y a plus que 40mo de libre depuis quelques jours... sur 4 Go
	00

09/11/2011, 21h17	#9
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 297 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 297 Points : 8 580 Points : 8 580	La RAM libre de 40 Mo, ce n'est pas forcément bien grave car le noyau Linux peut en réserver beaucoup par avance. Il faut surtout regarder le swap : il ne doit pas y en avoir. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

12/11/2011, 15h48	#10
Sylphide666 Invité de passage Inscription : juillet 2011 Messages : 11 Détails du profil Informations personnelles : Sexe : Informations forums : Inscription : juillet 2011 Messages : 11 Points : 0 Points : 0	Bon honnêtement je sais pas d'où ca vient. On va peut être devoir payer un professionnel pour qu'il se connecte en ssh quelques min et nous règle ce problème (si c'est faisable), qui nous embête depuis des mois. Merci beaucoup mac pour ton aide au passage
	00

23/11/2011, 23h35	#12
Sylphide666 Invité de passage Inscription : juillet 2011 Messages : 11 Détails du profil Informations personnelles : Sexe : Informations forums : Inscription : juillet 2011 Messages : 11 Points : 0 Points : 0	Salut lenono, Merci pour ta suggestion intéressante, j'ai transféré toutes les images/vidéos dans un sous-domaine mais ca n'a malheureusement pas résolu le problème. Un technicien/admin de notre hébergeur va nous faire un audit du serveur pour 70€... on verra bien ce qu'il dit.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email