Re: [cgiapp] mod_perl vs. FastCGI

2009-02-09 Thread Benjamin Hitz


We have converted a plain cgi app under CGI::App (no dispatch) to run  
under FCGI without much difficulty (Solaris).  The biggest problem I  
had was some mixed apps where I was creating 2 distinct DBI database  
handles.  Once I got it down to 1, everything worked well.


Primary gain is start up time from stuff like DBIx::Class (but  
CGI::App and even perl are kinda heavy weight).


We still have to restart apache to debug it, although in principle  
you don't.


Ben

On Jan 19, 2009, at 8:57 AM, fREW Schmidt wrote:


Someone earlier mentioned that FastCGI adds a good layer between
apache and the application.

The main issues I have with mod_perl is that even with Apache2::Reload
I still get errors and have to restart the server while I am
developing.  I think the issue has something to do with the way that
Autorunmode is implemented.


I also like the idea that with FastCGI we can switch back to IIS.  I
am trying to convince my boss that Apache is a good option, but it
would be nice to be able to switch back to IIS if there are issues.

Anyway, I worry that I will keep having issues like this as I develop,
and restarting the server every time I make a change (while in
development of course) is just silly.  Does anyone know how hard it is
to set up FastCGI with CGI::Application and
CGI::Application::Dispatch?


--

-fREW

#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####



--
Ben Hitz
Senior Scientific Programmer ** Saccharomyces Genome Database ** GO  
Consortium

Stanford University ** h...@genome.stanford.edu




#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-02-09 Thread Peter Karman
Benjamin Hitz wrote on 02/09/2009 12:30 PM:
 
 We have converted a plain cgi app under CGI::App (no dispatch) to run
 under FCGI without much difficulty (Solaris).  The biggest problem I had
 was some mixed apps where I was creating 2 distinct DBI database
 handles.  Once I got it down to 1, everything worked well.
 
 Primary gain is start up time from stuff like DBIx::Class (but CGI::App
 and even perl are kinda heavy weight).
 
 We still have to restart apache to debug it, although in principle you
 don't.

I recommend the in principle part. I run all my fastcgi apps using the
ExternalServer option, which I found well documented at the fastcgi
site. That lets me stop/start the app independently of apache, which is
nice for rolling out new versions, etc.

-- 
Peter Karman  .  pe...@peknet.com  .  http://peknet.com/


#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-02-09 Thread Steve
I've got my app with Dispatch (and Autorunmode) running under mod_fcgid. 
I've actually seen some pretty astounding speed improvements (approx 17x 
faster) since I've done it.


I usually debug my apps by reverting my local apache config to run under 
vanilla CGI.


---
Steve Comrie

Benjamin Hitz wrote:


We have converted a plain cgi app under CGI::App (no dispatch) to run 
under FCGI without much difficulty (Solaris).  The biggest problem I 
had was some mixed apps where I was creating 2 distinct DBI database 
handles.  Once I got it down to 1, everything worked well.


Primary gain is start up time from stuff like DBIx::Class (but 
CGI::App and even perl are kinda heavy weight).


We still have to restart apache to debug it, although in principle 
you don't.


Ben

On Jan 19, 2009, at 8:57 AM, fREW Schmidt wrote:


Someone earlier mentioned that FastCGI adds a good layer between
apache and the application.

The main issues I have with mod_perl is that even with Apache2::Reload
I still get errors and have to restart the server while I am
developing.  I think the issue has something to do with the way that
Autorunmode is implemented.


I also like the idea that with FastCGI we can switch back to IIS.  I
am trying to convince my boss that Apache is a good option, but it
would be nice to be able to switch back to IIS if there are issues.

Anyway, I worry that I will keep having issues like this as I develop,
and restarting the server every time I make a change (while in
development of course) is just silly.  Does anyone know how hard it is
to set up FastCGI with CGI::Application and
CGI::Application::Dispatch?


--

-fREW

#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####



--
Ben Hitz
Senior Scientific Programmer ** Saccharomyces Genome Database ** GO 
Consortium

Stanford University ** h...@genome.stanford.edu




#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####





#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-02-09 Thread Benjamin Hitz


On Feb 9, 2009, at 10:47 AM, Peter Karman wrote:


Benjamin Hitz wrote on 02/09/2009 12:30 PM:


We have converted a plain cgi app under CGI::App (no dispatch) to run
under FCGI without much difficulty (Solaris).  The biggest problem  
I had

was some mixed apps where I was creating 2 distinct DBI database
handles.  Once I got it down to 1, everything worked well.

