In general, I feel that the session function of PHP can basically be used, it is quite convenient, and it saves a lot of trouble of handling
cookies by yourself. PHP's session management is still based on files. The default is to generate a session file with the same name as the session id in the /tmp directory
, and save the registered
session data in this file. Session has a lifetime, which can be set in /usr/local/lib/php.ini.
The efficiency should be considered so-so. After all, file operations are still required, although it is /tmp. For applications with a large service volume, many session files will be generated in /tmp. . .
What about distributed applications? How many web servers serve together? There is a trick, the session file directory
is configurable, just put all the session files into a shared nfs directory and you're done. But when php
generates unique files, have you considered the special processing of nfs? I didn’t look at the source code carefully, I guess
something might go wrong, although the chance is very small...
You can be a session keeper damon, session data can be stored in a hash table
In the memory, use the UDP service mode (high efficiency, small packet loss rate in LAN) to complete the session generation, retrieval, termination, retrieval and setting of session variables, etc., so that multiple web servers can share the session information. I have done both server-side and client-side functions. Now the question is how to add the client-side functions to PHP, or how PHP supports dynamic library function calls. These things are covered in the manual. Not exhaustive, no relevant examples.
BTW: Due to the loose grammar, PHP function returns are prone to ambiguity. For example, strpos returns 0 if there is no
match, but the matching position may be 0, favorite~...
http://www.bkjia.com/PHPjc/316138.html