[Mod-fcgid-users] Weird behavior or what?
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 -- 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
Re: [Mod-fcgid-users] Weird behavior or what?
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?
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
