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: Add skiplist to APR 1.5 (Was: Re: event MPM (Was: Re: Planning for 2.4.7 in Oct))
+1... On Sep 28, 2013, at 12:12 PM, Graham Leggett minf...@sharp.fm wrote: On 26 Sep 2013, at 15:44, Jim Jagielski j...@jagunet.com wrote: Like I said, I think that skiplist fits better in APR; in fact there are a few other things in httpd that would be better in APR, but APR and httpd are 2 sep projects and so we can't force things. In fact, I'm adding dev@apr to the To: line :) +1 on apr, it seems a sensible addition alongside the hash and table implementations. Regards, Graham --
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: Streamlining/improving ephemeral key handling in mod_ssl?
On 29.09.2013 19:48, Hanno Böck wrote: What needs to happen so this can be backported to 2.4? Testing patches and reporting on its results e.g. (as previously solicited in this thread). I have put a backport of the relevant trunk commits under https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff and will soon add it as a proposal to 2.4.x/STATUS (if my remaining tests with 2.4.6-dev are successful). The backport proposal then needs consensus approval, as explained under http://httpd.apache.org/dev/guidelines.html, so at least two +1 from other devs are needed as well. Kaspar
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: [PATCH 55593] Add SSLServerInfoFile directive
On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 28.09.2013 18:34, Dr Stephen Henson wrote: How about something like: int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd); which can return things like... SSL_CONF_TYPE_INVALID:unrecognised name. SSL_CONF_TYPE_FILE: file name. SSL_CONF_TYPE_DIR:directory name. ... others ... SSL_CONF_TYPE_STR:string with no special meaning. Sounds good, yes. Sounds fine to me. But another wrinkle is occurring to me: We're going to need different ServerInfo files for different certs (since things like Certificate Transparency and TACK will return different data depending on the server's cert/key). The OpenSSL code was written on the assumption of one ServerInfo file per SSL_CTX, so will need a bit of rework. But it's worth discussing what the API should be. There are currently 8 possible key/cert types in OpenSSL (ssl/ssl_locl.h): #define SSL_PKEY_RSA_ENC 0 #define SSL_PKEY_RSA_SIGN 1 #define SSL_PKEY_DSA_SIGN 2 #define SSL_PKEY_DH_RSA 3 #define SSL_PKEY_DH_DSA 4 #define SSL_PKEY_ECC5 #define SSL_PKEY_GOST94 6 #define SSL_PKEY_GOST01 7 I think we'd rather not try to embed OIDs or whatever in the ServerInfo files. Perhaps the ServerInfoFile ConfCmd could be annotated to refer to these identifiers somehow? SSLOpenSSLConfCmd ServerInfoFile_RSA_ENC certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile_RSA_SIGN certs/ServerInfo2.pem - or - SSLOpenSSLConfCmd ServerInfoFile 0 certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile 1 certs/ServerInfo2.pem Any thoughts?? Trevor
