Quiconque a écrit un ASP légèrement plus grand sait que l'objet Session est vraiment simple à utiliser. Il peut être utilisé pour enregistrer les variables de données privées de l'utilisateur, ce qui est à la fois sûr et pratique. Mais savez-vous vraiment comment fonctionne Session ? Quiconque a écrit un ASP légèrement plus grand sait que l'objet Session est vraiment simple à utiliser. Il peut être utilisé pour enregistrer les variables de données privées de l'utilisateur, ce qui est à la fois sûr et pratique. Mais savez-vous vraiment comment fonctionne Session ? Peut-être qu’après l’avoir compris, vous n’oserez plus utiliser cet objet tant aimé et détesté. Bien que la méthode alternative soit un peu gênante, après réflexion à long terme, elle doit être mise en œuvre.
Parlons d'abord des avantages de Session. Il peut être utilisé pour enregistrer les variables de données privées du client et ne disparaîtra pas dans le délai imparti. C'est vraiment une fonction importante, surtout pour les systèmes avec des membres qui doivent être utilisés. Tels que le compte de connexion du membre, l'heure, le statut et de nombreuses données en temps réel qui doivent être enregistrées (telles que le système d'achat enregistrant les articles dans le panier de l'utilisateur). Ces informations sont nécessaires en privé à chaque utilisateur et sont généralement utilisées par les développeurs. . Traitement des enregistrements de session.
Cependant, la Session dans ASP est composée de Cookies, et le serveur transmet toutes les données enregistrées dans la Session au navigateur de l'utilisateur sous forme de Cookies. Habituellement, les navigateurs généraux stockent ces cookies Chaque fois que l'utilisateur clique sur un lien et se reconnecte au serveur, le navigateur renvoie ces cookies au serveur pour traitement. C'est le principe de fonctionnement de Session. Lorsque la quantité de données est plus importante, puisqu'elles doivent être envoyées et récupérées, non seulement cela consomme de la bande passante de ligne, mais réduit également les performances car le serveur doit consacrer plus de ressources au traitement et à la reconfiguration en ligne. mémoire. Maintenant, vous pensez peut-être : « Je dois utiliser cette fonction, donc je dois la sacrifier. » Cependant, cet article parle de Session, d'une part, il vous apprend à l'utiliser moins, d'autre part, bien sûr. il existe des alternatives. La prochaine chose qui apparaît est qu'il appartient également à l'objet Application Global.asa.
L'application est également efficace pour enregistrer et traiter des données temporaires. Ses capacités et son utilisation sont les mêmes que celles de Session à tous égards. Cependant, en comparaison, les données qu'elle enregistre sont publiques, c'est-à-dire un espace variable qui peut être partagé par n'importe quel utilisateur. Contrairement à la session, l'application ne transfère pas les données à l'utilisateur et n'attend pas la prochaine connexion pour les relire. Elles sont directement enregistrées dans la mémoire du serveur. En comparaison, les performances sont beaucoup plus rapides que celles de la session.
Puisque l'objet Application est public, la première chose à faire est de planifier un espace commun pour chaque utilisateur, afin que chaque utilisateur puisse disposer de son propre espace pour enregistrer les données, afin d'atteindre l'objectif de simulation de session. Il existe désormais deux approches :
1. Initialisez, créez et allouez l'espace mémoire utilisateur à l'avance lorsque le serveur est activé. Habituellement, bien que cette approche occupe beaucoup de ressources dès le démarrage du serveur, elle évite également de devoir l'allouer à chaque fois que l'utilisateur. est en ligne à l'avenir. Mais il y a une limitation : cette méthode doit limiter le nombre maximum de personnes. Puisqu'elle est initialisée dès qu'elle est activée, on ne peut qu'estimer la création d'une certaine quantité d'espace mémoire, cette méthode est donc généralement utilisée dans les petits programmes. comme les salons de discussion.
2. Cette méthode doit être considérée comme plus appropriée pour les applications à grande échelle. Elle adopte une méthode d'allocation dynamique et commence à allouer des ressources à l'utilisateur lorsque celui-ci se connecte pour la première fois au serveur. Le but de ces deux méthodes de simulation de Session est de réduire la consommation des ressources de Session, mais après tout, elles ne peuvent pas être complètement remplacées. Il faut quand même utiliser un peu de Session, ce qui peut au moins réduire beaucoup de charge sur le. Serveur.
Première option
Nous commençons d’abord la mise en œuvre de la première solution. Puisque l’application est initialisée lors de l’activation, nous devons bien sûr partir de Global.asa :
L'initialisation est terminée, mais comment l'utiliser ? Il nous suffit de modifier les données initialement stockées à l'aide de la session, telles que le numéro de compte et l'heure de connexion, dans l'objet Application que nous avons créé où l'utilisateur se connecte :
Copiez le code comme suit :
'Recherchez l'espace inutilisé
Pour i = 1 Vers Application (ClientMax)
Si Application (User_Status_ & i) = 0 Alors
'Numéro temporaire de l'utilisateur
Session (Index) = je
'verrouillage
Application Application.Lock
'Défini à l'état utilisé
Application(User_Status_ & i) = 1 'Mettre les données variables
Application (User_Account_ & i) = Compte
Application (User_Logtime_ & i) = Maintenant ()
'Ouvrir
Application.Déverrouiller
Quitter pour
Fin si
Suivant
Pour obtenir des données variables liées à l'utilisateur, procédez comme suit :
Réponse.Write (Application (User_Account_ & Session (Index))
Vous constaterez peut-être qu'il n'est pas dit de ne pas utiliser Session ? Alors pourquoi Session existe-t-il toujours dans le code source ci-dessus ? Comme mentionné précédemment, cette alternative ne peut pas remplacer complètement la Session. Le navigateur n'est pas toujours en ligne avec le Serveur. Il sera déconnecté après la lecture de la page. Alors comment savoir que la même personne est connectée la prochaine fois ? A ce moment, nous devons nous appuyer sur Session. Nous donnons à l'utilisateur un ensemble de numéros en temps réel. Ce numéro est le numéro de l'espace variable de l'utilisateur sur l'Application. Vous pouvez imaginer qu'il y a de nombreux coffres-forts dans votre banque. une clé, et la clé Il y a un numéro dessus, et le numéro sur la clé permet au commis de vous conduire à votre propre coffre-fort. Il y a encore des améliorations à cette méthode, mais elle est suffisante pour les petites applications.
Deuxième option
Concernant la solution précédente, vous pouvez aussi penser que nos numéros personnalisés sont enregistrés à l'aide de Session. En parlant de chiffres, l'objet Session fournit une méthode "SessionID". C'est vrai, que nous souhaitions l'utiliser ou non, le serveur attribuera automatiquement un numéro à chaque utilisateur, et ce numéro ne sera pas répété. Quant à ce numéro, il est obtenu à l'aide de Session.SessionID. Cette numérotation est une action que Session fera certainement. Nous pouvons l'utiliser pour remplacer le programme de numérotation que nous avons écrit nous-mêmes, ce qui permet également d'économiser beaucoup d'efforts et offre même une plus grande évolutivité. Mais fondamentalement, la première solution ci-dessus a toujours ses utilités, comme les petites applications telles que les salons de discussion qui limitent le nombre de personnes. L'alternative suivante concerne les systèmes plus grands.
Pour les sites Web comptant des centaines, des milliers, voire des dizaines de milliers de visiteurs par seconde, la solution précédente ne fonctionnera certainement pas. Supposons que vous définissiez la limite supérieure du nombre de personnes à 10 000. Une fois activé, le serveur vous aidera à supprimer 10 000 zones pour 10 000 utilisateurs. S'il y a 5 variables dans une zone et qu'une variable occupe 32 octets, 10 000 elle en occupe plus. supérieure à 320 000 K (320 Mo), serveur Dès qu'il est activé, tant de déchets sont stockés dans la mémoire, et les performances seront forcément considérablement réduites avant d'entrer sur le champ de bataille ; et ne regardez pas ces petits chiffres et pensez que vos 512 Mo seront Les chiffres ci-dessus supposent un nombre minimum, plus on ne sait pas combien de ressources supplémentaires le serveur utilisera lors de la configuration de la mémoire, ce ne sera donc que plus, pas moins. Par conséquent, la seule solution consiste à configurer dynamiquement l'espace variable utilisateur et à supprimer une zone uniquement lorsqu'un utilisateur est connecté au serveur. De cette façon, il n'est pas nécessaire de configurer une énorme mémoire à l'avance.
La deuxième option est relativement simple à mettre en œuvre. Veuillez jeter tout ce qui se trouve dans la première option. Nous n'avons pas besoin de toucher à Global.asa. Il nous suffit de modifier le lieu de connexion de l'utilisateur et les autres emplacements utiles :
Copiez le code comme suit :
'LockApplicationApplication.Lock 'Mettre les données variables
Application (User_Account_ & Session.SessionID) = Compte
Application(User_Logtime_ & Session.SessionID) = Now() 'Déverrouiller Application.Déverrouiller
Pour obtenir des données variables liées à l'utilisateur, procédez comme suit :
Copiez le code comme suit :
Réponse.Write(Application(User_Account_ & Session.SessionID))
Dans le passé, j'ai lu de nombreux livres qui disaient que les séances étaient très gourmandes en ressources, alors essayez de ne pas les utiliser, mais vous devez quand même les utiliser quand vous le devez, et les livres n'enseignaient pas de solutions plus appropriées. Maintenant que vous comprenez comment remplacer Session, profitez-en ! Peut-être que les problèmes de performances qui m’ont toujours troublé pourraient être considérablement améliorés !