Ubuntu-fr

Crone123

[Résolu] Apache2 : Problème de réponse

Bonjour,

SUJET RÉSOLU: Solution ici: http://forum.ubuntu-fr.org/viewtopic.ph … #p16220281

J'ai un site hébergé sur un serveur perso (Ubuntu 64bits, apache2 mod itk, PHP5, MySQL, CPU I5, 4Go RAM), et maintenant que j'ai des posts avec un certain nombre de miniatures (images) dedans, je remarque un problème permanent:
Un certain pourcentage des images de la page chargent correctement, et les autres sont remplacés par le "alt" de la balise html, ce n'est jamais les mêmes images, a peu près une fois sur 2 elles chargent, et des fois non.

J'ai cherché, et j'ai fini par découvrir ceci:

Donc merci a Firefox pour l'analyse:

Les images envoyée de façon "pure" apache2 , genre les smileys, la bannière, etc... sont bien mises en cache correctement et même après rafraîchissement Firefox reçois un "304 Not modified".

Cependant, par commodité, fonctionnalité, et par sécurité, tout ce qui est envoyé par les utilisateurs est traité par PHP, et l'envoi est fait via XSendFile. ça me permet de gérer des miniatures de différentes tailles avec Imagick que je garde sur le disque dur du serveur en cache (pour pas les re-générer), ça m'évite d'avoir des accès directs aux fichiers (on sait jamais si quelqu'un envoie un .php et qu'il passe, ici le site le laisse passer mais il n'y a de toute façon aucun risque qu'il soit exécuté par le serveur) → L'image juste au dessus est d'ailleurs une miniature 720p (en préservant le ratio de l'image) de ma capture d'écran d'origine et elle est envoyée par XSendFile depuis mon serveur.

Sauf que d'après Firefox, on remarque que: Déjà toutes les images en FJ_N°_ViewMinN° qui sont justement envoyés par n'importe quel utilisateur on un soucis, celles en "vert" sont bien chargée, les autres pour une raison inconnue le serveur n'a pas répondu, dans la requête de firefox, j'ai remarqué qu'il ne demandait pas toujours le "If-Modified-Since" et "If-None-Match"

Donc, coté cache:
Pour la page: session_cache_limiter = nocache, Header: Pragma: nocache, Cache-Control: no-cache
Pour les images par XSendFile: session_cache_limiter = public, Header: Pragma: public, Cache-Control: public

Le problème ne peut pas venir de la connexion internet, le test est effectué en local sur du RJ45.

Quelqu'un a t-il une piste/idée/solution? parce que là je sèche...
Merci beaucoup

Dernière modification par Crone123 (Le 05/03/2014, à 19:05)

bruno

Re : [Résolu] Apache2 : Problème de réponse

C'est un peu confus pour moi… En gros tu as un problème avec certaines images qui ne s'affichent pas. Il faut donc essayer de charger directement l'une ou l'autre de ces images et voir quels sont les codes HTTP renvoyés.

