Re: [Mod-fcgid-users] Weird behavior or what?

2009-08-25 Thread Ivan Voras
2009/8/19 Noor mlist-fc...@orientalsensation.com:

tldr;

 According to these findings, the best benchmark is when
 MaxProcessCount is set to 8 (which is number of CPU's). Is this just
 an accident? According to so many tips and pages I read on the

No. In general, a thread-pool design, which is what mod_fcgid+PHP
effectively emulates, will peak with the number of worker threads
equal to the number of active CPUs. Note that this is in fact a very
logical result, since PHP processing is CPU-bound.

 Internet (and even its default value,) this variable should be around
 100. If you notice the last benchmark, when I put 64 in this variable,

This might be true in the general case if PHP is used as mod_php and
Apache handles not only PHP requests but also other, static content
delivery (which make serving IO and network latency bound). In that
case, and interpolated over real-life workload, increasing the number
of server threads or processes to high number will be beneficial
simply because the vast majority of them will sleep in a point in
time.

 I got 26 failed transactions. While when I put only 8 working
 processes, I got no failures and the benchmark had the best times and
 records!

Overloading your CPUs can do that, yes.

 And while you're at it, I'll through in another question: How does
 eAccelerator/FastCGI manage the shared memory segments? According to

Very, very badly, and for silly reasons too. APC and eAccelerator
could be upgraded with code that would make them use truly shared
memory, but for whatever reasons (possibly nobody has paid for the
development), they don't.

-- 
f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users


Re: [Mod-fcgid-users] Weird behavior or what?

2009-08-19 Thread Jason
Way too involved of a question for this list :)

I'd suspect that your application is fairly heavy judging from avg response
times and that if you ran it from a script without involving fastcgi or
apache you'd see similar throughput.



