Re: [VOTE] Release mod_fcgid 2.3.8
Re: [VOTE] Release mod_fcgid 2.3.8
On Fri, Oct 4, 2013 at 6:23 AM, Steffen i...@apachelounge.com wrote: That looks better and so far I can see it is the behavior as with 2.3.7. Keep it running at AL. When I see some strange, I shall report. That is good news. I hope to tag and roll mod_fcgid 2.3.9 later in the day unless I hear of problems. For your info, the build warnings: Yeah :( The whole stack from APR on up needs attention. For now I verified that they don't get worse between 2.3.7 and current svn sources. warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c 339 warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c 411 warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data E:\VC11\Win64\2.4.6\include\http_protocol.h 414 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 69 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 116 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 121 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 40 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 104 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 209 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 312 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proctbl_win.c 71 On Friday 04/10/2013 at 03:59, Jeff Trawick wrote: On Thu, Oct 3, 2013 at 5:45 AM, Steffen i...@apachelounge.com wrote: Running in real at AL for an hour with patch revert-r1377398.txt Results, see www.apachelounge.com/status-revert-r1377398.html Observation: No hanging with working and no accesses anymore Still quite some more processes: with 2.3.7 1-3 and now 8 Processes with idle time more then 300 (default) is still there, a process has 1818 seconds and stays with 11 accesses and it does not stop/kill. The diff with 2.3.7 that there are more entries with Process: In 2.3.7 I saw only one entry, never more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. .. As you can see in 2.3.8 more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) ... .. etc. Back to 2.3.7 Steffen, thanks again for sticking with this. I've had trouble finding the time myself :( I've committed the last patch you tried, as well as one additional fix which could explain your latest results. (r1529062) Please try the latest from svn, or add this very minor change on top of the revert-r1377398.txt patch: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c?r1=1529062r2=1529061pathrev=1529062 These two uninitialized fields on Windows could prevent finding a suitable, existing FastCGI process when one is needed. (This was a regression in 2.3.8.) Thanks!! *From:* Jeff Trawick traw...@gmail.com *Sent:* Wednesday, October 2, 2013 2:10 AM *To:* Apache HTTP Server Development List dev@httpd.apache.org *Subject:* Re: [VOTE] Release mod_fcgid 2.3.8 On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.comwrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.comwrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without
Re: [VOTE] Release mod_fcgid 2.3.8
On Fri, Oct 4, 2013 at 8:19 AM, Jeff Trawick traw...@gmail.com wrote: On Fri, Oct 4, 2013 at 6:23 AM, Steffen i...@apachelounge.com wrote: That looks better and so far I can see it is the behavior as with 2.3.7. Keep it running at AL. When I see some strange, I shall report. That is good news. I hope to tag and roll mod_fcgid 2.3.9 later in the day unless I hear of problems. Starting that now... For your info, the build warnings: Yeah :( The whole stack from APR on up needs attention. For now I verified that they don't get worse between 2.3.7 and current svn sources. warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c 339 warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c 411 warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data E:\VC11\Win64\2.4.6\include\http_protocol.h 414 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 69 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 116 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 121 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 40 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 104 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 209 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 312 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proctbl_win.c 71 On Friday 04/10/2013 at 03:59, Jeff Trawick wrote: On Thu, Oct 3, 2013 at 5:45 AM, Steffen i...@apachelounge.com wrote: Running in real at AL for an hour with patch revert-r1377398.txt Results, see www.apachelounge.com/status-revert-r1377398.html Observation: No hanging with working and no accesses anymore Still quite some more processes: with 2.3.7 1-3 and now 8 Processes with idle time more then 300 (default) is still there, a process has 1818 seconds and stays with 11 accesses and it does not stop/kill. The diff with 2.3.7 that there are more entries with Process: In 2.3.7 I saw only one entry, never more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. .. As you can see in 2.3.8 more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) ... .. etc. Back to 2.3.7 Steffen, thanks again for sticking with this. I've had trouble finding the time myself :( I've committed the last patch you tried, as well as one additional fix which could explain your latest results. (r1529062) Please try the latest from svn, or add this very minor change on top of the revert-r1377398.txt patch: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c?r1=1529062r2=1529061pathrev=1529062 These two uninitialized fields on Windows could prevent finding a suitable, existing FastCGI process when one is needed. (This was a regression in 2.3.8.) Thanks!! *From:* Jeff Trawick traw...@gmail.com *Sent:* Wednesday, October 2, 2013 2:10 AM *To:* Apache HTTP Server Development List dev@httpd.apache.org *Subject:* Re: [VOTE] Release mod_fcgid 2.3.8 On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.comwrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.comwrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.comwrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow
Re: [VOTE] Release mod_fcgid 2.3.8
K On 4 okt. 2013, at 22:15, Jeff Trawick traw...@gmail.com wrote: On Fri, Oct 4, 2013 at 8:19 AM, Jeff Trawick traw...@gmail.com wrote: On Fri, Oct 4, 2013 at 6:23 AM, Steffen i...@apachelounge.com wrote: That looks better and so far I can see it is the behavior as with 2.3.7. Keep it running at AL. When I see some strange, I shall report. That is good news. I hope to tag and roll mod_fcgid 2.3.9 later in the day unless I hear of problems. Starting that now... For your info, the build warnings: Yeah :( The whole stack from APR on up needs attention. For now I verified that they don't get worse between 2.3.7 and current svn sources. warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c339 warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proc_win.c411 warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of dataE:\VC11\Win64\2.4.6\include\http_protocol.h 414 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 69 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 116 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_bridge.c 121 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 40 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 104 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 209 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_pm_main.c 312 warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data E:\VC11\Win64\2.4.6\modules\mod_fcgid-2.3.8\fcgid_proctbl_win.c 71 On Friday 04/10/2013 at 03:59, Jeff Trawick wrote: On Thu, Oct 3, 2013 at 5:45 AM, Steffen i...@apachelounge.com wrote: Running in real at AL for an hour with patch revert-r1377398.txt Results, see www.apachelounge.com/status-revert-r1377398.html Observation: No hanging with working and no accesses anymore Still quite some more processes: with 2.3.7 1-3 and now 8 Processes with idle time more then 300 (default) is still there, a process has 1818 seconds and stays with 11 accesses and it does not stop/kill. The diff with 2.3.7 that there are more entries with Process: In 2.3.7 I saw only one entry, never more: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) .. .. .. As you can see in 2.3.8 more: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) .. .. Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) ... .. etc. Back to 2.3.7 Steffen, thanks again for sticking with this. I've had trouble finding the time myself :( I've committed the last patch you tried, as well as one additional fix which could explain your latest results. (r1529062) Please try the latest from svn, or add this very minor change on top of the revert-r1377398.txt patch: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c?r1=1529062r2=1529061pathrev=1529062 These two uninitialized fields on Windows could prevent finding a suitable, existing FastCGI process when one is needed. (This was a regression in 2.3.8.) Thanks!! From: Jeff Trawick Sent: Wednesday, October 2, 2013 2:10 AM To: Apache HTTP Server Development List Subject: Re: [VOTE] Release mod_fcgid 2.3.8 On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.comwrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage
Re: [VOTE] Release mod_fcgid 2.3.8
Running in real at AL for an hour with patch revert-r1377398.txt Results, see www.apachelounge.com/status-revert-r1377398.html Observation: No hanging with working and no accesses anymore Still quite some more processes: with 2.3.7 1-3 and now 8 Processes with idle time more then 300 (default) is still there, a process has 1818 seconds and stays with 11 accesses and it does not stop/kill. The diff with 2.3.7 that there are more entries with Process: In 2.3.7 I saw only one entry, never more: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) .. .. .. As you can see in 2.3.8 more: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) .. .. Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) ... .. etc. Back to 2.3.7 From: Jeff Trawick Sent: Wednesday, October 2, 2013 2:10 AM To: Apache HTTP Server Development List Subject: Re: [VOTE] Release mod_fcgid 2.3.8 On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! Steffen, by chance can you test the full revert of r1377398 (and follow-on fixes), at http://people.apache.org/~trawick/revert-r1377398.txt (CR-LF to make your GNU patch happy ;) ) I tested before and after on Windows using a trivial PHP script and php-cgi.exe. I didn't see the issue Steffen saw, but it definitely used a lot fewer processes after reverting. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Thu, Oct 3, 2013 at 5:45 AM, Steffen i...@apachelounge.com wrote: Running in real at AL for an hour with patch revert-r1377398.txt Results, see www.apachelounge.com/status-revert-r1377398.html Observation: No hanging with working and no accesses anymore Still quite some more processes: with 2.3.7 1-3 and now 8 Processes with idle time more then 300 (default) is still there, a process has 1818 seconds and stays with 11 accesses and it does not stop/kill. The diff with 2.3.7 that there are more entries with Process: In 2.3.7 I saw only one entry, never more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. .. As you can see in 2.3.8 more: *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) .. .. *Process: php-cgi.exe* (d:/servers/apache/php/php-cgi.exe) ... .. etc. Back to 2.3.7 Steffen, thanks again for sticking with this. I've had trouble finding the time myself :( I've committed the last patch you tried, as well as one additional fix which could explain your latest results. (r1529062) Please try the latest from svn, or add this very minor change on top of the revert-r1377398.txt patch: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_pm_win.c?r1=1529062r2=1529061pathrev=1529062 These two uninitialized fields on Windows could prevent finding a suitable, existing FastCGI process when one is needed. (This was a regression in 2.3.8.) Thanks!! *From:* Jeff Trawick traw...@gmail.com *Sent:* Wednesday, October 2, 2013 2:10 AM *To:* Apache HTTP Server Development List dev@httpd.apache.org *Subject:* Re: [VOTE] Release mod_fcgid 2.3.8 On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.comwrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! Steffen, by chance can you test the full revert of r1377398 (and follow-on fixes), at http://people.apache.org/~trawick/revert-r1377398.txt (CR-LF to make your GNU patch happy ;) ) I tested before and after on Windows using a trivial PHP script and php-cgi.exe. I didn't see the issue Steffen saw, but it definitely used a lot fewer processes after reverting. -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
I can confirm that this makes 2.3.8 act more like 2.3.7... On Sep 30, 2013, at 8:12 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Sep 30, 2013 at 5:23 AM, Steffen i...@apachelounge.com wrote: Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-cgi.exe .php /Files Hi Steffen, Are you able to try this patch? http://people.apache.org/~trawick/restore-fcgid-2.3.7-process-count-r1.txt This reverts one of the changes in 2.3.8 that affects how soon mod_fcgid will create a new process when one isn't immediately available. With this backed out, my simple testcase uses 11-12 processes like 2.3.7 instead of 20 processes like 2.3.8. TIA! On Monday 30/09/2013 at 01:36, Jeff Trawick wrote: On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17 �� 192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) So far I've only set up a simple test... Simple perl FastCGI script, ab -n 20 -c 20, default main vhost configuration, this for the vhost: VirtualHost *:8082 FCGIDCmdOptions /home/trawick/myhg/apache/fcgid/apps/altinfo.pl \ InitialEnv VHOST=any \ InitialEnv PERL5LIB=/home/trawick/perl5/lib/perl5 /VirtualHost 2.3.7 grows up to about 12 (vs. max 20 concurrent clients). 2.3.8 grows up to about 20. I got both the fastest and slowest times for 200,000 requests using 2.3.8. Generally I suspect 2.3.7 is slightly faster, but I don't have a good overall summary. If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses parameter to something that your system can handle. Otherwise, see FcgidMaxProcesses and FcgidMaxProcessesPerClass. Regardless of 2.3.7 or 2.3.8. Still, for this simple scenario + configuration, 2.3.7 would have been better (generally not worse performance, uses 40% fewer processes). Different scenarios would have different results, but I think that the common, fat PHP processes would have bigger problems with 2.3.8 if there is no reasonable configured limit on the
Re: [VOTE] Release mod_fcgid 2.3.8
On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Tue, Oct 1, 2013 at 6:57 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Oct 1, 2013 at 8:35 AM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:00 PM, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. This release is scrapped based on Steffen's test results. I know of one 2.3.8 change to back out that restores better behavior in my testing, but we don't have a proposed fix for everything that Steffen saw: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. I suspect that all I can manage today is to move my test to Windows and see if that behavior shows up. The previous patch I suggested was just a small bit of 1377398. I am testing a complete revert of that, as well as the two follow-up changes 1397778 and 1527358. With luck I'll even see Steffen's problem on Windows without it, but even if not I'll share the new one. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ Steffen, by chance can you test the full revert of r1377398 (and follow-on fixes), at http://people.apache.org/~trawick/revert-r1377398.txt (CR-LF to make your GNU patch happy ;) ) I tested before and after on Windows using a trivial PHP script and php-cgi.exe. I didn't see the issue Steffen saw, but it definitely used a lot fewer processes after reverting. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-cgi.exe .php /Files On Monday 30/09/2013 at 01:36, Jeff Trawick wrote: On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317 �� 192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) So far I've only set up a simple test... Simple perl FastCGI script, ab -n 20 -c 20, default main vhost configuration, this for the vhost: VirtualHost *:8082 FCGIDCmdOptions /home/trawick/myhg/apache/fcgid/apps/altinfo.pl \ InitialEnv VHOST=any \ InitialEnv PERL5LIB=/home/trawick/perl5/lib/perl5 /VirtualHost 2.3.7 grows up to about 12 (vs. max 20 concurrent clients). 2.3.8 grows up to about 20. I got both the fastest and slowest times for 200,000 requests using 2.3.8. Generally I suspect 2.3.7 is slightly faster, but I don't have a good overall summary. If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses parameter to something that your system can handle. Otherwise, see FcgidMaxProcesses and FcgidMaxProcessesPerClass. Regardless of 2.3.7 or 2.3.8. Still, for this simple scenario + configuration, 2.3.7 would have been better (generally not worse performance, uses 40% fewer processes). Different scenarios would have different results, but I think that the common, fat PHP processes would have bigger problems with 2.3.8 if there is no reasonable configured limit on the max to spawn. Does anyone else have time to play? On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Mon, Sep 30, 2013 at 5:23 AM, Steffen i...@apachelounge.com wrote: Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/** WINDOWS/system32;C:/WINDOWS;C:**/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-**cgi.exe .php /Files Hi Steffen, Are you able to try this patch? http://people.apache.org/~trawick/restore-fcgid-2.3.7-process-count-r1.txt This reverts one of the changes in 2.3.8 that affects how soon mod_fcgid will create a new process when one isn't immediately available. With this backed out, my simple testcase uses 11-12 processes like 2.3.7 instead of 20 processes like 2.3.8. TIA! On Monday 30/09/2013 at 01:36, Jeff Trawick wrote: On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17 �� 192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) So far I've only set up a simple test... Simple perl FastCGI script, ab -n 20 -c 20, default main vhost configuration, this for the vhost: VirtualHost *:8082 FCGIDCmdOptions /home/trawick/myhg/apache/**fcgid/apps/altinfo.pl \ InitialEnv VHOST=any \ InitialEnv PERL5LIB=/home/trawick/perl5/**lib/perl5 /VirtualHost 2.3.7 grows up to about 12 (vs. max 20 concurrent clients). 2.3.8 grows up to about 20. I got both the fastest and slowest times for 200,000 requests using 2.3.8. Generally I suspect 2.3.7 is slightly faster, but I don't have a good overall summary. If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses parameter to something that your system can handle. Otherwise, see FcgidMaxProcesses and FcgidMaxProcessesPerClass. Regardless of 2.3.7 or 2.3.8. Still, for this simple scenario + configuration, 2.3.7 would have been better (generally not worse performance, uses 40% fewer processes). Different scenarios would have different results, but I think that the common, fat PHP processes would have bigger problems with 2.3.8 if there is no reasonable configured limit on the max to spawn. Does anyone else have time to play? On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at
Re: [VOTE] Release mod_fcgid 2.3.8
Still not going well with patch restore-fcgid-2.3.7-process-count-r1.txt See for details http://www.apachelounge.com/status.html I notice: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. Back to 2.3.7 From: Jeff Trawick Sent: Monday, September 30, 2013 2:12 PM To: Apache HTTP Server Development List Subject: Re: [VOTE] Release mod_fcgid 2.3.8 On Mon, Sep 30, 2013 at 5:23 AM, Steffen i...@apachelounge.com wrote: Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-cgi.exe .php /Files Hi Steffen, Are you able to try this patch? http://people.apache.org/~trawick/restore-fcgid-2.3.7-process-count-r1.txt This reverts one of the changes in 2.3.8 that affects how soon mod_fcgid will create a new process when one isn't immediately available. With this backed out, my simple testcase uses 11-12 processes like 2.3.7 instead of 20 processes like 2.3.8. TIA!
Re: [VOTE] Release mod_fcgid 2.3.8
On Mon, Sep 30, 2013 at 12:22 PM, Steffen i...@apachelounge.com wrote: Still not going well with patch restore-fcgid-2.3.7-process-**count-r1.txt See for details http://www.apachelounge.com/**status.htmlhttp://www.apachelounge.com/status.html I notice: - just one process is serving. - rest is just “hanging” as working with no accesses and high idle time. Back to 2.3.7 Thanks... I'll see if I can encounter this issue and look for another change to revert. From: Jeff Trawick Sent: Monday, September 30, 2013 2:12 PM To: Apache HTTP Server Development List Subject: Re: [VOTE] Release mod_fcgid 2.3.8 On Mon, Sep 30, 2013 at 5:23 AM, Steffen i...@apachelounge.com wrote: Running at AL now 2.3.7 again, all fine again with 1-3 processes instead of the 30+ with 2.3.8. The config live running here and your config for synthetic test is different. And not using fat php processes and max processes is in place. Not any mod_fcgid directives here in a vhost, only in server the commonly used config for php. All vhosts here serving .php, including the default vhost. Running server 2012. IfModule fcgid_module FcgidInitialEnv PHPRC d:/servers/apache/conf/ FcgidInitialEnv PATH d:/servers/apache/php;C:/** WINDOWS/system32;C:/WINDOWS;C:**/WINDOWS/System32/Wbem; FcgidInitialEnv SystemRoot C:/Windows FcgidInitialEnv SystemDrive C: FcgidInitialEnv TEMP C:/WINDOWS/Temp FcgidInitialEnv TMP C:/WINDOWS/Temp FcgidInitialEnv windir C:/WINDOWS FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000 FcgidMaxRequestsPerProcess 1000 FcgidMaxProcesses 50 FcgidMaxRequestLen 8131072 # added for z-push iPhone FcgidIOTimeout 7200 FcgidConnectTimeout 180 FcgidBusyTimeout 7200 /IfModule Files ~ \.php$ AddHandler fcgid-script .php FcgidWrapper d:/servers/apache/php/php-**cgi.exe .php /Files Hi Steffen, Are you able to try this patch? http://people.apache.org/~**trawick/restore-fcgid-2.3.7-** process-count-r1.txthttp://people.apache.org/~trawick/restore-fcgid-2.3.7-process-count-r1.txt This reverts one of the changes in 2.3.8 that affects how soon mod_fcgid will create a new process when one isn't immediately available. With this backed out, my simple testcase uses 11-12 processes like 2.3.7 instead of 20 processes like 2.3.8. TIA! -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On 29 September 2013 20:00, Jeff Trawick traw...@gmail.com wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ +1 ] Release mod_fcgid 2.3.8 as GA tested on Debian 7 with PHP 5.4 (distro) and 5.5 (dotdeb) I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036214317192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/**dist/mod_fcgid/http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/** dist/mod_fcgid/CHANGES-FCGIDhttp://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-**cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) So far I've only set up a simple test... Simple perl FastCGI script, ab -n 20 -c 20, default main vhost configuration, this for the vhost: VirtualHost *:8082 FCGIDCmdOptions /home/trawick/myhg/apache/fcgid/apps/altinfo.pl \ InitialEnv VHOST=any \ InitialEnv PERL5LIB=/home/trawick/perl5/lib/perl5 /VirtualHost 2.3.7 grows up to about 12 (vs. max 20 concurrent clients). 2.3.8 grows up to about 20. I got both the fastest and slowest times for 200,000 requests using 2.3.8. Generally I suspect 2.3.7 is slightly faster, but I don't have a good overall summary. If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses parameter to something that your system can handle. Otherwise, see FcgidMaxProcesses and FcgidMaxProcessesPerClass. Regardless of 2.3.7 or 2.3.8. Still, for this simple scenario + configuration, 2.3.7 would have been better (generally not worse performance, uses 40% fewer processes). Different scenarios would have different results, but I think that the common, fat PHP processes would have bigger problems with 2.3.8 if there is no reasonable configured limit on the max to spawn. Does anyone else have time to play? On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/**dist/mod_fcgid/http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/** dist/mod_fcgid/CHANGES-FCGIDhttp://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [VOTE] Release mod_fcgid 2.3.8
Hi Jeff, at least I can say from another build that I have made that r1500307 does not have that issue on my box Debian Box. There are the number of processes that I see in htop and on the server status page the same. So the issue might happen in a later revision. Hope that helps. (May some other can try r1500307 on Windows, too). On 29 September 2013 23:14, Jeff Trawick traw...@gmail.com wrote: On Sun, Sep 29, 2013 at 4:04 PM, Steffen i...@apachelounge.com wrote: Becoming dramatic here, already running over 30 processes. Running out of memory this way. All time high here is 5 processes, and while writing this mail it is already 34 and all 34 have an entry in the mod_status page. Also looks like it is not stopping/killing processes any more, have entries with 1784 seconds idle (FcgidIdleTimeout is default, 300) Going back to 2.3.7 at AL. On Sunday 29/09/2013 at 21:15, Steffen wrote: Observe a different behavior compared to 2.3.7 - It spawns a lot more mod_fcgid processes, looks like vhost is in charge (mod_fcgid only global defined here) - I see in Windows taskmanager and in mod_status 5 processes and the error log says that the are 3 started, a mismatch. - Also different in mod_status page, see more then one entry for Process: php-cgi.exe With 2.3.8 splitted now : Total FastCGI processes: 5 Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 46204874317Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 38405151095Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 65525574566Ready Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready With 2.3.7 was only one entry, like: Process: php-cgi.exe (d:/servers/apache/php/php-cgi.exe) PidActiveIdleAccessesState 320419627187Ready 5036 2143 17192Ready ... Not really trust 2.3.8 (yet), give me a few days to observe more. Thanks, Steffen. I'll try to reproduce soon and see which commit changed that. (Maybe 1377398?) On Sunday 29/09/2013 at 20:01, Jeff Trawick wrote: Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/ Shortcut to changes: http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID +/-1 [ ] Release mod_fcgid 2.3.8 as GA I'll hold the vote open for 72 hours unless something out of the ordinary occurs. Thanks in advance for testing! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