Si une image ne s'affiche pas c'est que :
- le fichier n'existe pas -> erreur 404
- le fichier existe mais ne peut être lu (insuffisance ou  restriction des droits d'accès) -> 401, 403
- le serveur met trop de temps à répondre - > 408
etc.

Crone123

Re : [Résolu] Apache2 : Problème de réponse

Le truc, c'est qu'en faisant "clic droit → Actualiser" sur une image qui ne s'affiche pas avec Firefox, elle s'affiche immédiatement. Et encore pire: En fait, pendant 2s toutes les images s'affichent (cache je suppose), puis elles finissent par disparaître quand Firefox indique que le serveur n'a pas répondu.

Ensuite, le 401, 403, et 404 c'est impossible:
Quelque soit l'adresse chargée, ça utilise index.php (url-rewriting) qui est accessible, et qui envoie ce qu'il faut.
Il gère lui même les erreurs, un 403 va soit sortir une page html, soit envoyer une autre image (selon le cas), et aucune image n'est en 403 sur le site.
404 pareil, il envoie une autre image de 404 donc dans tous les cas ça envoie quelque chose.

Pour une image qui ne s'affiche pas, comme je l'ai dit, y a pas de cas général d'image qui ne s'affiche pas, exemple:
Image1 s'affiche, Image2 s'affiche et Image3 ne s'affiche pas.
Chargement de page suivant:
Image1 ne s'affiche pas, Image2 s'affiche, Image3 ne s'affiche pas.
Chargement de page suivant:
Image1 s'affiche, Image2 ne s'affiche pas, Image3 s'affiche.
C'est aléatoire, et le bug se produit aussi bien avec Firefox que Chrome/Chromium donc le navigateur n'est pas en cause.

Les avatars sont aussi envoyés par ce système, et ils subissent les mêmes bugs.
Mais par exemple, sur une page ou j'ai quelques images, 3 - 4 par exemple, elles s'affichent toutes a tout les coups.

Exemple, j'ai une page contenant environ 30 images envoyées par XSendFile.
Avatars, Images en taille réelle, et Miniatures générées par le site (générées 1fois, puis envoyée a chaque demande)
Elles sont normalement toutes gardées en cache par le navigateur.
Déjà pour commencer, j'ai pas l'impression quelles soient mises en cache correctement, alors que les en têtes d'après Firefox répondent: "public, max-age=10800" dans Cache-Control.

Exemple:
J'ai un avatar qui normalement est censé être gardé en cache par le navigateur. Déjà a priori ça ne fonctionne pas correctement, car il fait a chaque fois une requête de type GET au serveur, alors qu'il n'en fait pas pour les images en cache qui ne sont pas envoyées par XSendFile.
Donc, a mon chargement de la page, l'avatar ne s'affiche pas, dans l'analyse réseau de Firefox, je vois que Firefox n'a reçu aucune réponse (alors que l'avatar existe, la page aussi, et que je suis connecté en local au serveur, et que le serveur étant capable de lancer Skyrim en Ultra, doit être capable d'envoyer 30images par http)
Dans l'analyse réseau, je fais modifier et ré-envoyer, je ne modifie rien, et je fais ré-envoyer, hop directement l'avatar s'affiche.

Je pense qu'il s'agit d'un problème de nombre de requêtes traitées en même temps, il doit y avoir une limite, et soit il met les autres en attente, et ne les traite pas, soit il les abandonne tout simplement.
Sauf erreur de ma part, je crois que PHP ne peut pas être lancé en multithreadé, j'utilise le MPM ITK, donc je suppose que c'est le cas, et que ça peut être la cause du problème.
J'ai lu que FastCGI permettrait de lancer du multi-threadé, donc j'aimerais bien essayer:
→ Peut t-on avoir du multi-threadé sur apache2 avec ITK, ou uniquement sur le WORKER? Ou alors, peut t-on avoir une séparation d'utilisateur sur le WORKER? (Genre sur le virtualhost machin c'est www-data qui accède, sur le virtualhost machin2 c'est user-machin qui y accède, etc...)
→ Peut t-on installer FastCGI avec apache2 ITK/WORKER?

Sinon, autre question: En dehors de apache2, je sais que nginx est fait pour ce genre de choses: Envoyer pleins de fichiers d'un coup: Supporte t-il PHP en multi-threadé (FastCGI ou autres..), les virtualhost, et la séparation d'utilisateurs? Si c'est le cas je pourrais peut être optimiser le chargement et régler le problème soit en modifiant l'installation d'apache2, soit en le remplaçant par nginx.
Mais j'ai toujours eu apache2 donc je suis un peu perdu là dedans.
Mieux vaut FastCGI/XSendFile, les 2? Et comment adapter le cache proprement?

Si quelqu'un peut me conseiller pour optimiser tout ça et résoudre mon problème ce serait très sympa
Je cherche une solution qui:
→ Supporte le chargement de plusieurs fichiers/page a la fois, y compris en PHP
→ Est rapide (cache coté serveur/compression de l'envoi avec gzip par exemple, etc..)
→ Ne bloque pas la navigation quand un fichier est téléchargé depuis une page PHP (comme XSendFile par exemple)
→ Supporte la gestion de virtualhosts ou équivalent
→ Permet de séparer les utilisateurs des différents virtualhosts. (Exemple: VH1, le serveur web utilisera user1:group1, VH2, le serveur web utilisera user2:group2, etc..)

Merci

Crone123

Re : [Résolu] Apache2 : Problème de réponse

Je crois que j'ai réussi, je poste ma solution si quelqu'un venait a avoir le problème:

Donc, j'ai activé fastcgi, et php-fpm

Je ne pense pas que ça aie une quelconque utilité pour résoudre le problème mais voilà...

J'ai crée une nouvelle fonction pour envoyer les fichiers/images, en prenant soin de remplir proprement tous les headers de cache.
Je n'utilises plus XSendFile mais readfile tout simplement, vu que je ferme la session php avant d'envoyer normalement y a pas de soucis pour la navigation.
Si je venais a retrouver un problème pour la navigation je verrais pour ré-utiliser XSendFile mais pour l'instant ça m'as l'air bon.

Il fallait en fait tester sois même la date de modification du fichier, et la dernière date de modification du navigateur, et envoyer un header 304 Not Modified quand il n'y avait pas besoin de ré-envoyer.

Maintenant d'après mes tests: Les images chargent tout sans exception, en multi-threadé, et restent en cache.