On Wed, Aug 19, 2009 at 2:45 PM, Noor mlist-fc...@orientalsensation.comwrote:

 Hello list.

 (I hope I'm posting to the right mailing list. If not, then I
 apologize already and ask you to direct me to the right list. Thanks!)

 I've setup the following configuration on a Dell 2940 2 x Quad-Core
 with 4GB RAM:

 - FreeBSD 7.2-STABLE amd64 bit. Kernel recompiled with minimal
 options, no optimizations done.
 - /etc/sysctl.conf includes: kern.ipc.shmmax=134217728,
 kern.ipc.semvmx=131068
 - Apache worker-MPM V2.2.11_7 from ports -- required modules active
 only, no optimizations done.
 - mod_fcgid V2.2 from ports, no optimizations done.
 - PHP 5.2.10, compiled from source with options to activate FastCGI.
 - eAccelerator 0.9.5.3, compiled from source with options to activate
 shared memory.

 Now, I've been testing load using siege and I'm either not
 understanding the whole concept of processes/threads of Apache (and
 fcgid's processes) or every other documentation and tip I found on the
 Internet is irrelevant! I will detail next:

 Siege configuration:
 
 version: 2.66
 verbose: false
 debug: true
 protocol: HTTP/1.1
 connection: close
 concurrent users: 100
 time to run: n/a
 repetitions: 50
 socket timeout:  30
 delay: 1 sec
 internet simulation: false
 benchmark mode: false
 failures until abort: 1024
 named URL: none
 URLs file: /usr/local/etc/urls.txt
 logging: true
 log file: /var/log/siege.log
 resource file: /root/.siegerc
 allow redirects: true
 allow zero byte data: true
 allow chunked encoding: true

 Base httpd.conf include the following settings:
 
 ServerLimit: 64
 ThreadLimit: 128
 MaxClients: 1024

 The following 3 snippets detail loads I've done with siege.
 For all tests, I've setup eAccelerator (compiled from source with
 shared-memory enabled) with 32MB of mem_only optimization.
 Parameters I've setup for siege are detailed before the (+++) signs,
 results after them:

 StartServers 4
 ThreadsPerChild 64
 MinSpareThreads 32
 MaxSpareThreads 64
 MaxProcessCount 8
 DefaultMaxClassProcessCount 8
 DefaultMinClassProcessCount 0
 
 ransactions: 5092 hits
 Availability: 99.98 %
 Elapsed time: 170.01 secs
 Data transferred: 78.40 MB
 Response time: 2.46 secs
 Transaction rate: 29.95 trans/sec
 Throughput: 0.46 MB/sec
 Concurrency: 73.78
 Successful transactions: 4720
 Failed transactions: 1
 Longest transaction: 27.70
 Shortest transaction: 0.05

 StartServers 4
 ThreadsPerChild 64
 MinSpareThreads 32
 MaxSpareThreads 64
 MaxProcessCount 16
 DefaultMaxClassProcessCount 16
 DefaultMinClassProcessCount 0
 
 ransactions: 5091 hits
 Availability: 99.96 %
 Elapsed time: 242.89 secs
 Data transferred: 78.38 MB
 Response time: 3.75 secs
 Transaction rate: 20.96 trans/sec
 Throughput: 0.32 MB/sec
 Concurrency: 78.70
 Successful transactions: 4719
 Failed transactions: 2
 Longest transaction: 26.10
 Shortest transaction: 0.06

 StartServers 4
 ThreadsPerChild 64
 MinSpareThreads 32
 MaxSpareThreads 64
 MaxProcessCount 128
 DefaultMaxClassProcessCount 64
 DefaultMinClassProcessCount 0
 
 ransactions: 5067 hits
 Availability: 99.49 %
 Elapsed time: 322.76 secs
 Data transferred: 78.11 MB
 Response time: 5.31 secs
 Transaction rate: 15.70 trans/sec
 Throughput: 0.24 MB/sec
 Concurrency: 83.30
 Successful transactions: 4695
 Failed transactions: 26
 Longest transaction: 29.34
 Shortest transaction: 0.10

 According to these findings, the best benchmark is when
 MaxProcessCount is set to 8 (which is number of CPU's). Is this just
 an accident? According to so many tips and pages I read on the
 Internet (and even its default value,) this variable should be around
 100. If you notice the last benchmark, when I put 64 in this variable,
 I got 26 failed transactions. While when I put only 8 working
 processes, I got no failures and the benchmark had the best times and
 records!

 Anyone please care to explain why this is happening?

 And while you're at it, I'll through in another question: How does
 eAccelerator/FastCGI manage the shared memory segments? According to
 eAccelerator's homepage, it'll share such segments when the spawning
 process is shared. In the case of FastCGI (mod_fcgid), *who* is the
 spawning process? And this spawning process, how many cgi-php
 processes it'll spawn? (which if I understand correctly, such cgi-php
 processes would share eAccelerator's cached scripts as they've got one
 father).

 Kindly, someone knowledgeable with all these technologies care to
 explain and shed more light, for me and for others maybe...

 Thanks in advance.

 Noor


 

Re: [Mod-fcgid-users] Weird behavior or what?

2009-08-19 Thread Olivier B.
Travers Carter a écrit :
 On Thu, 20 Aug 2009 00:45:36 +0300, Noor
 mlist-fc...@orientalsensation.com
 wrote:
   
 And while you're at it, I'll through in another question: How does
 eAccelerator/FastCGI manage the shared memory segments? According to
 eAccelerator's homepage, it'll share such segments when the spawning
 process is shared. In the case of FastCGI (mod_fcgid), *who* is the
 spawning process? And this spawning process, how many cgi-php
 processes it'll spawn? (which if I understand correctly, such cgi-php
 processes would share eAccelerator's cached scripts as they've got one
 father).

 

 As I understand it in FastCGI mode a php process will launch a number
 of children equal to the value of the PHP_FCGI_CHILDREN environment
 variable, I believe that this is the spawning process referred to in
 the eAccelerator docs, meaning that the shared memory segment would
 be shared by those PHP_FCGI_CHILDREN processes.

 But mod_fcgid (unlike mod_fastcgi) assumes that each process it starts
 directly can only handle a single concurrent request so
 PHP_FCGI_CHILDREN should be set to 0, meaning that no children will be
 launched and the shared memory segment will only be used by a single
 php process.

   
PHP will shutdown the process after 500 request, so if you don't use 
PHP_FCGI_CHILDREN the
opcode cache (eaccelerator/xcache/apc) will be lost.
For this type of setup I generally set PHP_FCGI_CHILDREN to 1 and 
increase the
ProcessLifeTime fastcgi parameter to 86400 seconds instead of 3600.

Olivier

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users