Re: [Mod-fcgid-users] Fwd: mod_fcgid with php CGI hangs on interrupted downloads

2011-02-21 Thread Noor
Hi Liam,

Try adding this to the VirtualHost configuration for the intended website:

IPCCommTimeout 300

In addition, I'd recommend starting with a bare-bones Apache (without any
additional 3rd party module, like Suhosin and others) and then activating
only FastCGI with PHP. Best is when you compile PHP from sources.

I run Apache 2.2, FCGI, PHP5 on Debian and have no issues for years. The
only difference than your configuration is: I compile PHP5 from sources.
Actually I do that all the time in FreeBSD servers, but since Debian is a
development machine, I only build PHP5 from sources.

/Noor


On Tue, Feb 22, 2011 at 12:12 AM, Liam O'Boyle l...@elyobo.net wrote:

 Morning,

 I still haven't had any luck addressing this problem; I'm posting this
 in the hope that someone has some sort of idea, otherwise I will have
 to scrap mod_fcgid and revert to mod_php this evening, as this is
 causing considerable problems for our users.

 Thanks for any assistance,

 Liam



--
Index, Search  Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev___
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users


[Mod-fcgid-users] Yet more weird results...

2009-08-20 Thread Noor
Hello list,

On a previous post
(http://sourceforge.net/mailarchive/message.php?msg_name=d5fcc4ff0908191445x18dbadd8rdad145aa4e0c1c1f%40mail.gmail.com),
I've reported weird statistics after runnning siege on a heavy PHP
application.
Those tests were done on localhost and were blazing-fast even for a T3
user. So, I re-did the same tests but this time I installed siege on
another server (hosted in a different country altogether).

I've attached a CSV file with the test's results. The (MinProcess) and
(MaxProcess) are values for minimum and maximum processes that
mod-fcgid is allowed to spawn. I've yet to get a response on the
following:

According to the results, setting a top of 8 processes for the
FastCGI-launched php-cgi process would achieve a remarkable boost in
performance. Even better than setting 100 processes, and each equipped
with an eAccelerator opcode.

Anyone?

Noor


siege.csv
Description: Binary data
--
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


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

2009-08-19 Thread Noor
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
https