Forums
Ok, why is FASTCGI working with this configuration - but some other problems.
This is the following configuration being used on a Server 2003 Webserver
Windows Server 2003 - 32-Bit - Service Pack 2
IIS6
FastCGI handler 7.5.7693.0 (fbl_srv_iis_dev(ksingla).090415-1635) - ActivityTimeout=900 - IdelTimeout=300 - RequestTimeout=90 - InstanceMaxRequests=1000 - MaxInstances=50 - SignalBeforeTerminateSeconds=10 - ExePath= (redactedpathforsecurity)\php\php.exe PHP 4.4.9
eAccelerator 0.9.5.1
URL Scan 3.1
Native Compression Enabled - GZIP (Static: htm, html, css, js, txt - level 9) (Dynamic: php - level 9)
So, this configuration appears to be running and running pretty well. But after some further research it seems as if we should be running a "non thread safe" version of PHP instead of the thread safe PHP 4.4.9 binaries that we currently are running. I cannot seem to find any non-thread safe PHP 4X Windows Binaries and upgrading to PHP 5x (where they offer non-thread safe binaries) is not an option at the moment.
Question here is why is the configuration working when I've read that is shouldn't? Is there something we should be doing differently?
One thing we have noticed is IIS6 is not using the Kernel Mode Cache - See below
Web Service Cache
Current File Cache Memory Usage - 9639
Current Files Cached - 16
File Cache Hits - 93255
File Cache Hits % - 62,315
Kernel: Current URIs Cached - 0
Kernel: Total URIs Cached - 0
Kernel: URI Cache Hits - 0
Kernel: URL Cache HIts % - 0
Maximum FIle Cache Memory Usage - 341276
Total Files Cached - 6409
Thanks in advance!
- Add new comment
- 4628 reads
Hi There,
If you are still using PHP 4.x then you have no choice but to use the Thread-Safe version of PHP, unless of course your choose to compile your own PHP binaries which in my view would be a wasted effort that should be directed at getting your PHP code version 5 compatible. This should not necessarily cause problems as the PHP core has been Thread-Safe for quite some time, it will only really cause you issues if you are using PHP extensions that are not Thread-Safe. There are also substanital perfomance benefits by moving to the PHP NTS binaries, however by using an OpCode cache such as you are a lot of this is negated. I notice you have MaxInstances set to 50. This value should be set to the same number of cores in your system as demonstrated in this article.
IIS kernel mode cache is something quite different, and only really useful for very high traffic sites where content does not differentiate between users (think at least dozens of hits on the same content every minute). The second part here is really quite important as using kernel mode cache on something like a forum site where content is almost certainly individual to the user can result in all sorts of issues. Have a read of this great blog post by David Wang, however I'd suggest you'd be far better off directing your efforts into getting your code PHP 5.x compliant so you are able to take advantage of the performance improvements of the NTS binaries and the WinCache module.
----------------
Dominic Ryan
6 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster
Thank You for the reply. We did some extensive testing yesterday - some of which involved the following:
Attempt to run PHP 5.2.X (failed - will mention below)
Moving back to PHP 4.4.9 ISAPI
Removing eaccelerator and installing Xcache
Switching to FASTCGI 0.6
Switching back to FASTCGI 1.5
Adjustments made in IIS Admin and fcgiexe.ini
I'll speak about the php 5.2.x issue later on in this post.
1st, as expected, going back to ISAPI without any opcode (eaccelerator) was pretty slow in comparison to what we were used to. We added back eaccelerator and as expected started getting the dreaded php errors that happen with ISAPI.
We then removed eaccelerator and tried XCache. Seemed to run fine but also seemed slower than the eaccelerator implementation under ISAPI (when it works). Didn't experience any crashes or errors.
We then moved from ISAPI to FASTCGI 0.6 (something that we previously used for some time. Again, this implementation didn't seem as fast as where we started (1.5/eaccelerator) but again no errors.
**On a side note**
One thing I remember from the past when we were running FASTCGI 0.6 and eaccelerator for a couple of years was the PHP processes would sometimes hang after awhile. We had solved this by periodically automatically running a KILLPHP command which seemed to keep things stable
**END Side Note**
We then moved back to FASTCGI 1.5 with XCache and noticed that although the Xcache admin was showing pages were cached, it seems as if they were disappearing then reappearing.
We then removed Xcache and reinstalled eaccelerator and made some adjustments to fcgiext.ini based off of trying multiple things gathered from your posts, other posts you've made in the past along with some various blogs, forums, etc.
ActivityTimeout= 900
IdleTimeout= 300
RequestTimeout= 900
InstanceMaxRequests= 1000
MaxInstances= 0
SignalBeforeTerminateSeconds= 30
For application pool serving the site in question, we also tried various settings and have (for the moment) ended up with the following
No recycling or pinging selected
Web Garden set to (4) (This particular server is dual single core)
Startup time limit 60
Shutdown time limit 60
So far with this, it seems as if the server is a bit more responsive to requests (especially on some pages where alot of images are displayed from a gallery using php and GD. The w3wp.exe all stay between 10,000K and 30,000K with 0 CPU usage. The php.exe processes seems to grow and shrink dynamically and normally sits about 10,000K to 25,000K but we have seen some grow to about 250,000K when a user tries to view a rather large image in a gallery (12756 X 3487 Pixels)
So again, with all the various things tried, it seems that these settings (for now) are resulting in the best stability and performance with what we have to work with. What are your feelings on this?
You mentioned in your previous post that the maxinstances we initially had set to 50 should be set to the number of cores in our system (2). As you can see we now have set maxinstances to 0 for "dynamic" based off of info found in this post http://www.ksingla.net/2010/05/goodness-of-dynamic-maxinstances-in-fastcgi/ Have you any experience or opinion on setting the maxinstances to 0 instead of 2 (number of cores in our system) as previously suggested? Also I previously mentioned that we changed the application pool web garden to 4 which has seemed to result in better web server response. What are you feelings on this/
Regarding the Kernel Mode Cache, I understand what you mean by potential issues caused by dynamic content individual to a user. The problem is that "nothing" is in the Kernel Cache at all. Will not having some static items like images, etc in the Kernel cache improve performance? If so, we cannot understand why nothing at all is in the Kernel Mode Cache and how can this be corrected?
Now regarding PHP 5.2.X. We tried an install of 5.2.x from the IIS Web platform installed and we were seeing this error afterwards
Call to undefined function: mysql_connect(). Please install the MySQL Connector for PHP
Tried researching this and could not find an answer as to what the problem might be. From initial research, it appears that our code "should" be PHP 5.2.X compatible so this seems this error is the only roadblock to moving forward on a php upgrade path.
Thank You for your reply and looking forward to your additional input.
Whole lot of stuff going on there. My suggestion is don't get too bogged down in the detail. Just quickly FastCGI 0.6 was developed by Shane Caraveo almost a decade ago and although it is the basis for the modern day FastCGI developed by the IIS team at Microsoft, the two should not be compared. Unless you have a very specific reason, you should only really be looking at the Windows FastCGI module these days. You are also correct regarding the MaxInstances value, I had forgot that this can now be set to a dynamic value. Still, rule of thumb applies and the MaxInstances being equal to system cores can be used safely (assuming of course the response output dose not exceed the ResponseBufferLimit value which by default is 4MB). Finally (for this portion at least), there really is no benefit in using a web garden when using FastCGI. The advantage of a web garden for PHP on IIS is that it increases concurrency, which when using FastCGI is redundant as uping the MaxInstances value has much the same effect. Web gardens & PHP should not longer be on the table as they were really only effective in specific cases when using the PHP ISAPI module on multi CPU/Core system (search this site for an article on that)
As for Kernel mode caching, have you done any analysis of your IIS log files to determine if it is truly required? That is do you see HTTP requests for a specific item being consistently bombarded (dozens of requests in any 10 second period) in the logs? If not, I strongly recommend you give kernel mode caching a miss as it is something that should be planned and implemented with consideration. Generally speaking this pretty much rules out forum or any highly dynamic content based sites. I urge you to really have a good read of the kernel mode caching link I posted earlier as well as the links coming off that article to get a better idea of what situations are suited for using kernel mode cache.
The mysql_connect() related error will be because the MySQL extension is built into PHP 4 and in PHP 5 you need to enabled it as a PECL extension. Search this site for instructions on how to do this. From what I can see from you site you host forums with semi regular purges of inactive users. The areas I see you best exploring for faster page loads to end users are;
1) Get you PHP apps PHP 5.x compliant and upgrade to at least the latest NTS version of PHP 5.2.x along with the WinCache module (which is an OpCode cache similar to APC & eAccelerator except designed specifically for FastCGI on IIS by Microsoft).
2) Being a forum with semi regular clean outs it should be safe to assume a large portion of your traffic consists of return visitors. Develop yourself a caching policy to maximise the use of client side browser caching (images, js, css and the like) and your interest in kernel mode caching will become all but redundant. Port80 software even make a cool product called CacheRight which takes a lot of the administrative pain out of this task.
3) If after the above users are still experiencing lag in loading times, first examine your logs for the time to last byte (TTLB) value which can be enabled in your IIS logs. Also look at your system resources as if you have a high TTLB with low CPU utilisation you will either have not enough PHP processes or the actual bandwidth to your server is not sufficient. If CPU usage, Memory Pages/Sec and Disk queue length are all off the scale, then your least problematic approach will be to look at upgrading your server. For this I advise getting a fresh OS build and just migrate your data.
----------------
Dominic Ryan
6 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster
Thank You very much for the reply. I've got quite a bit to report back, but that will have to wait until next week when I have a bit less on my plate. I did want to report an interesting finding from some testing done over the week.
As I reported in my last post, during some testing of Xcache, I discovered cached items were disappearing as php processes closed out. I saw a post of yours where you reported
****
UPDATE
Unfortunately it seems that xCache is not compatible with the community version of FastCGI for IIS at this stage. Currently xCache only uses the mmap shared memory scheme which is bound to an individual php.exe process and all its child processes. This is so that the xCache cache is shared among all php.exe processes. FastCGI for IIS unfortunatley does not launch extra php.exe procccess as child processes of the original php.exe process as defined by the PHP_FCGI_CHILDREN variable, but rather they are spawned by the worker process (w3wp.exe) which contains the isapi_fcgi.dll module. The effect this has is that the xCache cache is cleared every time a new php.exe process is started, and also that the xCache cache is not shared amongst any of the running php.exe processes.
****
Well during some more testing with Eaccelerator and thread safe PHP 4.4.9 I noticed all the memory reported by eAccelerator as being "allocated" was sitting in the (2) w3wp.exe processes (Still currently testing with a 2 webgarden as it has been more responsive under load). 1/2 the amount of reported allocated memory is sitting in each w3wp.exe process. The FastCGI php.exe processes come and go as expected but the cached items from eAccelerator seem to stay put in the w3wp.exe processes as long as they are not recycled. We cannot recycle the w3wp.exe processes due to the fact that they will crash and generate a Faulting application w3wp.exe, version 6.0.3790.3959, faulting module ntdll.dll, version 5.2.3790.4789 error. As long as the processes are not recycled everything stays pretty stable.
Is this behavior expected or should eAccelerator under this scenario behave as XCache per your post?
Thank You very much for the reply. I've got quite a bit to report back, but that will have to wait until next week when I have a bit less on my plate. I did want to report an interesting finding from some testing done over the week.
As I reported in my last post, during some testing of Xcache, I discovered cached items were disappearing as php processes closed out. I saw a post of yours where you reported
****
UPDATE
Unfortunately it seems that xCache is not compatible with the community version of FastCGI for IIS at this stage. Currently xCache only uses the mmap shared memory scheme which is bound to an individual php.exe process and all its child processes. This is so that the xCache cache is shared among all php.exe processes. FastCGI for IIS unfortunatley does not launch extra php.exe procccess as child processes of the original php.exe process as defined by the PHP_FCGI_CHILDREN variable, but rather they are spawned by the worker process (w3wp.exe) which contains the isapi_fcgi.dll module. The effect this has is that the xCache cache is cleared every time a new php.exe process is started, and also that the xCache cache is not shared amongst any of the running php.exe processes.
****
Well during some more testing with Eaccelerator and thread safe PHP 4.4.9 I noticed all the memory reported by eAccelerator as being "allocated" was sitting in the (2) w3wp.exe processes (Still currently testing with a 2 webgarden as it has been more responsive under load). 1/2 the amount of reported allocated memory is sitting in each w3wp.exe process. The FastCGI php.exe processes come and go as expected but the cached items from eAccelerator seem to stay put in the w3wp.exe processes as long as they are not recycled. We cannot recycle the w3wp.exe processes due to the fact that they will crash and generate a Faulting application w3wp.exe, version 6.0.3790.3959, faulting module ntdll.dll, version 5.2.3790.4789 error. As long as the processes are not recycled everything stays pretty stable.
Is this behavior expected or should eAccelerator under this scenario behave as XCache per your post?
Ok, so still waiting for any comments/input on the previous post. Per the last post few things to report from testing.
We were hit with a considerable traffic spike which allowed us to do some real world testings on various things until we can find a switch to php 5.2 solution.
So on this particular box (WIMP stack) - during the traffic spike, we noticed the the CPU usage was continuously pegged and the service level was not too good.
Were we started at during this process was as I mentioned in a previous post
(FCGI Settings)
ActivityTimeout= 900
IdleTimeout= 300
RequestTimeout= 900
InstanceMaxRequests= 1000
MaxInstances= 0
SignalBeforeTerminateSeconds= 30
(IIS)
No recycling or pinging selected
Web Garden set to (4) (This particular server is dual single core)
Startup time limit 60
Shutdown time limit 60
With these settings at a lower traffic level, things seemed pretty stable but when traffic spiked, the CPUs maxed out although RAM usage was still pretty low
So during the spike we tried a few things and initially settled on this
(FASTCGI)
Disabled - moved back to PHP ISAPI
(IIS)
Tried recycling at 30 and 60 min intervals
Tried pinging enabled and disabled
Tried Web Garden set to (1, 2, 4 and 8) (This particular server is dual single core)
Startup time limit tried 10, 60 and 90
Shutdown time limit tried 10, 60 and 120
We found at this point that **initially** the ISAPI implementation in this scenario was more responsive than the FastCGI implementation. The problem though was the stability was horrible. The W3WP.exe processes would intermittently crash mostly during recycle times with a Faulting application w3wp.exe, version 6.0.3790.3959, faulting module ntdll.dll, version 5.2.3790.4789 error. We did some troubleshooting and found that this mostly happened when there was alot of activity on the portion of the site that uses a considerable amount of the PHP GD extension. So as you can imagine at this point the instability level was unacceptable and not able to be mitigated enough to provide the service level needed.
So we temporarily move resources so we could do some further testing and went back once again to the FASTCGI. We broke out WCAT and did some testing and after considerable back and forth found some interesting things
* We though the IIS compression (on static items) might be an issue. We also were looking at the PHP output buffer (which was only set to 4096 default) and the FASTCGI Response Buffer. Our pages initially (some are very heavy) showed compression as active with the default buffer settings. We tried setting the php buffer to 0, disabling all unused extensions. We also tried setting the FASTCGI response buffer to 0. This seemed to increase the site responsiveness considerably but only to a point. We noticed that with the buffers set to 0, the compression was no longer showing as active for site pages even though the compression setting for static content was still activated for the server on a global basis. For the time, we left it as is.
*Testing with WCAT. So we decided to test with WCAT and used our initial FAST CGI settings and the responses per second was pretty dismal. We started off with 1 then 10, 50, 100, 200 and 400 threads. We then changed various settings and found that the following settings provided the best response/sec along with the needed stability
[FASTCGI]
ActivityTimeout= 900
IdleTimeout= 300
RequestTimeout= 900
InstanceMaxRequests= 1000
MaxInstances= 2
SignalBeforeTerminateSeconds= 30
ResponseBufferLimit= 68157440
[IIS]
1 on webgarden
No recycling
No pinging
Startup and Shutdown - 60
[PHP]
Output Buffer 0
Now a few things on these current settings. You will notice that the response buffer is set quite high. We were unable to find concise information as to exactly what is effective here. During our testing with the response buffer set to 0 or even the 4MB default, we were not getting the desired results on some of our pages. With the buffer set to 0, the pages seemed very responsive but on our some of our image pages we found that larger images were not caching in the user's browser. We have one set of pages for example that brings up an image that is high resolution (example 2560X1600) but limits width and height display (via html) on that page. A user can click on the page to view the full resolution picture. Normally when that image is 1st loaded, it should cache in the user's browser so when they click on it to see it full size, there is not another download of the image a 2nd time from the site. With the buffer a 0, this was not happening. With the buffer at the high number we set, even the very largest image on the site (12756X3487 - 40MB) would cache properly.
With these new settings and testing with WCAT, we noticed that even with 400 threads the CPUs would get high but would not completely max out. The site would be less responsive than under normal load but it still would respond to an external visitor where before with the previous settings there was no hope of a response at all during that level of testing. During normal load the CPU usage is much lower than it was with the older settings.
Ok so that is where we are at with FastCGI and PHP4.4.9 We would appreciate any input or comments on this.
Now onto the PHP 5.2.17 NTS upgrade. We did some testing and found the PECL WIN32 extensions you metioned (I think it would be helpful for people to have a link as there was not one provided in your previous post - http://museum.php.net/php5/ )
So this resolved the previously reported MYSQL error and some other PHP sites on the box seem to run without issue. The main site still had a problem which we are attempting to resolve. I'll send you a list of the errors via email as I would rather not post these sort of specifics in this public post. I think that the errors are not so much a application compatibility issue with PHP5 (many others have reported the app should work with no issue) but instead maybe something else that is being missed in the PHP config.
Again, any input is appreciated.
Had an update to report.
We finally were able to resolve the issues that prevented the upgrade to PHP 5.2.17. Now we have upgraded a few things to report and some comments as well.
- There is a HUGE difference in performance and stability between our previous config (Windows, Thread Safe PHP 4.4.9 with eAccelerator and NTS PHP 5.2.17 with Wincache. It is a night and day difference so if you have the opportunity and ability - upgrading is well worth the time
- After witnessing the difference and experiencing the performance and stability issues with the older versions of PHP (4x) with FASTCGI and ISAPI including eAccelerator compared to PHP5/FastCGI/WinCache - just wondering what the developers were thinking? The previous stuff is absolutely horrible and a big headache. Sure you can patch/band-aid it to make it work (as we were). But at the core of the issue, why put something out that works so badly in the 1st place? On top of that, the support and documentation is severely lacking and shows a half thought out effort. The saying if you are going to do something - do it right or don't do it all really applies here
- Last we found it extremely disappointing with the consistent lack of timely input here at IIS-AID. The responses could be more concise and detailed as well. (The lack of a link to the PECL WIN32 binaries is an example). Its frustrating! Regardless, we do appreciate and want to thank those who responded.
- This brings up another point while taking a significant amount of time researching this issue. The search results on Google and other search engines are becoming rubbish. 1st you have scrapers who are pulling snippets from sites such as IIS-AID which just lead in big circles that lead to not finding any sort of a real answer or solution. Then when you find the source, the responses lack necessary detail and make you wonder if any of the responders have any idea what they are talking about. Don't get me wrong, this is not the case with every site and responder - but you find more rubbish than anything.
If anyone runs into any of these issues, just drop us an email and we would be glad to offer any of what we learned in resolving this issue.
Glad you're seeing some results. I can appreciate the frustration of not being able to find the documentation you are looking for or getting the answers you want as quick as you like. It is essential however you keep in mind that everything from the PHP application you are using (PHPBB), to PHP itself and also all the content/replies on IIS-Aid are only possible because skilled people are giving what spare time they do have to help others and as such getting answers in what you might perceive as a timely manner is not always possible. Added to this is the fact PHP4 was discontinued almost 4 years ago, so it shouldn't be that surprising that finding relevant content is hard to come by. Lesson to be learnt is just how important it is to maintain your systems.
Also, I'm not sure how/where you think that there is detail lacking in the responses you've been given here. In your first post you were looking at solutions (kernel mode caching) without doing the necessary investigation to see if it was suited to your issue. I tried to provide advise on why kernel mode caching wasn't suited (with links that included details on how items are inserted into the kernel mode cache) and in my second post along with urging you to have a good read of previously linked content I also very clearly broke a plan of action down into 3 steps, which by your report here you have seen very good results from having just followed the first step of that plan.
---------------
Dominic Ryan
6 x Microsoft IIS MVP, MCSE, MCSA
IIS Aid owner/webmaster
Dominic,
Thanks again for the response. Again, I'm appreciative for any input received regarding posted issues and concerns. I also understand what its like to not have much spare time. I along with those I work with try to take the approach that if we take involvement in a project, user issue, etc. - in a way we kind of make a commitment to see it through as timely as possible all while remembering what it is like to be on both sides. I also feel that when something is put out ( software, service/help related content/sites, etc) that type of commitment is even more important/relevant. In our experience a week or more between responses seems to be a bit excessive knowing that there is someone on the other end who might be waiting. The "do unto others" approach should be considered especially in community driven projects/software/systems as you never know when you might be sitting on the other side.
Yes, PHP4 was discontinued some time ago. This should mean that finding "relevant" content would be less of an issue compared to that of newer software due to the expected combined experiences and collaboration by the users of the older software. The problem is that detailed and clear documentation seems to have been a consistent weakness in some cases not only with PHP (iis - the non open source part) but with other open source projects as well. This along with the expanding pollution of the search space (as I previously mentioned) just makes things more difficult where they shouldn't be.
It should be noted that there are situations where "upgrading" is not an indication of lack of systems maintenance but instead just that such an upgrade is an unavailable option for various reasons. In this situation (especially considering the horrible implementation of php4 and iis6) upgrading was definitely the answer. I do know that there are those that such an upgrade is not an option and I believe that there are things that can be done to help their issues to be a bit more manageable.
This brings me to my next point. I appreciate your action plan (which we've been following and I'll follow up on below) but initially this is not what I was primarily looking for. Your plan discussed basically moving away (upgrading) from the PHP4/IIS6 implementation (which I understand made the best sense) but the immediate need was to find options and documentation with what we (and others current still are) were working with. This approach vaguely reminded me of stories from "once upon a time" of Dell or Microsoft tech support representatives almost immediately suggesting to completely erase a hard drive and reload fresh software at any indication of the slightest issue that might take some of their time and effort to resolve. You mentioned in your action plan "Port 80". Prior to this posting, I've had the opportunity of working with them and it is they who suggested investigating implementing use of the "Kernel Cache". Unfortunately the linked documentation you provided did not provide enough clear information to provide answers regarding applicability or implementition of the Kernel Cache in our situation.
I do hope that perhaps some input on our previous posts could be provided as this might be helpful for those who might be in the same situation. I can say there is very little documentation available for those who wish to improve the performance of some applications dependent upon a php4/iis6 scenario. As I mentioned before, anyone can contact us and we will be glad to provide what was learned during our testing and how we were able to successfully upgrade from PHP4.
Regarding your action plan
- As you know, we have brought our apps into PHP5.x compliance and have upgraded to the latest NTS PHP 5.2.x with Wincache. We had been working on this for some time prior to our post here but unfortunately the documentation and support for accomplishing this with our platform/implementation is severely lacking. We are investigating PHP 5.3.X and we will start another thread with some questions not only on this but better implementation and use of WinCache as once again, the documentation is not very clear (example, what are the best settings for the ResponseBufferLimit in FastCGI, etc)
- We do have and are continuing to develop an expanded caching policy. Some of this we are hoping to use some of the new WinCache features. As I mentioned, we have worked with Port80 and although they might have a decent "paid" (and applicable in some situations) solution, I think it is beneficial to gain the understanding and knowledge from self implementation/administration (along with sharing those experiences with others in similar circumstances) of features offered by their product.
- At this point I think we are ok on both hardware and bandwidth. Of course the hardware vendors are always pushing (upgrade, upgrade, upgrade your servers) even when it is unnecessary. I think that some administrators do not do enough (especially those with expansive budgets) to learn how to maximize the use of their existing resources.
Thank You again
MT
User login
Location: Melbourne, Australia
Joined: Sep 2003