Primary gain is start up time from stuff like DBIx::Class (but  
CGI::App

and even perl are kinda heavy weight).

We still have to restart apache to debug it, although in  
principle you

don't.


I recommend the in principle part. I run all my fastcgi apps using  
the

ExternalServer option, which I found well documented at the fastcgi
site. That lets me stop/start the app independently of apache, which  
is

nice for rolling out new versions, etc.



Thanks Peter, I will check it out.  Restarting apache takes about 1  
second for us (obviously, we do this on a development machine/ 
development web server)


Ben

--
Ben Hitz
Senior Scientific Programmer ** Saccharomyces Genome Database ** GO  
Consortium

Stanford University ** h...@genome.stanford.edu




#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-02-08 Thread Ron Savage
Hi Folks

Did anyone get FCGI::Engine V (0.05) working?

I didn't, and logged a ticket with RT:

o OS: Debian
o Perl: 5.10.0
o One test failed and one test hung:

Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'inc', 'blib/lib', 'blib/arch') t/*.t
t/000_load.ok 
t/001_basicok 
t/002_basic_with_listen13/17 
# Failed test '... our pidfile was created'
# at t/002_basic_with_listen.t line 62.

# Failed test '... our daemon is running (pid: 20680)'
# at t/002_basic_with_listen.t line 67.
t/002_basic_with_listen Failed 3/17 subtests 
t/003_basic_with_options...ok 
t/010_errors...ok 
t/020_basic_manager1/19 
^Cmake: *** [test_dynamic] Interrupt

-- 
Ron Savage
r...@savage.net.au
http://savage.net.au/index.html



#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-01-19 Thread fREW Schmidt
 However, if that still seems like too long, and your code is too
 tricky for Apache2::Reload, there are two simple solutions.  One is to
 develop under CGI, which should be easy for most CGI::App users.  Then
 you just switch over to mod_perl when you're ready for testing.

I think I'll do this one.  That's definitely reasonable.  What about
the dispatch stuff?  Will my URL just look like this:

foo/Dispatch.pm/controller_foo/action

?

 Another is to set MaxRequestsPerChild to 1, so that your code is
 compiled fresh every time.  If you do this, make sure you don't load
 the code you're editing in your startup.pl (before the fork).

I'd prefer to do the previous idea as I've had lots of success with
apache and vanilla cgi before, but I may look into this when I'm not
so busy.

 I also like the idea that with FastCGI we can switch back to IIS.

 Can't say I agree with you there, but to each their own.  However, I
 would caution you that when I tried to find an IIS FastCGI solution a
 few years ago, there was really nothing available.  That may have
 changed since Ruby increased the popularity of FastCGI.

Well, technically I agree with you and I think we should abandon IIS
and SQL Server and Windows even, but you have to start small :-)

I think I'll just do the CGI stuff for now as that should be just fine
really.  mod_perl may be overkill anyway as we will probably never
have more than 5 users at the same time as this app is for one single
small organization.

-fREW

#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####




Re: [cgiapp] mod_perl vs. FastCGI

2009-01-19 Thread Lyle

Perrin Harkins wrote:

On Mon, Jan 19, 2009 at 11:57 AM, fREW Schmidt fri...@gmail.com wrote:
  

The main issues I have with mod_perl is that even with Apache2::Reload
I still get errors and have to restart the server while I am
developing.



Pity the Java guys.  It can take 5 minutes or more to restart IBM's
EJB dev environment.  Most mod_perl servers restart in less than 5
seconds.

However, if that still seems like too long, and your code is too
tricky for Apache2::Reload, there are two simple solutions.  One is to
develop under CGI, which should be easy for most CGI::App users.  Then
you just switch over to mod_perl when you're ready for testing.

Another is to set MaxRequestsPerChild to 1, so that your code is
compiled fresh every time.  If you do this, make sure you don't load
the code you're editing in your startup.pl (before the fork).

  

I also like the idea that with FastCGI we can switch back to IIS.



Can't say I agree with you there, but to each their own.  However, I
would caution you that when I tried to find an IIS FastCGI solution a
few years ago, there was really nothing available.  That may have
changed since Ruby increased the popularity of FastCGI.
  


Microsoft have themselves made a FastCGI library. It was done in 
partnership with Zend to improve PHP's performance on IIS.

All details can be found at www.iis.net

You don't have to like Microsoft or IIS, but it makes business sense to 
have it as an option.



Lyle


#  CGI::Application community mailing list  
####
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:  http://cgiapp.erlbaum.net/ ##
####