The transaction only consisted of a single PHP page request. The backend system architecture was apache2.2+PHP5.3+mysql+windows2003. The stress test request had no sql operations, ruling out mysql issues.
Checking the operating system resources showed CPU and MEM were very idle, so CPU and memory were likely not the bottleneck.
Checking the apache configuration also revealed no issues, 1200 execution threads, a bit large but still well within concurrency requirements.,Suspecting PHP was causing unstable performance, we decided to stress-test a static resource request to see if the TPS would be stable
The TPS for static resource files was very stable, indicating the problem likely lay with PHP. We checked the PHP configuration file php.ini:
session.auto_start = 1 #Executes session_start() on every page load, initializing a session
session.save_path = "D:/tmp" #Session file save path
session.save_handler = files #Session save method
Upon seeing the PHP session settings, our initial suspicion was that the session configuration was causing the performance issue. During concurrent stress testing, every request would create a session, and each session would create a file in D:/tmp
After running for a while, the sheer number of files in the directory caused performance to degrade.
After communicating with the user, we learned the requests being stress-tested did not require sessions. So we changed session.auto_start = 0 and re-ran the test:
After changing the session setting, the TPS finally stabilized. Due to external network bandwidth limitations, we switched to internal network testing
In the internal network test, TPS increased to 1530, and the CPU was fully utilized, reaching 100%.
This shows that PHP’s session file save method has a significant impact on performance.