2009-10-12 9 views
3

J'ai une application PHP qui utilise Zend Framework, ajax de jQuery et Zend_Session. Cette application existe depuis environ 7 mois et fonctionne comme elle le devrait. Lorsque l'application s'initialise après la connexion de l'utilisateur, environ 10 requêtes ajax sont déclenchées pour charger les données pertinentes sur une page de type tableau de bord. Une fois ces requêtes terminées, les requêtes ajax sont principalement initiées par l'utilisateur à partir de ce point. Lorsque l'application fonctionnait correctement, nous n'avions pas vraiment d'environnement à charge équilibrée, nous avions 3 serveurs d'applications qui traitaient les demandes, mais chacun stockait les données de session PHP localement. Récemment, nous avons changé cela pour que chaque serveur d'application soit connecté à un partage NFS central où les données de session PHP sont stockées. C'est quand l'application a éclaté.Numéro Ajax, PHP et Sessions

Maintenant, ce qui se passe est la page initialise, je peux voir les demandes ajax en attente, mais la moitié d'entre eux délai. Si j'attends assez longtemps (environ 3 à 10 minutes), tous les clics initiés par l'utilisateur répondent rapidement. Nous avons vérifié que le problème a été causé par notre changement de traitement de session.

Quelqu'un at-il une explication de ce qui pourrait se passer, comment dépanner et/ou une solution?

J'apprécie grandement toute aide que vous pouvez donner. J'ai tiré mes cheveux sur celui-ci.

+0

Pourriez-vous fournir plus de détails sur "notre changement dans la gestion des sessions"? Cela devrait être une raison de ce problème. –

+0

La modification à laquelle je fais référence est lorsque nous sommes passés de sessions stockées localement par serveur à un magasin NFS central pour nos sessions comme expliqué ci-dessus. – Bob

Répondre

2

Ceci est un problème courant. Vous avez probablement rencontré un problème de verrouillage de session. Le gestionnaire de sauvegarde de session par défaut que PHP utilise, le gestionnaire de fichiers (et celui que Zend_Session utilise par défaut), utilise le flick() syscall pour verrouiller les fichiers de session.

Comment choisissez-vous à quel serveur envoyer les demandes HTTP individuelles? Si elle est juste aléatoire, et que n'importe quelle requête peut être traitée par l'un des serveurs, vous pouvez facilement imaginer un scénario où le serveur 1 gère la demande initiale, crée le fichier de session sur le partage NFS et obtient et garde un verrou ce fichier. La requête AJAX suivante arrive sur un serveur différent, où le processus PHP sur ce serveur lit l'ID de session du cookie du client et tente d'obtenir un verrou sur le fichier de session sur le partage NFS. Puisque le premier serveur a toujours le verrou sur le fichier, vous êtes verrouillé et en attente.

Cela pourrait être ce qui le cause. C'est assez commun quand vous commencez à charger la balance PHP. Certains équilibreurs de charge ont un mode qui fournit des 'sessions persistantes' où l'équilibreur est assez intelligent pour regarder l'ID de session sur le réseau et s'assurer que le même serveur physique gère toutes les demandes pour une session donnée. Cela peut rendre votre équilibrage de charge moins efficace, mais cela en vaut la peine pour vous débarrasser du problème.

Ou, le problème peut être lié à autre chose. Je ne sais pas.

+0

C'est la conclusion que nous pouvons aussi bien, mais nous n'étions pas sûrs à 100%. Je ne suis pas sûr de ce que les options sont pour le réparer. J'aimerais un moyen rapide et facile, mais il semble que nous pourrions avoir besoin de reengineer une bonne partie de l'application. – Bob

+0

Dans un autre de mes messages sur ce site, je suggère une petite méthode pour stocker les données de session dans le cookie du navigateur. La meilleure solution est d'éviter de stocker quoi que ce soit dans la session côté serveur. Lien vers cette réponse est ici: http://stackoverflow.com/questions/617793/what-is-the-best-way-to-persist-an-object-using-forms-in-php/617915#617915 – RibaldEddie

2

Il pourrait y avoir plusieurs problèmes.

  • parts NFS Mount avec option noac pour essayer d'empêcher les copies périmées (What is close-to-open cache consistency?).
  • NFS est lent
  • fichier verrouillé (est session_write_close() appelé?) Ou non écrites sur le fichier, mais uniquement dans la mémoire locale du serveur
  • Il y a des problèmes connus si vous utilisez framesets (consultez la documentation de la session php)
  • Il peut également y avoir des problèmes si vous changez de domaine (a.domain.com, b.domain.com)