2009-06-10 17 views
2

Nous avons deux applications de base fonctionnant sur nos serveurs sur CF8, et les deux ont exactement le même délai de session défini dans l'application CFC (2 heures en ce moment). Cependant, nous constatons que les sessions sont hors de contrôle pour l'une des applications (actuellement à plus de 120 000 sur un serveur), appelons AppA alors qu'AppB semble bien (et AppB est celui auquel nous attendons beaucoup plus de trafic). J'ai donc creusé davantage et j'ai découvert que la plupart des sessions pour AppA étaient inutilisées depuis de nombreuses heures, la valeur la plus élevée que j'ai vue jusqu'à maintenant étant de plus de 11 heures.Les sessions ColdFusion ne sont pas dépassées

Nous ne faisons pas grand-chose avec les sessions, donc je suis un peu confus quant aux raisons pour lesquelles ils ne sont pas expirés comme prévu. J'ai également jeté la portée this dans l'application CFC et il montre la valeur attendue pour sessionTimeout. La seule chose que j'ai remarquée est que dans une instance, nous assignons une variable sur la portée Request à partir d'une variable Session. Si c'était une portée différente, je penserais peut-être que cela cause une sorte de référence que GC (ou autre) ne peut pas effacer.

+2

Les délais d'attente de session sont des délais d'inactivité, êtes-vous sûr que rien ne touche le CFC pendant 11 heures? – kevink

Répondre

0

En fait, il s'avère que les sessions ont été démarrées à partir d'une autre application qui ne dépassait pas la valeur par défaut dans le fichier Application.cfc de base (y compris le nom de l'application).

0

J'avais l'habitude d'obtenir des blocages de serveur dans CF6.1 quand je persistais CFCs dans les étendues d'application ou de session. Maintenant, je les instancie dans la portée de la requête et les blocages s'arrêtent (sans perte de performance notable). Peut-être que vous avez un problème similaire.

1

En termes de spirale, je dirais que cela concerne certaines demandes qui ne passent pas par le CFID/CFTOKEN pour maintenir la session. Il peut s'agir d'appels de service Web, de requêtes CFHTTP, de robots de moteur de recherche, etc. L'expérience de l'une de vos applications est similaire. Si c'est le cas, alors pour CFHTTP passez le CFID/CFTOKEN à travers pour maintenir les sessions. Les services Web sont un peu plus compliqués, vous devrez créer une «clé» qui vous sera transmise, sujet distinct! Les robots peuvent être manipulés en ayant quelques conditions pour définir la valeur du délai d'expiration de la session.

Pour les 11 heures, je dirais que c'est parce qu'il a été maintenu en vie par quelque chose. Un sondage continu? Reprise de la requête AJAX? Ce devrait être quelque chose qui continue à passer l'ID/TOKEN à travers.

+0

FusionReactor serait un bon outil à avoir dans cette situation, pour voir quels scripts sont en cours d'exécution que vous ne connaissez pas. –

+0

Oui, j'ai creusé un peu plus et j'ai trouvé que la plupart des sessions étaient inactives pendant tout le temps où elles ont été levées, ce qui me pointe vers des bots. Nous avons quelques vérifications de base pour les robots sur cette application, mais sur l'autre application, nous avons des contrôles plus agressifs pour les robots collecteurs de spam, donc je vais les déplacer vers cette application aussi, je pense. – DEfusion

Questions connexes