Through FastCGI for IIS we can have support for PHP on the Microsoft server for Windows (IIS).
It is not the best option to serve applications in PHP but, when the server requirements are these, there is no other choice.
These days I have been really busy developing an eCommerce platform on this platform. To improve performance, membase is used (something more than a Memcache server for windows), as well as a hybrid data system: MySQL and MongoDB, Haanga as a template system and as a search engine a modification of Zend_Search_Lucene.
Everything seemed to be going well until we started to see a strange slowness in some requests, so the queries were reviewed, giving the heaviest one (in the MySQL slow query log) 2 seconds, somewhat below the 20 seconds that some pages took, without apparent complexity.
There was no large network load, nor a considerable number of simultaneous requests, but there were moments of extreme slowness.
Not finding the origin, and verified that on the development and pre-production server, with the same data, these problems did not occur, we ended up adding, in production, different error_log() in specific areas to pinpoint the origin of the problem.
Every time we looked at the logs, we observed very different patterns, the times were apparently random, sometimes before a simple query, sometimes when rendering the template, sometimes when searching for a value in the cache … they appeared anywhere and at any time, making the website completely inoperative.
Once the different origins were ruled out: MongoDB, SQL queries, memory cache … I noticed that the logs were erratic, I didn’t see them as in a Unix with a tail -f, but I saw them in jumps.
What if this was the problem?
Indeed, my assumption was as simple as: With FastCGI multiple php5-cgi.exe processes are launched that receive the php code and process it, and if something has Windows with files, especially NTFS, it is a great difficulty to be able to add information at the end of a file from multiple processes. In this case, the simple error_log() that were launched caused locks between the different FastCGI processes.
Only by eliminating all error_log and similar recordings to files, and passing it to a database, everything returned to normal, correct speed.
In summary: If there is no other choice but to use an IIS with FastCGI + PHP, under no concept use any file for logs, or functions like error_log() (which do the same) since we will encounter locks of the different processes when accessing that file and adding the information. In theory, recording a basic log in a database is less efficient than doing it in plain text in a file, but in Windows we will have no choice but to resolve it this way.
Note: I don’t know if apache (mod_php) in windows has this problem.
I have searched the Internet for some information about this problem, but I have not found absolutely anything.
Comments