osdir.com
mailing list archive

Subject: Any way to increase RSS (shared memory) by pre-loading under fastcgi? - msg#00006

List: web.fastcgi.devel

Date: Prev Next Index Thread: Prev Next Index
I am familiar with some pre-loading tricks under mod-perl (loading code,
vars before the server forks). Is there any advantage (in terms of shred
memory) to using or requiring modules before waiting for requests? Any
other tricks to improve shared memory under fastcgi?

-------------
use Some::Module;
while (my $q = CGI::Fast->new()) {
...
}

---- vs. ----
while (my $q = CGI::Fast->new()) {
require Some::Module;
...

}


Thanks,
Mike





___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: perl FCGI segmentation fault using ithreads ...

Hi, Actually I solve this problem by .. 1.- Creating the threads before the accept loop 2.- Creating a pool of threads and keeping them alive. Thanks, Igor Igor Suarez-Sola wrote: Hi, I imagine this is not new, so apologies in advance if this has been disscussed already but I haven't found an answer yet. I'd like to use FCGI and perl ithreads in the same application. However it looks like after one loop the application crashes with a segmentation fault. This is a example that reproduce the problem. use CGI::Fast qw(:standard *table *script *div start_ul -nosticky); use threads; my $count = 0; my $request = FCGI::Request(); while(new CGI::Fast()) { { print("Content-type: text/html\r\n\r\n", ++$count,"\n"); my @thArr =(); for my $num (1..3) { my $thr = threads->create (\&dispatcher, $num); push @thArr, $thr; } for my $th (@thArr) { my $r = $th->join; if (defined($r)) { print "Thread id [",$r->{tid},"] ;; Order num [",$r->{num},"] ;; time [",$r->{time},"]\n"; } } } sub dispatcher { my $num = shift; # does nothing only returns a hash; my $hash={}; $hash->{time}=gmtime; $hash->{tid}=threads->self->tid; $hash->{num}=$num; return $hash; } 1; ######################### If I call this cgi from apache I get in the logs: [Thu Aug 05 14:27:07 2004] [warn] FastCGI: server "/var/www/cgi-bin/VSO_FAST/votest.pl" (pid 14843) terminated due to uncaught signal '11' (Segmentation fault) If I run it manually I get a long list of errors like: Attempt to free non-existent shared string 'SSH_ASKPASS', Perl interpreter: 0x8350438 during global destruction. I'm using perl 5.8.5 , Apache/2.0.48 and mod_fastcgi 2.4.2 Any info is most welcome! Thanks! Igor ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/

Next Message by Date: click to view message preview

Re: perl FCGI segmentation fault using ithreads ...

Igor, You are doing this: Master perl -> load FCGI -> create FCGI handle -> accept FCGI socket -> create new interpreter thread ->request ->request If threading is giving you segfaults, it is a fairly safe bet that the FCGI.pm module is not re-entrant. Observe that you could move the thread creation to any point in the tree, eg Master perl -> load FCGI -> create new interpreter thread -> create FCGI handle -> accept FCGI socket ->request ->request -> create FCGI handle -> accept FCGI socket ->request ->request Depending on where the non-reentrancy bug in the FCGI.pm XS part lies, you might be restricted to doing it before you even load the FCGI module. If you can have a monitor thread that spots when all of the worker threads are busy, you could keep a nice little managed threadpool, too. Just a thought, Sam. Igor Suarez-Sola wrote: Hi, I imagine this is not new, so apologies in advance if this has been disscussed already but I haven't found an answer yet. I'd like to use FCGI and perl ithreads in the same application. However it looks like after one loop the application crashes with a segmentation fault. This is a example that reproduce the problem. use CGI::Fast qw(:standard *table *script *div start_ul -nosticky); use threads; my $count = 0; my $request = FCGI::Request(); while(new CGI::Fast()) { { print("Content-type: text/html\r\n\r\n", ++$count,"\n"); my @thArr =(); for my $num (1..3) { my $thr = threads->create (\&dispatcher, $num); push @thArr, $thr; } for my $th (@thArr) { my $r = $th->join; if (defined($r)) { print "Thread id [",$r->{tid},"] ;; Order num [",$r->{num},"] ;; time [",$r->{time},"]\n"; } } } sub dispatcher { my $num = shift; # does nothing only returns a hash; my $hash={}; $hash->{time}=gmtime; $hash->{tid}=threads->self->tid; $hash->{num}=$num; return $hash; } 1; ######################### If I call this cgi from apache I get in the logs: [Thu Aug 05 14:27:07 2004] [warn] FastCGI: server "/var/www/cgi-bin/VSO_FAST/votest.pl" (pid 14843) terminated due to uncaught signal '11' (Segmentation fault) If I run it manually I get a long list of errors like: Attempt to free non-existent shared string 'SSH_ASKPASS', Perl interpreter: 0x8350438 during global destruction. I'm using perl 5.8.5 , Apache/2.0.48 and mod_fastcgi 2.4.2 Any info is most welcome! Thanks! Igor ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/ ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/

Previous Message by Thread: click to view message preview

perl FCGI segmentation fault using ithreads ...

Hi, I imagine this is not new, so apologies in advance if this has been disscussed already but I haven't found an answer yet. I'd like to use FCGI and perl ithreads in the same application. However it looks like after one loop the application crashes with a segmentation fault. This is a example that reproduce the problem. use CGI::Fast qw(:standard *table *script *div start_ul -nosticky); use threads; my $count = 0; my $request = FCGI::Request(); while(new CGI::Fast()) { { print("Content-type: text/html\r\n\r\n", ++$count,"\n"); my @thArr =(); for my $num (1..3) { my $thr = threads->create (\&dispatcher, $num); push @thArr, $thr; } for my $th (@thArr) { my $r = $th->join; if (defined($r)) { print "Thread id [",$r->{tid},"] ;; Order num [",$r->{num},"] ;; time [",$r->{time},"]\n"; } } } sub dispatcher { my $num = shift; # does nothing only returns a hash; my $hash={}; $hash->{time}=gmtime; $hash->{tid}=threads->self->tid; $hash->{num}=$num; return $hash; } 1; ######################### If I call this cgi from apache I get in the logs: [Thu Aug 05 14:27:07 2004] [warn] FastCGI: server "/var/www/cgi-bin/VSO_FAST/votest.pl" (pid 14843) terminated due to uncaught signal '11' (Segmentation fault) If I run it manually I get a long list of errors like: Attempt to free non-existent shared string 'SSH_ASKPASS', Perl interpreter: 0x8350438 during global destruction. I'm using perl 5.8.5 , Apache/2.0.48 and mod_fastcgi 2.4.2 Any info is most welcome! Thanks! Igor ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/

Next Message by Thread: click to view message preview

problems with UNIX domain sockets

Hi all, I've implemented the webserver side of the FastCGI protocol. I've built some test apps in Perl using the Perl FCGI library version 0.67, which is based on the FastCGI development kit version 2.4.0. I'm having two problems. #1 The library closes the connection if it's a UNIX domain socket and it does not receive any data within 2 seconds. There is a big long comment in os_unix.c about how this is supposed to work around an obscure bug in Linux 2.0.x and SCO UnixWare wherein you could accept a connection that was already closed on the client side, blah blah blah. I see in the mailing list archives that this has been mentioned before, but I don't think anything has been done about it yet. The problem I'm having is that my webserver creates a connection to the FastCGI app at init time and keeps it open (persistent); it only sends data to the FastCGI app when there is an actual request, which probably won't be in the first 2 seconds. I've chosen this model for performance reasons. Shouldn't this kludge be off by default, and only on for those systems that are affected? By "those systems that are affected", I mean you could either use #ifdefs based on architecture, or perhaps even a simple simulation could be performed at compile time to determine if the system is affected. I know that I can make a special versin of the FCGI library myself to disable the kludge, but given that my aim is to incorporate FastCGI support into a *webserver*, I want that webserver to be able to work with a wide variety of FastCGI apps out there. This kludge is very annoying. #2 To try to work around the kludge without modifying the Perl FCGI library, I decided that I could have my webserver send an FCGI_GET_VALUES message to the FastCGI app immediately after connecting to it. Here is a hexdump of the exact message I send, in case somebody can spot something I'm doing wrong: 01 09 00 00 00 30 00 00 0E 00 46 43 47 49 5F 4D .....0....FCGI_M 41 58 5F 43 4F 4E 4E 53 0D 00 46 43 47 49 5F 4D AX_CONNS..FCGI_M 41 58 5F 52 45 51 53 0F 00 46 43 47 49 5F 4D 50 AX_REQS..FCGI_MP 58 53 5F 43 4F 4E 4E 53 XS_CONNS The problem is I never get a response back; the FastCGI app reads in the three name-value pairs but then enters a perma-blocked state trying to read more name-value pairs. In fcgiapp.c, line 1464, ProcessManagementRecord() calls ReadParams() which starts to read the name-value pairs. But it doesn't know when to stop. Once it has exhausted the three pairs, it keeps on going and calls FCGX_GetChar() again, which ends up doing a read() because there's no more data. It sits in the read(), so ReadParams() never returns, and consequently we never get back into ProcessManagementRecord() so that it can send back the FCGI_GET_VALUES_RESULT message. BTW this problem is not specific to UNIX domain sockets. So in order to get the FCGI_GET_VALUES / FCGI_GET_VALUES_RESULT exchange to work, I would have to hack up the FCGI library which is what I wanted to avoid. Basically I have no way of communicating reliably with an off-the-shelf FCGI library over a UNIX domain socket in my model where I don't necessarily send data immediately after connecting. Any help is greatly appreciated! ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by