From simon at optinet.com Thu Apr 2 18:36:57 2009 From: simon at optinet.com (Simon) Date: Thu, 02 Apr 2009 18:36:57 -0400 Subject: [FASTCGI] PHP FastCGI mysql_pconnect Message-ID: <20090402223656.6F2A812829@smtp.chelsea.net> Hello, Does anyone know if PHP under FastCGI can keep persistent connection to MySQL via mysql_pconnect. I believe the last time I tried this, it wouldn't work. Thanks! Simon From simon at optinet.com Fri Apr 3 08:16:50 2009 From: simon at optinet.com (Simon) Date: Fri, 03 Apr 2009 08:16:50 -0400 Subject: [FASTCGI] PHP FastCGI mysql_pconnect In-Reply-To: Message-ID: <20090403121650.6DFB6E184@smtp.chelsea.net> Thanks! I will test it again. I'm not using it, I'm just the admin. Just wanted to double check because for some reason I remember testing it and it wouldn't work before. I always tell users not to use it not to tie up MySQL connections, but they still do and sometimes run into issues. On the other hand, can you tell me why you believe it's a bad idea to use pconnect to begin with? -Simon On Fri, 3 Apr 2009 14:10:49 +0200, Rasmus Andersson wrote: >On Fri, Apr 3, 2009 at 00:36, Simon wrote: >> Hello, >> >> Does anyone know if PHP under FastCGI can keep persistent connection to >> MySQL via mysql_pconnect. I believe the last time I tried this, it wouldn't work. >Yes it can and should. But keep in mind PHP leaks like a broken >umbrella so normally each PHP process is restarted every N requests, >thus dropping any connections. (N is normally 10000 or something). >Even though this really is out of topic for this list :) >Quick question and tip: Why are you using pconnect? It's almost always >a bad idea. Setting up a TCP connection on an internal network is >really cheap in comparison to connecting to other networks. If you are >connecting to an outside network, connection latency might become a >problem and then pconnect is there to ease the pain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasmus at flajm.com Fri Apr 3 08:10:49 2009 From: rasmus at flajm.com (Rasmus Andersson) Date: Fri, 3 Apr 2009 14:10:49 +0200 Subject: [FASTCGI] PHP FastCGI mysql_pconnect In-Reply-To: <20090402223656.6F2A812829@smtp.chelsea.net> References: <20090402223656.6F2A812829@smtp.chelsea.net> Message-ID: On Fri, Apr 3, 2009 at 00:36, Simon wrote: > Hello, > > Does anyone know if PHP under FastCGI can keep persistent connection to > MySQL via mysql_pconnect. I believe the last time I tried this, it wouldn't work. Yes it can and should. But keep in mind PHP leaks like a broken umbrella so normally each PHP process is restarted every N requests, thus dropping any connections. (N is normally 10000 or something). Even though this really is out of topic for this list :) Quick question and tip: Why are you using pconnect? It's almost always a bad idea. Setting up a TCP connection on an internal network is really cheap in comparison to connecting to other networks. If you are connecting to an outside network, connection latency might become a problem and then pconnect is there to ease the pain. From root at menkisys.net Mon Apr 6 03:56:18 2009 From: root at menkisys.net (root at menkisys.net) Date: Mon, 6 Apr 2009 09:56:18 +0200 Subject: [FASTCGI] fastcgi to slow: Message-ID: hello i am using debian lenny 64bit with mod_fastcgi 2.4.6. i have troubles with the fastcgi response time. many users say to me that he must wait about 3-4 seconds to view the site. the visitor of the site must wait about 3-4 seconds the see the website. i dont know waht is wrong but this is very slow. my server is quadcore intel server with 4 gb ram and he is very fast. i have tried fcgid and the spped is very very good. under fcgid i have many ram problems and i dont want use it. i ant to use fastcgi on my server. please help me to find the roght config. my network have about 1600 domains worldwide.... you can try to access these sites and you can see live the response time of fastcgi: http://www.menkisys.de and http://www.board2null.de ... my fastcgi config is this: FastCgiWrapper On FastCgiIpcDir /var/lib/apache2/fastcgi2 FastCgiConfig -minProcesses 0 \ -maxProcesses 350 \ -idle-timeout 80 \ -singleThreshold 100 \ -maxClassProcesses 3 \ -multiThreshold 15 \ -killInterval 20 \ -startDelay 3 # -autoUpdate \ # -pass-header HTTP_AUTHORIZATION thanks.... MENKI -------------- next part -------------- An HTML attachment was scrubbed... URL: From german.gutierrez at tide.cl Mon Apr 6 13:19:20 2009 From: german.gutierrez at tide.cl (German Gutierrez) Date: Mon, 6 Apr 2009 13:19:20 -0400 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? Message-ID: Hi, I want deploy a python app in apache with mod_fastcgi, but this module has not changes since november 2007. This means no bugs or not support? Germán Gutiérrez -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasmus at flajm.com Mon Apr 6 15:17:33 2009 From: rasmus at flajm.com (Rasmus Andersson) Date: Mon, 6 Apr 2009 21:17:33 +0200 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? In-Reply-To: References: Message-ID: On Mon, Apr 6, 2009 at 19:19, German Gutierrez wrote: > Hi, > > I want deploy a python app in apache with mod_fastcgi, but this module has > not changes since november 2007. This means no bugs or not support? There is no such thing as "no bugs" ;). But I'd call it "stable and tested". You should also be aware of the mod_fcgid http://fastcgi.coremail.cn/ > > Germán Gutiérrez > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > -- Rasmus Andersson From german.gutierrez at tide.cl Mon Apr 6 15:26:13 2009 From: german.gutierrez at tide.cl (German Gutierrez) Date: Mon, 6 Apr 2009 15:26:13 -0400 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? In-Reply-To: References: Message-ID: Thanks, i'm going to check mod_fcgid Germán Gutiérrez 2009/4/6 Rasmus Andersson > On Mon, Apr 6, 2009 at 19:19, German Gutierrez > wrote: > > Hi, > > > > I want deploy a python app in apache with mod_fastcgi, but this module > has > > not changes since november 2007. This means no bugs or not support? > > There is no such thing as "no bugs" ;). But I'd call it "stable and > tested". You should also be aware of the mod_fcgid > http://fastcgi.coremail.cn/ > > > > > Germán Gutiérrez > > > > _______________________________________________ > > FastCGI-developers mailing list > > FastCGI-developers at mailman.fastcgi.com > > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > > > > > > > -- > Rasmus Andersson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.php at gmail.com Mon Apr 6 15:37:30 2009 From: walter.php at gmail.com (Walter Cruz) Date: Mon, 6 Apr 2009 16:37:30 -0300 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? In-Reply-To: References: Message-ID: <32cabba0904061237m2b590e42hd80fe9e680f18c9@mail.gmail.com> Why not use mod_wsgi? On Mon, Apr 6, 2009 at 4:26 PM, German Gutierrez wrote: > Thanks, i'm going to check mod_fcgid > > Germán Gutiérrez > > 2009/4/6 Rasmus Andersson > >> On Mon, Apr 6, 2009 at 19:19, German Gutierrez >> wrote: >> > Hi, >> > >> > I want deploy a python app in apache with mod_fastcgi, but this module >> has >> > not changes since november 2007. This means no bugs or not support? >> >> There is no such thing as "no bugs" ;). But I'd call it "stable and >> tested". You should also be aware of the mod_fcgid >> http://fastcgi.coremail.cn/ >> >> > >> > Germán Gutiérrez >> > >> > _______________________________________________ >> > FastCGI-developers mailing list >> > FastCGI-developers at mailman.fastcgi.com >> > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers >> > >> > >> >> >> >> -- >> Rasmus Andersson >> > > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > -- []' - Walter waltercruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattmarcella at passur.com Mon Apr 6 15:40:41 2009 From: mattmarcella at passur.com (Matt Marcella) Date: Mon, 06 Apr 2009 15:40:41 -0400 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? In-Reply-To: References: Message-ID: <49DA5AB9.6000609@passur.com> fastcgi has been working well for me for 10 years. I have used in in critical apps for brokerage firms , and for aviation companies I think it works well for people so there has been little need for change. Matt German Gutierrez wrote: > Thanks, i'm going to check mod_fcgid > > Germán Gutiérrez > > 2009/4/6 Rasmus Andersson > > > On Mon, Apr 6, 2009 at 19:19, German Gutierrez > > wrote: > > Hi, > > > > I want deploy a python app in apache with mod_fastcgi, but this > module has > > not changes since november 2007. This means no bugs or not support? > > There is no such thing as "no bugs" ;). But I'd call it "stable and > tested". You should also be aware of the mod_fcgid > http://fastcgi.coremail.cn/ > > > > > Germán Gutiérrez > > > > _______________________________________________ > > FastCGI-developers mailing list > > FastCGI-developers at mailman.fastcgi.com > > > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > > > > > > > -- > Rasmus Andersson > > > ------------------------------------------------------------------------ > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kab16 at sfu.ca Thu Apr 9 18:34:19 2009 From: kab16 at sfu.ca (Kurt Bolko) Date: Thu, 9 Apr 2009 15:34:19 -0700 (PDT) Subject: [FASTCGI] zombie fastcgi threads Message-ID: <0c5301c9b963$52ee7570$f8cb6050$@ca> Hello, I'm currently have a problem with a large number of zombie fastcgi threads accumulating and causing all virtual hosts to become unavailable. The only way to resolve the problem is to either reboot the server or stop Apache and manually kill off the zombie processes. >From what I've read this is the exception and not the rule so I'd very much appreciate any ideas or suggestions on what I may be doing wrong. I'm hoping it's something obvious that I'm just not seeing. If you need any further information please let me know. Thanks, Kurt Bolko Systems Consultant W.A.C. Bennett Library The configuration is as follows, RHEL 4 Mod_FastCGI 2.4.0 PHP 5.1.6 - './configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/etc/httpd/conf/magic' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-ncurses=shared' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/bin/mysql_config' '--enable-dom=shared' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,/usr' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared' Apache 2.0.59 Httpd.conf - FastCgiIpcDir /tmp/fcgi_ipc FastCgiWrapper /usr/sbin/suexec FastCgiConfig -idle-timeout 3000 -startDelay 30 -maxClassProcesses 20 -m axProcesses 75 Virtualhost.conf - SuexecUserGroup user1 user1 ScriptAlias /php-fastcgi/ /var/www/user1/fcgi-bin/ Action application/x-httpd-fastphp /php-fastcgi/php-fcgi DocumentRoot /var/www/user1 Options ExecCGI SetHandler fastcgi-script FastCGI wrapper - #!/bin/sh PHP_FCGI_MAX_REQUESTS=1000 export PHP_FCGI_MAX_REQUESTS exec /usr/bin/php-cgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasmus at flajm.com Fri Apr 10 05:57:29 2009 From: rasmus at flajm.com (Rasmus Andersson) Date: Fri, 10 Apr 2009 11:57:29 +0200 Subject: [FASTCGI] Apache mod_fastcgi 2.4.6 is stable? In-Reply-To: <32cabba0904061237m2b590e42hd80fe9e680f18c9@mail.gmail.com> References: <32cabba0904061237m2b590e42hd80fe9e680f18c9@mail.gmail.com> Message-ID: On Mon, Apr 6, 2009 at 21:37, Walter Cruz wrote: > Why not use mod_wsgi? Don't swear in the church ;) (You're on the FastCGI-dev mailing list) From wilburlo at gmail.com Sun Apr 12 16:24:37 2009 From: wilburlo at gmail.com (Daniel Lo) Date: Sun, 12 Apr 2009 13:24:37 -0700 Subject: [FASTCGI] zombie fastcgi threads In-Reply-To: <0c5301c9b963$52ee7570$f8cb6050$@ca> References: <0c5301c9b963$52ee7570$f8cb6050$@ca> Message-ID: <05543025.20090412132437@gmail.com> Hello Kurt, You may want to check to make sure people or someone is not setting (http://us.php.net/set_time_limit) to zero and then doing something lengthy -daniel Thursday, April 9, 2009, 3:34:19 PM, you wrote: > Hello, > > I'm currently have a problem with a large number of zombie fastcgi threads > accumulating and causing all virtual hosts to become unavailable. The > only way to resolve the problem is to either reboot the server or stop > Apache and manually kill off the zombie processes. > >>From what I've read this is the exception and not the rule so I'd very > much appreciate any ideas or suggestions on what I may be doing wrong. > I'm hoping it's something obvious that I'm just not seeing. > > If you need any further information please let me know. > > Thanks, > > Kurt Bolko > Systems Consultant > W.A.C. Bennett Library > > The configuration is as follows, > RHEL 4 > Mod_FastCGI 2.4.0 > PHP 5.1.6 - './configure' '--build=i686-redhat-linux-gnu' > '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' > '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' > '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' > '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' > '--libexecdir=/usr/libexec' '--localstatedir=/var' > '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--cache-file=../config.cache' > '--with-libdir=lib' '--with-config-file-path=/etc' > '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' > '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' > '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' > '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' > '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' > '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' > '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' > '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' > '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' > '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' > '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' > '--enable-memory-limit' '--enable-shmop' '--enable-calendar' > '--enable-dbx' '--enable-dio' '--with-mime-magic=/etc/httpd/conf/magic' > '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' > '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' > '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbstr-enc-trans' > '--enable-mbregex' '--with-ncurses=shared' '--with-gd=shared' > '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' > '--with-xmlrpc=shared' '--with-ldap=shared' '--with-mysql=shared,/usr' > '--with-mysqli=shared,/usr/bin/mysql_config' '--enable-dom=shared' > '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' > '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' > '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' > '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' > '--with-pdo-mysql=shared,/usr' '--with-pdo-pgsql=shared,/usr' > '--with-pdo-sqlite=shared' > Apache 2.0.59 > > Httpd.conf - > > FastCgiIpcDir /tmp/fcgi_ipc > FastCgiWrapper /usr/sbin/suexec > FastCgiConfig -idle-timeout 3000 -startDelay 30 -maxClassProcesses > 20 -m > axProcesses 75 > > > Virtualhost.conf - > > SuexecUserGroup user1 user1 > ScriptAlias /php-fastcgi/ /var/www/user1/fcgi-bin/ > Action application/x-httpd-fastphp /php-fastcgi/php-fcgi > DocumentRoot /var/www/user1 > > Options ExecCGI > SetHandler fastcgi-script > > > > FastCGI wrapper - > #!/bin/sh > PHP_FCGI_MAX_REQUESTS=1000 > export PHP_FCGI_MAX_REQUESTS > exec /usr/bin/php-cgi -- Best regards, Daniel mailto:wilburlo at gmail.com From root at menkisys.net Wed Apr 15 08:30:47 2009 From: root at menkisys.net (root at menkisys.net) Date: Wed, 15 Apr 2009 14:30:47 +0200 Subject: [FASTCGI] fastcgi opening pages - very slow Message-ID: <99E3A42EF16F4070A8E552AF7D6144D0@menkiPC> hello i have debian lenny 64bit lenny server with intel quadcore cpu and 4gb ram (fastcgi 2.4.6). i have about 1.4 tb traffic month on this server. my problem is the speed of fastcgi applikation. when i want the visit one website on my server somethimes i must wait about 5 seconds the view the site. after them the speed is better. you can try the visit these sites and you will see somethimes you must wait some seconds the view the site: http://www.ally-tera.de or http://www.board2null.de . when i restart the webserver everything ist going very fast for 30 minutes. after them the speed ist very bad again. please help me to solve the problem. is my configuration bad? i have many visitors per day: about 5000.... FastCgiWrapper On FastCgiIpcDir /var/lib/apache2/fastcgi2 FastCgiConfig -minProcesses 60 \ -maxProcesses 900 \ -idle-timeout 80 \ -singleThreshold 100 \ -maxClassProcesses 10 \ -multiThreshold 100 \ -killInterval 20 \ -startDelay 5 # -autoUpdate \ # -pass-header HTTP_AUTHORIZATION Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From agalkin at audible.com Wed Apr 15 14:35:23 2009 From: agalkin at audible.com (Alexander Galkin (Audible US)) Date: Wed, 15 Apr 2009 14:35:23 -0400 Subject: [FASTCGI] HTTP status code and HEAD request Message-ID: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> I am using FastCGI C library on Solaris 10 / Apache 2.0. I have two questions: 1. How do I get what HTTP request (GET, POST and specifically HEAD) is being processed? 2. How do I return specific HTTP status code rather then 400? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsprenkle at gmail.com Wed Apr 15 14:54:43 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Wed, 15 Apr 2009 13:54:43 -0500 Subject: [FASTCGI] HTTP status code and HEAD request In-Reply-To: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> References: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> Message-ID: <1b5f39a10904151154k20a7bb2ao602071996d0ed40@mail.gmail.com> http://www.faqs.org/faqs/www/cgi-faq/ see this subject: Subject: 3.14 Can I run a CGI script without returning a new page to the browser? On Wed, Apr 15, 2009 at 1:35 PM, Alexander Galkin (Audible US) < agalkin at audible.com> wrote: > I am using FastCGI C library on Solaris 10 / Apache 2.0. I have two > questions: > > > > 2. How do I return specific HTTP status code rather then 400? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agalkin at audible.com Wed Apr 15 15:00:44 2009 From: agalkin at audible.com (Alexander Galkin (Audible US)) Date: Wed, 15 Apr 2009 15:00:44 -0400 Subject: [FASTCGI] HTTP status code and HEAD request In-Reply-To: <1b5f39a10904151154k20a7bb2ao602071996d0ed40@mail.gmail.com> References: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> <1b5f39a10904151154k20a7bb2ao602071996d0ed40@mail.gmail.com> Message-ID: <8AD089992055F0408126B89B3E407B670871B24C@EXVS02.HESungard.local> I looked at the page but I didn't find any info related to my questions. From: Jay Sprenkle [mailto:jsprenkle at gmail.com] Sent: Wednesday, April 15, 2009 2:55 PM To: Alexander Galkin (Audible US); FastCGI Developers List Subject: Re: [FASTCGI] HTTP status code and HEAD request http://www.faqs.org/faqs/www/cgi-faq/ see this subject: Subject: 3.14 Can I run a CGI script without returning a new page to the browser? On Wed, Apr 15, 2009 at 1:35 PM, Alexander Galkin (Audible US) wrote: I am using FastCGI C library on Solaris 10 / Apache 2.0. I have two questions: 2. How do I return specific HTTP status code rather then 400? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsprenkle at gmail.com Wed Apr 15 15:05:02 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Wed, 15 Apr 2009 14:05:02 -0500 Subject: [FASTCGI] HTTP status code and HEAD request In-Reply-To: <8AD089992055F0408126B89B3E407B670871B24C@EXVS02.HESungard.local> References: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> <1b5f39a10904151154k20a7bb2ao602071996d0ed40@mail.gmail.com> <8AD089992055F0408126B89B3E407B670871B24C@EXVS02.HESungard.local> Message-ID: <1b5f39a10904151205g6578365cr23bee8c740689058@mail.gmail.com> On Wed, Apr 15, 2009 at 2:00 PM, Alexander Galkin (Audible US) < agalkin at audible.com> wrote: > I looked at the page but I didn?t find any info related to my questions. > > that sections explains how to return a status code. Here's the code: The correct solution according to the HTTP specification is to return HTTP status code 204. As an NPH script, this would be: #!/bin/sh # do processing (or launch it as background job) echo "HTTP/1.0 204 No Change" echo (as non-NPH, you'd simply replace HTTP/1.0 with the Status: CGI header). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattmarcella at passur.com Wed Apr 15 15:04:25 2009 From: mattmarcella at passur.com (Matt Marcella) Date: Wed, 15 Apr 2009 15:04:25 -0400 Subject: [FASTCGI] HTTP status code and HEAD request In-Reply-To: <8AD089992055F0408126B89B3E407B670871B24C@EXVS02.HESungard.local> References: <8AD089992055F0408126B89B3E407B670871B207@EXVS02.HESungard.local> <1b5f39a10904151154k20a7bb2ao602071996d0ed40@mail.gmail.com> <8AD089992055F0408126B89B3E407B670871B24C@EXVS02.HESungard.local> Message-ID: <49E62FB9.5050905@passur.com> Are you talking about a "RESTful"-like update, where you just change a value of a text field, for instance, instead of the whole page? Alexander Galkin (Audible US) wrote: > > I looked at the page but I didn't find any info related to my questions. > > > > *From:* Jay Sprenkle [mailto:jsprenkle at gmail.com] > *Sent:* Wednesday, April 15, 2009 2:55 PM > *To:* Alexander Galkin (Audible US); FastCGI Developers List > *Subject:* Re: [FASTCGI] HTTP status code and HEAD request > > > > > http://www.faqs.org/faqs/www/cgi-faq/ > > see this subject: > > Subject: 3.14 Can I run a CGI script without returning a new page to the browser? > > > > On Wed, Apr 15, 2009 at 1:35 PM, Alexander Galkin (Audible US) > > wrote: > > I am using FastCGI C library on Solaris 10 / Apache 2.0. I have two > questions: > > > > 2. How do I return specific HTTP status code rather then 400? > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanecalimlim at gmail.com Thu Apr 16 16:59:56 2009 From: shanecalimlim at gmail.com (Shane Calimlim) Date: Thu, 16 Apr 2009 13:59:56 -0700 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question Message-ID: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> Hi, first let me say that I'm new to the list, but I've been using (and loving) FastCGI for years -- great work everyone involved. I'm working on a FastCGI external server (using a port) with multiple threads. The problem I'm having is that even with multiple threads, only one request is being handled at a time. Multiple threads are handling them, but FCGX_Accept_r() is locking until the previous request's FCGX_Finish_r() is called. I am also using the Qt framework; in the code snippets below qDebug() is just a debugging printf(). Here is the code I'm using: In main(): if( FCGX_Init() != 0 ) { qDebug( "FCGX_Init() error." ); ::exit( 1 ); } g_listenSocket = FCGX_OpenSocket( ":9000", 100 ); if( g_listenSocket < 0 ) { qDebug( "FCGX_OpenSocket() error." ); ::exit( 1 ); } //spawn threads and wait until they all terminate In each thread: FCGX_Request request; if( FCGX_InitRequest( &request, g_listenSocket, 0 ) != 0 ) { qDebug( "FCGX_InitRequest() error." ); ::exit( 1 ); } int status; for(;;) { status = FCGX_Accept_r( &request ); if( status != 0 ) { qDebug( "FCGX_Accept_r() error." ); ::exit( 1 ); } FCGX_FPrintF( request.out, "Content-Type: text/plain\r\n\r\n" ); FCGX_FPrintF( request.out, "Hello World!\n" ); for( int i = 1; i <= 10; ++i ) { msleep( 1000 ); // this is a Qt function -- a 1 second sleep FCGX_FPrintF( request.out, "%d\n", i ); FCGX_FFlush( request.out ); } FCGX_Finish_r( &request ); } I've tried various combinations with Init/OpenSocket being in each thread, but have had no luck with those. I've also tried WSADuplicateSocket on g_listenSocket, but Windows complains that it is not a socket. Is this possible at all? Is it possible on Windows? The target platform is Linux, but I develop on Windows, so having it work identically on my dev machines would be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanecalimlim at gmail.com Thu Apr 16 17:00:32 2009 From: shanecalimlim at gmail.com (Shane Calimlim) Date: Thu, 16 Apr 2009 14:00:32 -0700 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question Message-ID: <16cc50f20904161400v2d90fb25ia7f482cc39ee464c@mail.gmail.com> Hi, first let me say that I'm new to the list, but I've been using (and loving) FastCGI for years -- great work everyone involved. I'm working on a FastCGI external server (using a port) with multiple threads. The problem I'm having is that even with multiple threads, only one request is being handled at a time. Multiple threads are handling them, but FCGX_Accept_r() is locking until the previous request's FCGX_Finish_r() is called. I am also using the Qt framework; in the code snippets below qDebug() is just a debugging printf(). Here is the code I'm using: In main(): if( FCGX_Init() != 0 ) { qDebug( "FCGX_Init() error." ); ::exit( 1 ); } g_listenSocket = FCGX_OpenSocket( ":9000", 100 ); if( g_listenSocket < 0 ) { qDebug( "FCGX_OpenSocket() error." ); ::exit( 1 ); } //spawn threads and wait until they all terminate In each thread: FCGX_Request request; if( FCGX_InitRequest( &request, g_listenSocket, 0 ) != 0 ) { qDebug( "FCGX_InitRequest() error." ); ::exit( 1 ); } int status; for(;;) { status = FCGX_Accept_r( &request ); if( status != 0 ) { qDebug( "FCGX_Accept_r() error." ); ::exit( 1 ); } FCGX_FPrintF( request.out, "Content-Type: text/plain\r\n\r\n" ); FCGX_FPrintF( request.out, "Hello World!\n" ); for( int i = 1; i <= 10; ++i ) { msleep( 1000 ); // this is a Qt function -- a 1 second sleep FCGX_FPrintF( request.out, "%d\n", i ); FCGX_FFlush( request.out ); } FCGX_Finish_r( &request ); } I've tried various combinations with Init/OpenSocket being in each thread, but have had no luck with those. I've also tried WSADuplicateSocket on g_listenSocket, but Windows complains that it is not a socket. Is this possible at all? Is it possible on Windows? The target platform is Linux, but I develop on Windows, so having it work identically on my dev machines would be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsprenkle at gmail.com Thu Apr 16 17:30:15 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Thu, 16 Apr 2009 16:30:15 -0500 Subject: [FASTCGI] Fwd: Hello and a Threading/External Server/Win32 question In-Reply-To: <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> References: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> Message-ID: <1b5f39a10904161430xa329a2dma1cecad208f5279e@mail.gmail.com> ---------- Forwarded message ---------- From: Jay Sprenkle Date: Thu, Apr 16, 2009 at 4:28 PM Subject: Re: [FASTCGI] Hello and a Threading/External Server/Win32 question To: Shane Calimlim I looked at this too and found the answer in cygwin. They duplicate a lot of the functionality of unix and have already been down this path. Here's the clue I found: http://www.mail-archive.com/cygwin at cygwin.com/msg62458.html I may be wrong but the short answer seems to be you can't pass open file handles that are tcp connections between processes because windows doesn't treat everything (tcp connections) as a file. I've not seen any way to get fastcgi to work on windows as the official specs specify (since you must pass more than a file handle between processes). If you get it to work I'd love to see how. If you use a named pipe on the other hand things get easier, and named pipes are supposed to be faster than tcp connections too. On Thu, Apr 16, 2009 at 3:59 PM, Shane Calimlim wrote: > Hi, first let me say that I'm new to the list, but I've been using (and > loving) FastCGI for years -- great work everyone involved. > > I'm working on a FastCGI external server (using a port) with multiple > threads. The problem I'm having is that even with multiple threads, only > one request is being handled at a time. Multiple threads are handling them, > but FCGX_Accept_r() is locking until the previous request's FCGX_Finish_r() > is called. > > I am also using the Qt framework; in the code snippets below qDebug() is > just a debugging printf(). > > Here is the code I'm using: > > In main(): > > if( FCGX_Init() != 0 ) > { > qDebug( "FCGX_Init() error." ); > ::exit( 1 ); > } > g_listenSocket = FCGX_OpenSocket( ":9000", 100 ); > if( g_listenSocket < 0 ) > { > qDebug( "FCGX_OpenSocket() error." ); > ::exit( 1 ); > } > > //spawn threads and wait until they all terminate > > In each thread: > > FCGX_Request request; > if( FCGX_InitRequest( &request, g_listenSocket, 0 ) != 0 ) > { > qDebug( "FCGX_InitRequest() error." ); > ::exit( 1 ); > } > > int status; > for(;;) > { > status = FCGX_Accept_r( &request ); > if( status != 0 ) > { > qDebug( "FCGX_Accept_r() error." ); > ::exit( 1 ); > } > > FCGX_FPrintF( request.out, "Content-Type: text/plain\r\n\r\n" ); > FCGX_FPrintF( request.out, "Hello World!\n" ); > for( int i = 1; i <= 10; ++i ) > { > msleep( 1000 ); // this is a Qt function -- a 1 second sleep > FCGX_FPrintF( request.out, "%d\n", i ); > FCGX_FFlush( request.out ); > } > FCGX_Finish_r( &request ); > } > > I've tried various combinations with Init/OpenSocket being in each thread, > but have had no luck with those. I've also tried WSADuplicateSocket on > g_listenSocket, but Windows complains that it is not a socket. > > Is this possible at all? Is it possible on Windows? The target platform > is Linux, but I develop on Windows, so having it work identically on my dev > machines would be very useful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsprenkle at gmail.com Thu Apr 16 18:23:34 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Thu, 16 Apr 2009 17:23:34 -0500 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question In-Reply-To: <16cc50f20904161436g22170420n3f806fcda7f66d7d@mail.gmail.com> References: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> <16cc50f20904161436g22170420n3f806fcda7f66d7d@mail.gmail.com> Message-ID: <1b5f39a10904161523q7b022116ge17721cc41c6eedd@mail.gmail.com> I looked into lighttpd's source. The author detests windows and refuses to port to it. On Thu, Apr 16, 2009 at 4:36 PM, Shane Calimlim wrote: > I was considering looking into some web server source, I know Apache > maintains a thread pool for responding to a single port, and I'm pretty sure > lighttpd does too (lighttpd's source is a lot smaller, so it would probably > be easier to locate what they are doing). > > If I find an answer I will definitely let you know; please let me know if > you do too! > > > On Thu, Apr 16, 2009 at 2:28 PM, Jay Sprenkle wrote: > >> I looked at this too and found the answer in cygwin. They duplicate a lot >> of the functionality of unix and have already been down this path. Here's >> the clue I found: >> http://www.mail-archive.com/cygwin at cygwin.com/msg62458.html >> >> I may be wrong but the short answer seems to be you can't pass open file >> handles that are tcp connections between processes because windows doesn't >> treat everything (tcp connections) as a file. I've not seen any way to get >> fastcgi to work on windows as the official specs specify (since you must >> pass more than a file handle between processes). >> >> If you get it to work I'd love to see how. >> >> If you use a named pipe on the other hand things get easier, and named >> pipes are supposed to be faster than tcp connections too. >> >> >> >> >> On Thu, Apr 16, 2009 at 3:59 PM, Shane Calimlim > > wrote: >> >>> Hi, first let me say that I'm new to the list, but I've been using (and >>> loving) FastCGI for years -- great work everyone involved. >>> >>> I'm working on a FastCGI external server (using a port) with multiple >>> threads. The problem I'm having is that even with multiple threads, only >>> one request is being handled at a time. Multiple threads are handling them, >>> but FCGX_Accept_r() is locking until the previous request's FCGX_Finish_r() >>> is called. >>> >>> I am also using the Qt framework; in the code snippets below qDebug() is >>> just a debugging printf(). >>> >>> Here is the code I'm using: >>> >>> In main(): >>> >>> if( FCGX_Init() != 0 ) >>> { >>> qDebug( "FCGX_Init() error." ); >>> ::exit( 1 ); >>> } >>> g_listenSocket = FCGX_OpenSocket( ":9000", 100 ); >>> if( g_listenSocket < 0 ) >>> { >>> qDebug( "FCGX_OpenSocket() error." ); >>> ::exit( 1 ); >>> } >>> >>> //spawn threads and wait until they all terminate >>> >>> In each thread: >>> >>> FCGX_Request request; >>> if( FCGX_InitRequest( &request, g_listenSocket, 0 ) != 0 ) >>> { >>> qDebug( "FCGX_InitRequest() error." ); >>> ::exit( 1 ); >>> } >>> >>> int status; >>> for(;;) >>> { >>> status = FCGX_Accept_r( &request ); >>> if( status != 0 ) >>> { >>> qDebug( "FCGX_Accept_r() error." ); >>> ::exit( 1 ); >>> } >>> >>> FCGX_FPrintF( request.out, "Content-Type: text/plain\r\n\r\n" ); >>> FCGX_FPrintF( request.out, "Hello World!\n" ); >>> for( int i = 1; i <= 10; ++i ) >>> { >>> msleep( 1000 ); // this is a Qt function -- a 1 second sleep >>> FCGX_FPrintF( request.out, "%d\n", i ); >>> FCGX_FFlush( request.out ); >>> } >>> FCGX_Finish_r( &request ); >>> } >>> >>> I've tried various combinations with Init/OpenSocket being in each >>> thread, but have had no luck with those. I've also tried WSADuplicateSocket >>> on g_listenSocket, but Windows complains that it is not a socket. >>> >>> Is this possible at all? Is it possible on Windows? The target platform >>> is Linux, but I develop on Windows, so having it work identically on my dev >>> machines would be very useful. >>> >>> >>> _______________________________________________ >>> FastCGI-developers mailing list >>> FastCGI-developers at mailman.fastcgi.com >>> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers >>> >>> >> >> >> -- >> -- >> The PixAddixImage Collector suite: >> http://groups-beta.google.com/group/pixaddix >> >> SqliteImporter and SqliteReplicator: Command line utilities for Sqlite >> http://www.reddawn.net/~jsprenkl/Sqlite >> >> Cthulhu Bucks! >> http://www.cthulhubucks.com >> > > -- -- The PixAddixImage Collector suite: http://groups-beta.google.com/group/pixaddix SqliteImporter and SqliteReplicator: Command line utilities for Sqlite http://www.reddawn.net/~jsprenkl/Sqlite Cthulhu Bucks! http://www.cthulhubucks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From unique at idempot.net Thu Apr 16 18:52:31 2009 From: unique at idempot.net (Matthew Weigel) Date: Thu, 16 Apr 2009 22:52:31 +0000 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question In-Reply-To: <1b5f39a10904161523q7b022116ge17721cc41c6eedd@mail.gmail.com> References: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> <16cc50f20904161436g22170420n3f806fcda7f66d7d@mail.gmail.com> <1b5f39a10904161523q7b022116ge17721cc41c6eedd@mail.gmail.com> Message-ID: <37c92f9410788e162f7a240782d78d7e@patience.idempot.net> On Thu, 16 Apr 2009 17:23:34 -0500, Jay Sprenkle wrote: > I looked into lighttpd's source. The author detests windows and refuses to > port to it. Lighttpd does not use multiple threads; it's got an event-driven architecture that would probably require a substantial rewrite to port to Windows. Instead, the original poster might want to look at what php-fastcgi does to distribute FastCGI requests between multiple child processes. It runs on Windows, and might correspond to what would be needed to distribute requests between multiple threads. -- Matthew Weigel hacker unique & idempot . ent From jsprenkle at gmail.com Thu Apr 16 22:17:27 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Thu, 16 Apr 2009 21:17:27 -0500 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question In-Reply-To: <37c92f9410788e162f7a240782d78d7e@patience.idempot.net> References: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> <16cc50f20904161436g22170420n3f806fcda7f66d7d@mail.gmail.com> <1b5f39a10904161523q7b022116ge17721cc41c6eedd@mail.gmail.com> <37c92f9410788e162f7a240782d78d7e@patience.idempot.net> Message-ID: <1b5f39a10904161917r670ad6fci9bbb43f96a11b7da@mail.gmail.com> On Thu, Apr 16, 2009 at 5:52 PM, Matthew Weigel wrote: > On Thu, 16 Apr 2009 17:23:34 -0500, Jay Sprenkle > wrote: > > I looked into lighttpd's source. The author detests windows and refuses > to > > port to it. > > Lighttpd does not use multiple threads; it's got an event-driven > architecture that would probably require a substantial rewrite to port > to Windows. Instead, the original poster might want to look at what > php-fastcgi does to distribute FastCGI requests between multiple > child processes. It runs on Windows, and might correspond to what > would be needed to distribute requests between multiple threads. > -- I don't believe php runs on windows that way either... but then I have been wrong lots of times. If he can get it to work that would be great. The last I read about they had a program that cached the php interpreter to get decent speed out of regular cgi. It's not fastcgi but it's similar http://en.wikipedia.org/wiki/PHP_accelerator -------------- next part -------------- An HTML attachment was scrubbed... URL: From unique at idempot.net Thu Apr 16 22:56:05 2009 From: unique at idempot.net (Matthew Weigel) Date: Thu, 16 Apr 2009 21:56:05 -0500 Subject: [FASTCGI] Hello and a Threading/External Server/Win32 question In-Reply-To: <1b5f39a10904161917r670ad6fci9bbb43f96a11b7da@mail.gmail.com> References: <16cc50f20904161359l1b22f59p153b83884e291044@mail.gmail.com> <1b5f39a10904161428s40669860w876b90c69931400e@mail.gmail.com> <16cc50f20904161436g22170420n3f806fcda7f66d7d@mail.gmail.com> <1b5f39a10904161523q7b022116ge17721cc41c6eedd@mail.gmail.com> <37c92f9410788e162f7a240782d78d7e@patience.idempot.net> <1b5f39a10904161917r670ad6fci9bbb43f96a11b7da@mail.gmail.com> Message-ID: <49E7EFC5.4090906@idempot.net> Jay Sprenkle wrote: > I don't believe php runs on windows that way either... but then I have > been wrong lots of times. http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/ :-) -- Matthew Weigel hacker unique & idempot . ent From Olivier.LeCam at crdp.ac-versailles.fr Tue Apr 21 02:54:57 2009 From: Olivier.LeCam at crdp.ac-versailles.fr (Olivier Le Cam) Date: Tue, 21 Apr 2009 08:54:57 +0200 Subject: [FASTCGI] fastcgi opening pages - very slow In-Reply-To: <99E3A42EF16F4070A8E552AF7D6144D0@menkiPC> References: <99E3A42EF16F4070A8E552AF7D6144D0@menkiPC> Message-ID: <49ED6DC1.6010906@crdp.ac-versailles.fr> root at menkisys.net wrote: > hello > > i have debian lenny 64bit lenny server with intel quadcore cpu and 4gb > ram (fastcgi 2.4.6). i have about 1.4 tb traffic month on this server. > my problem is the speed of fastcgi applikation. when i want the visit > one website on my server somethimes i must wait about 5 seconds the view > the site. after them the speed is better. you can try the visit these > sites and you will see somethimes you must wait some seconds the view > the site: > http://www.ally-tera.de or http://www.board2null.de . when i restart the > webserver everything ist going very fast for 30 minutes. after them the > speed ist very bad again. please help me to solve the problem. is my > configuration bad? i have many visitors per day: about 5000.... Hi - I reported something similar before (see below) but I never get rid of the problem. A far as I understood, fastcgi always tries to connect to a php-cgi process even if that said-process is no longer loaded (aka was killed by fastcgi). In this situation, fastcgi keep tries to join a non-existing process until timeout is reached. After that only it does respawn a new process which takes several seconds indeed due to the timeout. I think that when a previously-spawned process is killed for some reasons, fastcgi should not leave any trace of it in order to respawn a new one as soon as possible when required. I started to deal with that problem but I never find enough time to spend entering my brain in the source code! I'm not sure that I helped you so much, except that now you know you are not alone to face this problem! :) Best regards, Olivier Le Cam -- Copy of email sent on Nov 11, 2008 -- Setup based on Apache (2.2.3-4+etch5) + libapache2-mod-fastcgi (2.4.2-8) + php5-cgi (5.2.6-0.dotdeb.1) Everything is working fine with this setup except for an abnormal long delay for spawning a new php5-cgi through suexec for the second time (after the first one has been killed). Way to repeat the problem: 1. Apache just (re)started 2. Access to a virtualhost, say http://test.mydomain.com This takes approx. 0.5s which is fine 2. Access to this site again This takes approx. 0.04s which is still fine 3. Wait that the spawned process php5-cgi for this virtualhost is killed by fcgi-pm. Then access to the site again. Now it takes more than 3s to get the php5-cgi spawned. After that, time access is back to normal (~0.04s) untill the process is killed (then the 3s delay come back for the next spawn). I have this in my Apache conf: FastCgiWrapper /usr/local/lib/apache2/suexec-fcgi FastCgiConfig -minProcesses 0 -maxClassProcesses 1 -maxProcesses 300 \ -processSlack 30 -singleThreshold 20 -killInterval 240 AddHandler php5-fastcgi .php .php3 .php4 .php5 SetHandler fastcgi-script Options +ExecCGI Action php5-fastcgi /cgi-bin/php5-fcgi AddType application/x-httpd-php .php5 And this is the cgi-bin/php5-fcgi wrapper: #!/bin/sh export PHPRC="/web/s/t/test/php-configs/php5/" export PHP_FCGI_CHILDREN=0 export PHP_FCGI_MAX_REQUESTS=1000 exec /usr/bin/php5-cgi I spends some time attaching strace to fcgi-pm and Apache process, but I sadly didn't get a chance to figure out what could be the problem. Does this sound to someone? Any help/hint/idea will be greatly appreciated. Thanks in anticipation! From jsprenkle at gmail.com Tue Apr 21 08:33:52 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Tue, 21 Apr 2009 07:33:52 -0500 Subject: [FASTCGI] fastcgi opening pages - very slow In-Reply-To: <49ED6DC1.6010906@crdp.ac-versailles.fr> References: <99E3A42EF16F4070A8E552AF7D6144D0@menkiPC> <49ED6DC1.6010906@crdp.ac-versailles.fr> Message-ID: <1b5f39a10904210533o5008f3dbncf4fe3f7c3ffcb12@mail.gmail.com> This problem is either the php interpreter or Apache, or how they work together. You really should be on the Apache or php forums if you want answers. On Tue, Apr 21, 2009 at 1:54 AM, Olivier Le Cam < Olivier.LeCam at crdp.ac-versailles.fr> wrote: > root at menkisys.net wrote: > >> hello >> i have debian lenny 64bit lenny server with intel quadcore cpu and 4gb >> ram (fastcgi 2.4.6). i have about 1.4 tb traffic month on this server. my >> problem is the speed of fastcgi applikation. when i want the visit one >> website on my server somethimes i must wait about 5 seconds the view the >> site. after them the speed is better. you can try the visit these sites and >> you will see somethimes you must wait some seconds the view the site: >> http://www.ally-tera.de or http://www.board2null.de . when i restart the >> webserver everything ist going very fast for 30 minutes. after them the >> speed ist very bad again. please help me to solve the problem. is my >> configuration bad? i have many visitors per day: about 5000.... >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onefriedrice at brokenzipper.com Wed Apr 22 00:11:04 2009 From: onefriedrice at brokenzipper.com (Charles McGarvey) Date: Tue, 21 Apr 2009 22:11:04 -0600 Subject: [FASTCGI] memory leak in libfcgi Message-ID: <49EE98D8.5050003@brokenzipper.com> I'm seeing some sort of memory leak which eventually leads to a segfault in libfcgi. It only occurs under high concurrency (easily observable with 500-1000 concurrency). I'll debug this tomorrow, but I'm wondering if anyone else has come across this or could perhaps verify this bad behavior. Thanks, Chaz From rasmus at flajm.com Wed Apr 22 04:04:35 2009 From: rasmus at flajm.com (Rasmus Andersson) Date: Wed, 22 Apr 2009 10:04:35 +0200 Subject: [FASTCGI] memory leak in libfcgi In-Reply-To: <49EE98D8.5050003@brokenzipper.com> References: <49EE98D8.5050003@brokenzipper.com> Message-ID: Enable core dumping and attach a core dump next time it happens and it will be much easier to tell if there's a bug in FastCGI or your application. I have no problem with 4 000 concurrent connections to an app which is stateful (i.e. does not shut itself down every N requests like PHP). No leaks. We're running Debian Lenny. On Wed, Apr 22, 2009 at 06:11, Charles McGarvey wrote: > I'm seeing some sort of memory leak which eventually leads to a segfault > in libfcgi.  It only occurs under high concurrency (easily observable > with 500-1000 concurrency).  I'll debug this tomorrow, but I'm wondering > if anyone else has come across this or could perhaps verify this bad > behavior. > > Thanks, > Chaz > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > -- Rasmus Andersson From mgrant at grant.org Wed Apr 22 05:05:42 2009 From: mgrant at grant.org (Michael Grant) Date: Wed, 22 Apr 2009 11:05:42 +0200 Subject: [FASTCGI] sub-processes Message-ID: <62b856460904220205q78dfda71o5f4a8ab9e5e1b795@mail.gmail.com> I'm using mod-fastcgi in apache2. In httpd.conf, I have this: MinSpareServers 1 MaxSpareServers 20 StartServers 1 and in a php.fcgi script like this: #!/bin/sh PHP_FCGI_CHILDREN=10 export PHP_FCGI_CHILDREN exec /usr/local/bin/php-cgi What I see is 20 httpd instances, each with a process, and that process has up to 10 children, pstree outputs something like this: -+= 00000 root [swapper] \-+= 00001 root /sbin/init -- \-+= 05763 root /usr/local/sbin/httpd -k start |--- 05764 www /usr/local/sbin/httpd -k start |-+- 05765 www /usr/local/sbin/httpd -k start | |-+= 05767 user /usr/local/bin/php-cgi | | |--- 05768 user /usr/local/bin/php-cgi | | |--- 05769 user /usr/local/bin/php-cgi | | |--- 05770 user /usr/local/bin/php-cgi | | |--- 05771 user /usr/local/bin/php-cgi | | |--- 05772 user /usr/local/bin/php-cgi | | |--- 05773 user /usr/local/bin/php-cgi | | |--- 05774 user /usr/local/bin/php-cgi | | |--- 05775 user /usr/local/bin/php-cgi | | |--- 05776 user /usr/local/bin/php-cgi | | \--- 05777 user /usr/local/bin/php-cgi | |-+= 05941 user /usr/local/bin/php-cgi | | |--- 05942 user /usr/local/bin/php-cgi | | |--- 05943 user /usr/local/bin/php-cgi | | |--- 05944 user /usr/local/bin/php-cgi | | |--- 05945 user /usr/local/bin/php-cgi | | |--- 05946 user /usr/local/bin/php-cgi | | |--- 05947 user /usr/local/bin/php-cgi | | |--- 05948 user /usr/local/bin/php-cgi | | |--- 05949 user /usr/local/bin/php-cgi | | |--- 05950 user /usr/local/bin/php-cgi | | \--- 05951 user /usr/local/bin/php-cgi | |-+= 05956 user /usr/local/bin/php-cgi | | |--- 05957 user /usr/local/bin/php-cgi | | |--- 05958 user /usr/local/bin/php-cgi | | |--- 05959 user /usr/local/bin/php-cgi | | |--- 05960 user /usr/local/bin/php-cgi | | |--- 05961 user /usr/local/bin/php-cgi | | |--- 05962 user /usr/local/bin/php-cgi | | |--- 05963 user /usr/local/bin/php-cgi | | |--- 05964 user /usr/local/bin/php-cgi | | |--- 05965 user /usr/local/bin/php-cgi | | \--- 05966 user /usr/local/bin/php-cgi | |-+= 05972 user /usr/local/bin/php-cgi | | |--- 05973 user /usr/local/bin/php-cgi | | |--- 05974 user /usr/local/bin/php-cgi | | |--- 05975 user /usr/local/bin/php-cgi | | |--- 05976 user /usr/local/bin/php-cgi | | |--- 05977 user /usr/local/bin/php-cgi | | |--- 05978 user /usr/local/bin/php-cgi | | |--- 05979 user /usr/local/bin/php-cgi | | |--- 05980 user /usr/local/bin/php-cgi | | |--- 05981 user /usr/local/bin/php-cgi | | \--- 05982 user /usr/local/bin/php-cgi | |-+= 05984 user /usr/local/bin/php-cgi | | |--- 05985 user /usr/local/bin/php-cgi | | |--- 05986 user /usr/local/bin/php-cgi | | |--- 05987 user /usr/local/bin/php-cgi | | |--- 05988 user /usr/local/bin/php-cgi | | |--- 05989 user /usr/local/bin/php-cgi | | |--- 05990 user /usr/local/bin/php-cgi | | |--- 05991 user /usr/local/bin/php-cgi | | |--- 05992 user /usr/local/bin/php-cgi | | |--- 05993 user /usr/local/bin/php-cgi | | \--- 05994 user /usr/local/bin/php-cgi | |-+= 05996 user /usr/local/bin/php-cgi | | |--- 05997 user /usr/local/bin/php-cgi | | |--- 05998 user /usr/local/bin/php-cgi | | |--- 05999 user /usr/local/bin/php-cgi | | |--- 06000 user /usr/local/bin/php-cgi | | |--- 06001 user /usr/local/bin/php-cgi | | |--- 06002 user /usr/local/bin/php-cgi | | |--- 06003 user /usr/local/bin/php-cgi | | |--- 06004 user /usr/local/bin/php-cgi | | |--- 06005 user /usr/local/bin/php-cgi | | \--- 06006 user /usr/local/bin/php-cgi | |-+= 06009 user /usr/local/bin/php-cgi | | |--- 06010 user /usr/local/bin/php-cgi | | |--- 06011 user /usr/local/bin/php-cgi | | |--- 06012 user /usr/local/bin/php-cgi | | |--- 06013 user /usr/local/bin/php-cgi | | |--- 06014 user /usr/local/bin/php-cgi | | |--- 06015 user /usr/local/bin/php-cgi | | |--- 06016 user /usr/local/bin/php-cgi | | |--- 06017 user /usr/local/bin/php-cgi | | |--- 06018 user /usr/local/bin/php-cgi | | \--- 06019 user /usr/local/bin/php-cgi | |-+= 06025 user /usr/local/bin/php-cgi | | |--- 06026 user /usr/local/bin/php-cgi | | |--- 06027 user /usr/local/bin/php-cgi | | |--- 06028 user /usr/local/bin/php-cgi | | |--- 06029 user /usr/local/bin/php-cgi | | |--- 06030 user /usr/local/bin/php-cgi | | |--- 06031 user /usr/local/bin/php-cgi | | |--- 06032 user /usr/local/bin/php-cgi | | |--- 06033 user /usr/local/bin/php-cgi | | |--- 06034 user /usr/local/bin/php-cgi | | \--- 06035 user /usr/local/bin/php-cgi | |-+= 06208 user /usr/local/bin/php-cgi | | |--- 06210 user /usr/local/bin/php-cgi | | |--- 06211 user /usr/local/bin/php-cgi | | |--- 06212 user /usr/local/bin/php-cgi | | |--- 06213 user /usr/local/bin/php-cgi | | |--- 06214 user /usr/local/bin/php-cgi | | |--- 06215 user /usr/local/bin/php-cgi | | |--- 06216 user /usr/local/bin/php-cgi | | |--- 06217 user /usr/local/bin/php-cgi | | |--- 06218 user /usr/local/bin/php-cgi | | \--- 06219 user /usr/local/bin/php-cgi | \-+= 07960 user /usr/local/bin/php-cgi | |--- 07961 user /usr/local/bin/php-cgi | |--- 07962 user /usr/local/bin/php-cgi | |--- 07963 user /usr/local/bin/php-cgi | |--- 07964 user /usr/local/bin/php-cgi | |--- 07965 user /usr/local/bin/php-cgi | |--- 07966 user /usr/local/bin/php-cgi | |--- 07967 user /usr/local/bin/php-cgi | |--- 07968 user /usr/local/bin/php-cgi | |--- 07969 user /usr/local/bin/php-cgi | \--- 07970 user /usr/local/bin/php-cgi |--- 05766 www /usr/local/sbin/httpd -k start |--- 05778 www /usr/local/sbin/httpd -k start |--- 05779 www /usr/local/sbin/httpd -k start |--- 05780 www /usr/local/sbin/httpd -k start |--- 05883 www /usr/local/sbin/httpd -k start |--- 05952 www /usr/local/sbin/httpd -k start |--- 05953 www /usr/local/sbin/httpd -k start |--- 05954 www /usr/local/sbin/httpd -k start |--- 05967 www /usr/local/sbin/httpd -k start |--- 05968 www /usr/local/sbin/httpd -k start |--- 05969 www /usr/local/sbin/httpd -k start |--- 05970 www /usr/local/sbin/httpd -k start |--- 06037 www /usr/local/sbin/httpd -k start |--- 06531 www /usr/local/sbin/httpd -k start |--- 06532 www /usr/local/sbin/httpd -k start |--- 06533 www /usr/local/sbin/httpd -k start |--- 06548 www /usr/local/sbin/httpd -k start |--- 06555 www /usr/local/sbin/httpd -k start |--- 06557 www /usr/local/sbin/httpd -k start \--- 06558 www /usr/local/sbin/httpd -k start This seems excessive and it's unclear to me whether all these apache processes are being used or needed. I have experimented, if I set PHP_FCGI_CHILDREN=0, I only get 20 sub-processes for user 'user' and no sub-sub-processes for user, however, performance isn't great. Some more experimenting by writing some test scripts indicates that if I have PHP_FCGI_CHILDREN=0 that requests are not handled simultaneously. The requests seem to be spread around to the multiple waiting dynamic servers but serially. I can post my scripts I used to test this if needed. In essence, if I do 2 POST operations simultaneously, it takes twice as long as when I have PHP_FCGI_CHILDREN>0. PHP_FCGI_CHILDREN certainly needs to be greater than 0, but is there some way I can keep it from multiplying like this? Michael Grant From Olivier.LeCam at crdp.ac-versailles.fr Wed Apr 22 06:25:38 2009 From: Olivier.LeCam at crdp.ac-versailles.fr (Olivier Le Cam) Date: Wed, 22 Apr 2009 12:25:38 +0200 Subject: [FASTCGI] sub-processes In-Reply-To: <62b856460904220205q78dfda71o5f4a8ab9e5e1b795@mail.gmail.com> References: <62b856460904220205q78dfda71o5f4a8ab9e5e1b795@mail.gmail.com> Message-ID: <49EEF0A2.1060905@crdp.ac-versailles.fr> Michael Grant wrote: > PHP_FCGI_CHILDREN certainly needs to be greater than 0, but is there > some way I can keep it from multiplying like this? See this great collection of informations: http://www.seaoffire.net/fcgi-faq.html Pay particular attention to this section: "A : The PHP Wrapper and What it Does". HTH -- Olivier Le Cam From jgray at streamy.com Wed Apr 22 15:54:50 2009 From: jgray at streamy.com (Jonathan Gray) Date: Wed, 22 Apr 2009 12:54:50 -0700 (PDT) Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions Message-ID: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> Hello, I have a multithreaded, C FastCGI script using the fcgiapp library running on top of lighttpd. I'm having a recurring problem on my production environment that crops up after a few days straight of load around 20-40 concurrent connections. This script is implementing something called COMET http://en.wikipedia.org/wiki/Comet_(programming) It's basically using AJAX/XHR requests to simulate pushing to the client. The user opens an AJAX request to the script and the server keeps it loading until a message comes in from the server (it connects to a central server which sends messages to clients), or until we time it out. On the wikipedia page, this is described as Ajax with long polling / XMLHttpRequest long polling. This has been working for a very long time but recently as load has been increasing we started to see a weird behavior. All of a sudden, lighttpd/mod_fastcgi will start to reject all new connections. The log shows this error: 2009-04-01 12:21:33: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 load: 25 2009-04-01 12:21:33: (mod_fastcgi.c.2494) unexpected end-of-file (perhaps the fastcgi process died): pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 The process is not dead, there are 24 other connections that are currently being properly handled. When these requests come in, the script does not see them at all (ie. FCGX_Accept_r does not return). After all the existing connections have dropped, it will then continue normal operation and start to accept new connections: 2009-04-01 12:22:00: (mod_fastcgi.c.1515) released proc: pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 load: 2 2009-04-01 12:22:01: (mod_fastcgi.c.1515) released proc: pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 load: 1 2009-04-01 12:22:03: (mod_fastcgi.c.1515) released proc: pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 load: 0 and then 2009-04-01 12:22:03: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: unix:/home/user/cgi/socks/event.sock-0 load: 1 The same PID (the process never crashed) then does start to see new connections and things go for another few days without problems, then the same thing happens again. The design of my application differs from the example threaded application because I do not keep a thread per connection, rather I use queues, timers, hash tables, etc to track the state of sessions and their FCGX_Request. Since I can't just use a FCGX_Request per thread, as done in the example, I pre-instantiate a large array of FCGX_Requests of size MAX_ALLOC_REQUESTS. I then loop through this array, sliding down one index each time. This array is significantly large that I do not get anywhere close to reusing a request that was not FCGX_Finish_r'd already. (this is set to 25,000 right now, in benchmarking i'm trying to get over 10k. i am nowhere near this in production where the bug happens). Is this a sane approach? Could I be messing something up with my allocating so many and doing FCGX_InitRequest on each. for(i=0;iout,"..."); FCGX_Finish_r(request); That request is still part fo the reqs[] and will be called again, much later, with FCGX_Accept_r. Again, is this right? I read that FCGX_Finish_r is thread-safe, so I'm not locking around that, there are potentially two threads running FPrintF and Finish_r simultaneously (but ALWAYS on different FCGX_Requests). I have increased all kinds of system limits like file/socket descriptor limits and memory limits. I have seen the requests "loop" through the big array of pre-allocated ones, and they are reused without a problem. One thing i'm also not sure about is how keep-alives and pipelining might interact with what i'm doing. When looking into the lighttpd status page, sometimes I noticed connections, after they are out of handle-req and the script has returned/finish_r'd it, they sit in a 'read' state for some time. The only pointer I've got w.r.t. that was it might be trying to read another request from the client? I'd really appreciate any kind of help. I'm a bit stuck and in any case could use some best practices advice. Thanks. Jonathan Gray From jgray at streamy.com Wed Apr 22 16:40:24 2009 From: jgray at streamy.com (Jonathan Gray) Date: Wed, 22 Apr 2009 13:40:24 -0700 (PDT) Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions In-Reply-To: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> References: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> Message-ID: <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> If I disable keep-alives in lighttpd, I no longer see lots of connections in lighttpd status in the read state. That seems to have been tied to keep-alives. How does that work with fastcgi and fcgiapp? Is there anything i need to do to be able to take advantage of keep-alives? The build-up of extra connections in weird states leads me to believe that the keep-alives are not working. On Wed, April 22, 2009 12:54 pm, Jonathan Gray wrote: > Hello, > > > I have a multithreaded, C FastCGI script using the fcgiapp library > running on top of lighttpd. > > I'm having a recurring problem on my production environment that crops up > after a few days straight of load around 20-40 concurrent connections. > > This script is implementing something called COMET > http://en.wikipedia.org/wiki/Comet_(programming) > > > It's basically using AJAX/XHR requests to simulate pushing to the client. > The user opens an AJAX request to the script and the server keeps it > loading until a message comes in from the server (it connects to a central > server which sends messages to clients), or until we time it out. On > the wikipedia page, this is described as Ajax with long polling / > XMLHttpRequest long polling. > > > This has been working for a very long time but recently as load has been > increasing we started to see a weird behavior. > > All of a sudden, lighttpd/mod_fastcgi will start to reject all new > connections. The log shows this error: > > 2009-04-01 12:21:33: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: > unix:/home/user/cgi/socks/event.sock-0 load: 25 > 2009-04-01 12:21:33: (mod_fastcgi.c.2494) unexpected end-of-file (perhaps > the fastcgi process died): pid: 3664 socket: > unix:/home/user/cgi/socks/event.sock-0 > > > > The process is not dead, there are 24 other connections that are > currently being properly handled. When these requests come in, the script > does not see them at all (ie. FCGX_Accept_r does not return). > > After all the existing connections have dropped, it will then continue > normal operation and start to accept new connections: > > 2009-04-01 12:22:00: (mod_fastcgi.c.1515) released proc: pid: 3664 > socket: > unix:/home/user/cgi/socks/event.sock-0 load: 2 > 2009-04-01 12:22:01: (mod_fastcgi.c.1515) released proc: pid: 3664 socket: > unix:/home/user/cgi/socks/event.sock-0 load: 1 > 2009-04-01 12:22:03: (mod_fastcgi.c.1515) released proc: pid: 3664 socket: > unix:/home/user/cgi/socks/event.sock-0 load: 0 > > > and then > > 2009-04-01 12:22:03: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: > unix:/home/user/cgi/socks/event.sock-0 load: 1 > > > The same PID (the process never crashed) then does start to see new > connections and things go for another few days without problems, then the > same thing happens again. > > > The design of my application differs from the example threaded > application because I do not keep a thread per connection, rather I use > queues, timers, hash tables, etc to track the state of sessions and their > FCGX_Request. > > > Since I can't just use a FCGX_Request per thread, as done in the example, > I pre-instantiate a large array of FCGX_Requests of size > MAX_ALLOC_REQUESTS. I then loop through this array, sliding down one > index each time. This array is significantly large that I do not get > anywhere close to reusing a request that was not FCGX_Finish_r'd already. > (this is set to 25,000 right now, in benchmarking i'm trying to get over > 10k. i am nowhere near this in production where the bug happens). > > > Is this a sane approach? Could I be messing something up with my > allocating so many and doing FCGX_InitRequest on each. > > for(i=0;i > > I am locking around the accept, so the accepting of connections is > single-threaded: > > > pthread_mutex_lock(&accept_mutex); rc = FCGX_Accept_r(&reqs[curreq]); > nextreq = (curreq + 1) % MAX_ALLOC_REQUESTS; > pthread_mutex_unlock(&accept_mutex); > > > I have two potential threads that can close the connection. In all > cases, the closing of the connection follows the form: > > FCGX_FPrintF(request->out,"..."); > FCGX_Finish_r(request); > > > > That request is still part fo the reqs[] and will be called again, much > later, with FCGX_Accept_r. > > Again, is this right? I read that FCGX_Finish_r is thread-safe, so I'm > not locking around that, there are potentially two threads running FPrintF > and Finish_r simultaneously (but ALWAYS on different FCGX_Requests). > > > I have increased all kinds of system limits like file/socket descriptor > limits and memory limits. I have seen the requests "loop" through the big > array of pre-allocated ones, and they are reused without a problem. > > One thing i'm also not sure about is how keep-alives and pipelining might > interact with what i'm doing. When looking into the lighttpd status > page, sometimes I noticed connections, after they are out of handle-req > and the script has returned/finish_r'd it, they sit in a 'read' state for > some time. The only pointer I've got w.r.t. that was it might be trying > to read another request from the client? > > > I'd really appreciate any kind of help. I'm a bit stuck and in any case > could use some best practices advice. > > Thanks. > > > Jonathan Gray > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > > From mgrant at grant.org Wed Apr 22 19:31:17 2009 From: mgrant at grant.org (Michael Grant) Date: Thu, 23 Apr 2009 01:31:17 +0200 Subject: [FASTCGI] sub-processes In-Reply-To: <49EEF0A2.1060905@crdp.ac-versailles.fr> References: <62b856460904220205q78dfda71o5f4a8ab9e5e1b795@mail.gmail.com> <49EEF0A2.1060905@crdp.ac-versailles.fr> Message-ID: <62b856460904221631u30432d22j65ff0c028ea90a4@mail.gmail.com> On Wed, Apr 22, 2009 at 12:25 PM, Olivier Le Cam wrote: > Michael Grant wrote: > >> PHP_FCGI_CHILDREN certainly needs to be greater than 0, but is there >> some way I can keep it from multiplying like this? > > See this great collection of informations: > http://www.seaoffire.net/fcgi-faq.html > > Pay particular attention to this section: "A : The PHP Wrapper and What it > Does". > > HTH Yes, I've seen this excellent page. I have followed it pretty closely with only a few exceptions. For instance, I am using security2_module to do the chroot, not chrootssh and I'm using suexec to change users, hence I have this: FastCgiWrapper /usr/local/sbin/suexec I do not see the same behavior reported on this web page. For example under "E : Troubleshooting the PHP Wrapper", I do not see an fcgi-pm process, I only see my wrapper php.fcgi process. I don't even have fcgi-pm on my system. Their processes seem normal and reasonable, I don't see that on my box. As soon as I set PHP_FCGI_CHILDREN>0, the number of processes I get seems to be MaxSpareServers x PHP_FCGI_CHILDREN+1. This seems wrong. Michael Grant From jgray at streamy.com Wed Apr 22 19:39:55 2009 From: jgray at streamy.com (Jonathan Gray) Date: Wed, 22 Apr 2009 16:39:55 -0700 (PDT) Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions In-Reply-To: <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> References: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> Message-ID: <4497.98.112.71.211.1240443595.squirrel@webmail.streamy.com> Further testing is now reproducing the issue. It happens after the 65,563rd connection. It then stops accepting connections until all connections are dropped. Then it continues normally. This is suspiciously close to 64 * 1024 (what i have set my linux max file descriptors to). Is lighttpd or fastcgi somehow hanging on to file descriptors, either to the lighttpd->fastcgi file socket, or http/tcp sockets? Is there something else tied to ~64k I should look in to? Thanks. JG On Wed, April 22, 2009 1:40 pm, Jonathan Gray wrote: > If I disable keep-alives in lighttpd, I no longer see lots of connections > in lighttpd status in the read state. That seems to have been tied to > keep-alives. > > How does that work with fastcgi and fcgiapp? Is there anything i need to > do to be able to take advantage of keep-alives? The build-up of extra > connections in weird states leads me to believe that the keep-alives are > not working. > > On Wed, April 22, 2009 12:54 pm, Jonathan Gray wrote: > >> Hello, >> >> >> >> I have a multithreaded, C FastCGI script using the fcgiapp library >> running on top of lighttpd. >> >> I'm having a recurring problem on my production environment that crops >> up after a few days straight of load around 20-40 concurrent >> connections. >> >> This script is implementing something called COMET >> http://en.wikipedia.org/wiki/Comet_(programming) >> >> >> >> It's basically using AJAX/XHR requests to simulate pushing to the >> client. The user opens an AJAX request to the script and the server >> keeps it loading until a message comes in from the server (it connects >> to a central server which sends messages to clients), or until we time >> it out. On the wikipedia page, this is described as Ajax with long >> polling / XMLHttpRequest long polling. >> >> >> >> This has been working for a very long time but recently as load has >> been increasing we started to see a weird behavior. >> >> All of a sudden, lighttpd/mod_fastcgi will start to reject all new >> connections. The log shows this error: >> >> 2009-04-01 12:21:33: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: >> unix:/home/user/cgi/socks/event.sock-0 load: 25 >> 2009-04-01 12:21:33: (mod_fastcgi.c.2494) unexpected end-of-file >> (perhaps >> the fastcgi process died): pid: 3664 socket: >> unix:/home/user/cgi/socks/event.sock-0 >> >> >> >> >> The process is not dead, there are 24 other connections that are >> currently being properly handled. When these requests come in, the >> script does not see them at all (ie. FCGX_Accept_r does not return). >> >> After all the existing connections have dropped, it will then continue >> normal operation and start to accept new connections: >> >> 2009-04-01 12:22:00: (mod_fastcgi.c.1515) released proc: pid: 3664 >> socket: >> unix:/home/user/cgi/socks/event.sock-0 load: 2 >> 2009-04-01 12:22:01: (mod_fastcgi.c.1515) released proc: pid: 3664 >> socket: >> unix:/home/user/cgi/socks/event.sock-0 load: 1 >> 2009-04-01 12:22:03: (mod_fastcgi.c.1515) released proc: pid: 3664 >> socket: >> unix:/home/user/cgi/socks/event.sock-0 load: 0 >> >> >> >> and then >> >> 2009-04-01 12:22:03: (mod_fastcgi.c.3005) got proc: pid: 3664 socket: >> unix:/home/user/cgi/socks/event.sock-0 load: 1 >> >> >> >> The same PID (the process never crashed) then does start to see new >> connections and things go for another few days without problems, then >> the same thing happens again. >> >> >> The design of my application differs from the example threaded >> application because I do not keep a thread per connection, rather I use >> queues, timers, hash tables, etc to track the state of sessions and >> their FCGX_Request. >> >> >> >> Since I can't just use a FCGX_Request per thread, as done in the >> example, I pre-instantiate a large array of FCGX_Requests of size >> MAX_ALLOC_REQUESTS. I then loop through this array, sliding down one >> index each time. This array is significantly large that I do not get >> anywhere close to reusing a request that was not FCGX_Finish_r'd >> already. (this is set to 25,000 right now, in benchmarking i'm trying to >> get over 10k. i am nowhere near this in production where the bug >> happens). >> >> >> Is this a sane approach? Could I be messing something up with my >> allocating so many and doing FCGX_InitRequest on each. >> >> for(i=0;i> >> >> I am locking around the accept, so the accepting of connections is >> single-threaded: >> >> >> >> pthread_mutex_lock(&accept_mutex); rc = FCGX_Accept_r(&reqs[curreq]); >> nextreq = (curreq + 1) % MAX_ALLOC_REQUESTS; >> pthread_mutex_unlock(&accept_mutex); >> >> >> I have two potential threads that can close the connection. In all >> cases, the closing of the connection follows the form: >> >> FCGX_FPrintF(request->out,"..."); >> FCGX_Finish_r(request); >> >> >> >> >> That request is still part fo the reqs[] and will be called again, much >> later, with FCGX_Accept_r. >> >> Again, is this right? I read that FCGX_Finish_r is thread-safe, so I'm >> not locking around that, there are potentially two threads running >> FPrintF >> and Finish_r simultaneously (but ALWAYS on different FCGX_Requests). >> >> >> I have increased all kinds of system limits like file/socket descriptor >> limits and memory limits. I have seen the requests "loop" through the >> big array of pre-allocated ones, and they are reused without a problem. >> >> One thing i'm also not sure about is how keep-alives and pipelining >> might interact with what i'm doing. When looking into the lighttpd >> status page, sometimes I noticed connections, after they are out of >> handle-req and the script has returned/finish_r'd it, they sit in a >> 'read' state for >> some time. The only pointer I've got w.r.t. that was it might be trying >> to read another request from the client? >> >> >> I'd really appreciate any kind of help. I'm a bit stuck and in any >> case could use some best practices advice. >> >> Thanks. >> >> >> >> Jonathan Gray >> _______________________________________________ >> FastCGI-developers mailing list >> FastCGI-developers at mailman.fastcgi.com >> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers >> >> >> >> > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > > From jon+fastcgi-developers at unequivocal.co.uk Wed Apr 22 20:33:17 2009 From: jon+fastcgi-developers at unequivocal.co.uk (Jon Ribbens) Date: Thu, 23 Apr 2009 01:33:17 +0100 Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions In-Reply-To: <4497.98.112.71.211.1240443595.squirrel@webmail.streamy.com> References: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> <4497.98.112.71.211.1240443595.squirrel@webmail.streamy.com> Message-ID: <20090423003317.GR26224@snowy.squish.net> On Wed, Apr 22, 2009 at 04:39:55PM -0700, Jonathan Gray wrote: > This is suspiciously close to 64 * 1024 (what i have set my linux max file > descriptors to). Is lighttpd or fastcgi somehow hanging on to file > descriptors, either to the lighttpd->fastcgi file socket, or http/tcp > sockets? Is there something else tied to ~64k I should look in to? Several things I should imagine. Make your process restart every 60,000 requests? From jgray at streamy.com Wed Apr 22 21:41:33 2009 From: jgray at streamy.com (Jonathan Gray) Date: Wed, 22 Apr 2009 18:41:33 -0700 (PDT) Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions In-Reply-To: <20090423003317.GR26224@snowy.squish.net> References: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> <4497.98.112.71.211.1240443595.squirrel@webmail.streamy.com> <20090423003317.GR26224@snowy.squish.net> Message-ID: <1141.98.119.172.113.1240450893.squirrel@webmail.streamy.com> It's not really possible on my application. The connections are long-lived and do not reconnect in sync, so there is no instance in time where no one is connected. The transition from one web server to another would be extraordinarily complex in my case. There's obviously something wrong or misconfigured in my application, fastcgi, lighttpd, system settings... or most likely the interaction of these things. I'd rather not just treat the symptom. JG On Wed, April 22, 2009 5:33 pm, Jon Ribbens wrote: > On Wed, Apr 22, 2009 at 04:39:55PM -0700, Jonathan Gray wrote: > >> This is suspiciously close to 64 * 1024 (what i have set my linux max >> file descriptors to). Is lighttpd or fastcgi somehow hanging on to file >> descriptors, either to the lighttpd->fastcgi file socket, or http/tcp >> sockets? Is there something else tied to ~64k I should look in to? > > Several things I should imagine. Make your process restart every > 60,000 requests? > > > From onefriedrice at brokenzipper.com Wed Apr 22 22:32:03 2009 From: onefriedrice at brokenzipper.com (Charles McGarvey) Date: Wed, 22 Apr 2009 20:32:03 -0600 Subject: [FASTCGI] Threaded C fcgiapp implementation problems and questions In-Reply-To: <1141.98.119.172.113.1240450893.squirrel@webmail.streamy.com> References: <1129.98.112.71.211.1240430090.squirrel@webmail.streamy.com> <1588.98.112.71.211.1240432824.squirrel@webmail.streamy.com> <4497.98.112.71.211.1240443595.squirrel@webmail.streamy.com> <20090423003317.GR26224@snowy.squish.net> <1141.98.119.172.113.1240450893.squirrel@webmail.streamy.com> Message-ID: <49EFD323.700@brokenzipper.com> I have seen weird behavior trying to use a lot of requests (a new one per connection) versus one request object per thread. While the problems you're describing are not exactly the problems I've seen, I wonder if you would see an improvement if you could model your app more closely with the threaded example. -Chaz Jonathan Gray wrote: > It's not really possible on my application. The connections are > long-lived and do not reconnect in sync, so there is no instance in time > where no one is connected. The transition from one web server to another > would be extraordinarily complex in my case. > > There's obviously something wrong or misconfigured in my application, > fastcgi, lighttpd, system settings... or most likely the interaction of > these things. I'd rather not just treat the symptom. > > JG > > On Wed, April 22, 2009 5:33 pm, Jon Ribbens wrote: > >> On Wed, Apr 22, 2009 at 04:39:55PM -0700, Jonathan Gray wrote: >> >> >>> This is suspiciously close to 64 * 1024 (what i have set my linux max >>> file descriptors to). Is lighttpd or fastcgi somehow hanging on to file >>> descriptors, either to the lighttpd->fastcgi file socket, or http/tcp >>> sockets? Is there something else tied to ~64k I should look in to? >>> >> Several things I should imagine. Make your process restart every >> 60,000 requests? >> >> >> >> > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > From webmaster at cosmicperl.com Wed Apr 29 15:10:44 2009 From: webmaster at cosmicperl.com (Lyle) Date: Wed, 29 Apr 2009 20:10:44 +0100 Subject: [FASTCGI] FastCgiWrapper: "/usr/sbin/suexec" execute access for server (uid 4294967295 or -1, gid 4294967295 or -1) failed: execute not allowed Message-ID: <49F8A634.3070704@cosmicperl.com> Hi All, I came across this issue when installing mod_fastcgi with CentOS. When I search for the error I couldn't find a solution, so I thought I'd post it here:- This problem is caused by your suexec executable having restricted permissions and only letting a specific group execute it. I rectified this problem by letting everyone execute:- chmod 4755 suexec Lyle