Je me souviens de lire sur php.net (bien que malheureusement ne puisse pas sembler trouver la page) que l'interprète PHP peut Exécuter de différentes manières - le plus souvent, chaque fois qu'une page est demandée, une instance de l'interprète PHP est créée, exécute son cours, puis est détruite, ainsi que toute la mémoire associée à cet appel de page. Apparemment, il est également possible d'autoriser toute la mémoire à s'attarder, de sorte qu'elle puisse être utilisée à nouveau dans les prochains appels de page; Comme je l'ai compris, permettant essentiellement de multiples scripts PHP d'accéder à et de modifier les mêmes objets, sans les perdre après la fin du script.
ou au moins, donc je me souviens. Y a-t-il une vérité à cela? Si oui, comment puis-je le mettre en place?
3 Réponses :
php ne fonctionne pas de cette façon. c'est à propos de courir et d'oublier.
Vous pouvez enregistrer des données entre les demandes à l'aide d'extensions de mémoire partagées userland, par exemple: APC, XCache, Memcached, etc.
ou en utilisant le tableau de données de session après avoir appelé Session_Start
$ _ session
Ne pensez pas aux scripts PHP comme une application Java par ex. matou. Standard PHP n'a pas été conçu pour ce cas d'utilisation. Le compilateur PHP fonctionne à la volée.
J'ai trouvé Session_Name pour être très utile avec cela. Chaque fichier peut partager le même nom de session et toutes les données pertinentes peuvent être stockées dans l'objet Session. De cette façon, je peux exécuter un fichier init qui configure l'objet de session, puis tous les fichiers de script associés peuvent l'utiliser en conséquence.
@ Monchoman45 Bien à mes sessions d'opinion ne sont pas faits pour remplacer $ globaux ou la mise en cache de page si c'est ce que vous ment;)
Laissez le serveur rester entre les demandes, les objets seront donc:
Avec des applications bien écrites qui vous donne plus de vitesse que l'APC, mais elle n'éplève pas entre les utilisateurs si vous devez mettre sur des boîtes mutliples (vous pouvez toujours utiliser des sessions collantes).
Vous pouvez utiliser Mémoire partagée pour une partie de ce que vous Vous voulez, mais Redis / Memcache sont probablement meilleurs paris.
Qu'essayez-vous de résoudre? Quel est le problème d'origine?
Peut-être que la variable $ _session est tout ce dont vous avez besoin :)
Si vous souhaitez persister des objets en mémoire, puis les cache dans APC ou MEMCACHED. Mais oui, peut-être que vous cherchez simplement une fonctionnalité de session.
Il existe des méthodes de mémoire partagées php.net/manual/fr/book.shmop.php mais il est toujours sérialisé et insérifiant des objets
@zerkms: J'avais l'intention d'utiliser ceci pour créer une application qui envoie et recevant constamment des informations provenant d'autres serveurs (par le biais de Basic Get and Post) et devra peut-être effectuer plusieurs demandes simultanées que, lorsque vous avez terminé, peut revenir à la portée précédente et modifier les données en conséquence. J'ai envisagé d'utiliser une base de données, mais j'ai pensé que cela finirait par être plus compliqué que nécessaire. Ghommey: Je ne comprends pas complètement session_start , comment puis-je m'assurer que cela récupère la bonne séance?
Exécution de PHP à travers Old Slow CGI régulier effectue une configuration complète et une déchirure de l'interprète et de la mémoire pour chaque demande. Les restes d'exécution zéro restent de cette façon. Exécution de PHP en tant que module Apache, ce n'est cependant pas complètement essuie toute la mémoire, mais la plupart d'entre elles. J'ai rencontré des problèmes dans lesquels définir certains paramètres tels que les paramètres régionaux ne reçoivent pas la réinitialisation après une exécution de script et sont partagées dans une large mesure. C'était il y a longtemps, mais le point est que la mémoire n'est pas totalement essuyée lorsqu'il est exécuté comme module Apache, ni rapide CGI. De nombreuses extensions PHP se comportent différemment en raison de ces différences
A trouvé session_name , on dirait que $ _Session fonctionnera. Merci, @ghommey.