Web Speed-up: Avoid PHP session slow running

Web Speed-up: Avoid PHP session slow running

One, what--concurrent access, blocking execution
1.1 Do not use session

File index.php:

The contents of ajax.php, ajax2.php and ajax3.php are

    
   
   
   
Every request to sleep 1S,JQ Ajax requests is asynchronous, which means that the three requests are essentially simultaneous, and ideally the browser waits for all 1s,3 interfaces to return.
   
Visit http://localhost and view the test results under chrome:
   
   
Figure 1.1 do not use session test results
   
The test results are basically consistent with the theory.
   
1.2 Using session
   
Now we have changed the documents ajax.php, ajax2.php and ajax3.php to
   
   
   
   
     
   
   
   
   
What difference does it make? We look directly at the test results:
   
   
Figure 1.2 Using the session test results
   
Not every request only executes a 1s clock? Why ajax2.php consumes 3s 2s,ajax3.php?
   
Ii. Who-session lock
   
The official definition of Session Lock:
   
Session data is usually stored after your script terminated without the need to call Session_write_close (), but as session Data is locked to prevent concurrent writes only one script could operate on a session at any time.
   
The general meaning is that the session data will be locked from the call Session_Start () until the call Session_write_close () or the script ends, and the request from the same SessionID user will be blocked.
   
As seen from the test results in Figure 1.2, ajax2.php and ajax3.php performed 1s and 2s respectively, and obviously the session_start () operation caused the blockage.
   
When index.php at the same time access ajax.php, ajax2.php, ajax3.php,ajax.php first execution, at this time ajax2.php and ajax3.php are waiting in the ajax.php release session lock, are consumed 1s.
   
When the ajax.php execution completes, release the session lock, ajax2.php and ajax3.php again competition session lock, the same ajax3.php and wait for the 1s clock. So we get the result:
   
ajax.php consumption 1s
   
ajax2.php consumption 2s
   
ajax3.php consumption 3s
   
Iii. when – when will the session lock be triggered?
   
In chapter two, the session lock is defined as session_start () to trigger the session lock, so there is a problem with the user request blocking caused by the session lock for most of the existing PHP framework (using native PHP session). Imagine, there are 2 requests, where request a requires 3s to return the results, and request B only need 10ms to return, the front-end request both interfaces, if the background processing a request, then the B request will wait for 3s and then execute 10ms to return the results. However, the best case is that at the same time the request is initiated, 10MS receives a B request to return, and 3s receives a request to return.
   
Iv. Why-session internal execution mechanism
   
By default, the PHP session uses files as server-side storage media. In the source code of the PHP session module, there is a more important structure:
   
   

   
Figure 4.1 PHP Session module structure Body ps_module_struct
   
Several function pointers in this structure correspond to the functions of open, close, read, write, Destory, GC recycle of Session operation respectively. See these 6 functions, do you think of PHP Sessionhandlerinterface interface (version >=php5.4)?
   
   
Figure 4.2 PHP Sessionhandlerinterface Interface
   
Using this interface with Session_set_save_handler can rewrite these key operations of the session. So we can use the following code to explore the order in which the PHP session runs in the life cycle of a request:
   
   
Figure 4.3 Session run sequence test code
   
Test results:
   
   
The test results know the general order of the session execution, when the session_start () call, PHP back to call open and read operations, after the execution of the script (output PHP script run), call the write and close operation.
   
Now we might as well make a bold guess, PHP in the session open or read operation, opened the session lock, and write or close after the release session lock. This conjecture also conforms to our test results in Chapter 1.
   
In order to verify our conjecture, we need to go to the source code of PHP to explore. In the PHP source file/EXT/SESSION/MOD_FILES.C you can see the default session of the 6 important parts of the implementation of the operation. On line 156 (click the Open link), you see an open operation with a file operation: Flock (DATA->FD, LOCK_EX), which opens the file in a mutex-locked manner. Close the file in line 110 (DATA->FD);.
   
Seeing here, we should get the conclusion that:
   
In the default case, the so-called PHP session lock is actually a file lock
   
So, when we use Session_set_save_handler from a fixed session, instead of using memcache or other media, as long as we have no lock logic in the Sessionhandlerinterface interface, Then the session lock will naturally not exist. The author has also done such experiments privately, and it is true that this is the case with practice.
   
How--how to avoid the blocking phenomenon caused by the session lock
   
First, the session lock is not necessarily bad, in one case it is very useful, such as an interface to the same user's request by default the same time can only be executed once. At such times, you can use Seesion_start () and Session_write_close () to enclose the code you want to block. Very simple violence practical.
   
But most of the time we have to avoid the existence of this lock, the solution:
   
1, in the use of the session immediately after Session_write_close () off, release session lock
   
2, with no lock session operation, as described in Chapter 4, using Session_set_save_handler to customize a session without a lock.
   
3, and then use the default PHP session, the personal preferred one scenario: most of the time, we operate on the session is basically read operations, write operations are generally relatively small. At such times, we can write ourselves a session class.
   
Constructor: reads the session into the cache, closes the session lock
   
Write operation: Open session lock, write value, close session lock
   
Read operation: Direct read cache
   
Some of the code is as follows:
   
   
Reads the session into the global variable $_seesionstatic private function init () {if (self:: $not _init) {session_start (); Session_write_close () ; Self:: $not _init = false;}}
   
   
   
   
   
Read Sessionstatic public function get ($name) {self::init (); return $_session[$name];}
   
   
   
   
   
Write sessionstatic Public function set ($name, $val) {session_start (); $_session[$name] = $val; Session_write_close ();}
   
   
   
   
Note: It is not appropriate to use this method if it is a write operation that is frequently used.
