Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Switching to a production server

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


emily at burnham

Sep 9, 2008, 3:19 PM

Post #1 of 7 (1581 views)
Permalink
Switching to a production server

Hi, I have been developing a Catalyst application and just using the
Catalyst myapp_server.pl script to run it. We server a very small market,
currently less than 100 visits a day. The major issue we are having is that
even small images are loaded very slowly, and therefore the pages are loaded
slowly, on the order of more than 5 seconds for a first time visitor.



At this time, I don't know anything about fast_cgi or configuring apache or
what have you, to work with Catalyst, but before I take that on, my question
is, is it likely that the slow loading of very small images has to do with
the default myapp_server.pl, and switching to something else will make a big
difference with loading images and possibly other files?



Thanks,

Emily


mikhail.maluyk at gmail

Sep 9, 2008, 3:47 PM

Post #2 of 7 (1492 views)
Permalink
Re: Switching to a production server [In reply to]

Hi Emily,

For fast image serving you could use reverse proxy. For configuring
nginx as reverse proxy, follow that link
http://blog.kovyrin.net/2006/05/18/nginx-as-reverse-proxy/lang/en/

I'm not sure if the catalyst myapp_server.pl is more than a
development server. I suggest you switch to apache with nginx or
lighthttpd as a reverse proxy server.

2008/9/10 Emily Heureux <emily [at] burnham>:
> Hi, I have been developing a Catalyst application and just using the
> Catalyst myapp_server.pl script to run it. We server a very small market,
> currently less than 100 visits a day. The major issue we are having is that
> even small images are loaded very slowly, and therefore the pages are loaded
> slowly, on the order of more than 5 seconds for a first time visitor.
>
>
>
> At this time, I don't know anything about fast_cgi or configuring apache or
> what have you, to work with Catalyst, but before I take that on, my question
> is, is it likely that the slow loading of very small images has to do with
> the default myapp_server.pl, and switching to something else will make a big
> difference with loading images and possibly other files?
>
>
>
> Thanks,
>
> Emily
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>



--
Regards,
Mikhail

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Sep 9, 2008, 4:12 PM

Post #3 of 7 (1486 views)
Permalink
Re: Switching to a production server [In reply to]

On 9 Sep 2008, at 23:19, Emily Heureux wrote:
> At this time, I don’t know anything about fast_cgi or configuring
> apache or what have you, to work with Catalyst, but before I take
> that on, my question is, is it likely that the slow loading of very
> small images has to do with the default myapp_server.pl, and
> switching to something else will make a big difference with loading
> images and possibly other files?
>

By default, the myapp_server.pl which comes with catalyst for
development is _single threaded_. This means that if you have 200
images on the page, each image will be fetched one after the other,
which will be slow.

In a real deployment environment, you won't be single threaded (your
browser is likely to download 4 things at once), which will help.
Assuming that the images are static, you also want to configure your
web server to serve them statically, so Catalyst will never see the
image requests, this will significantly lower the overhead of serving
these images.

I recommend you set your app up with something like what your real
deployment is going to be (e.g. if your real deployment is going to
be fastcgi, then get fastcgi going on your development machine to
test it with).

See how your app looks then, and if you've still got speed issues you
can look at profiling the request (if that's what is taking the
time), and/or optimising the content (e.g. by using CSS sprites to
reduce the number of images in the page)..

Cheers
t0m


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


m9tn-oh4c at xemaps

Sep 10, 2008, 1:33 AM

Post #4 of 7 (1485 views)
Permalink
Re: Switching to a production server [In reply to]

Emily Heureux wrote:
>
> Hi, I have been developing a Catalyst application and just using the
> Catalyst myapp_server.pl script to run it. We server a very small
> market, currently less than 100 visits a day. The major issue we are
> having is that even small images are loaded very slowly, and therefore
> the pages are loaded slowly, on the order of more than 5 seconds for a
> first time visitor.
>
>
>
> At this time, I don’t know anything about fast_cgi or configuring
> apache or what have you, to work with Catalyst, but before I take that
> on, my question is, is it likely that the slow loading of very small
> images has to do with the default myapp_server.pl, and switching to
> something else will make a big difference with loading images and
> possibly other files?
>
>
>
I don't recommend going live by running myapp_server.pl - this is
intended for development and debugging. I do recommend using a
standalone fastcgi process farm (which could have just a single
instance), talking through a named pipe in the /tmp directory. The
fastcgi process runs in your application user account, saving you from
having to open up the permissions of your files to the www-data user.

This is quite well documented, see
http://search.cpan.org/~mramberg/Catalyst-Runtime/lib/Catalyst/Engine/FastCGI.pm

Also apart from in special circumstances, there's usually no reason to
serve images through your Catalyst application. The special
circumstances I imagine could be if the image is being stored in a
database blob, or being tweaked on the fly with ImageMagick.

One option could be to change the URLs for the images to be absolute
ones on the webserver, rather than static/images/powered_by.jpg etc.
which will deliver performance results with myapp_server.pl. You'd need
to copy the root/static/images directory to somewhere more public, where
the www-data user can see and use it. A recommended, documented option
is to configure Apache to handle /static rather than pass these requests
to the application with the following config snippet:

<Location /static>
SetHandler default-handler
</Location>


For more on configuring Apache 2.0, see
http://search.cpan.org/~agrundma/Catalyst-Engine-Apache/lib/Catalyst/Engine/Apache2/MP20.pm

Please bear it in mind that most of the information in this Pod is about
configuring your Catalyst app to run under mod_perl. I much prefer
fastcgi as it gives me much more control and awareness of machine
resources, keeps my permissions sane, and allows me to run multiple
different Catalyst applications and versions on the same box.


Ivor.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


emily at burnham

Sep 16, 2008, 9:41 AM

Post #5 of 7 (1436 views)
Permalink
RE: Switching to a production server [In reply to]

Thanks, I read your suggestions and opinions and am switching to fastcgi
with apache. I'd like to do this in steps:
1. Install FCGI::ProcManager
2. Run myapp_fastcgi.pl from the command line, just like myapp_server.pl
3. Then go through apache with mod_fastcgi.

I am on step 2, and I am thinking that I can't do that with that fastcgi
script like I can with myapp_server.pl. I need to combine 2 and 3?

E

> -----Original Message-----
> From: ivorw [mailto:m9tn-oh4c [at] xemaps]
> Sent: Wednesday, September 10, 2008 1:34 AM
> To: catalyst [at] lists
> Subject: Re: [Catalyst] Switching to a production server
>
> Emily Heureux wrote:
> >
> > Hi, I have been developing a Catalyst application and just using the
> > Catalyst myapp_server.pl script to run it. We server a very small
> > market, currently less than 100 visits a day. The major issue we are
> > having is that even small images are loaded very slowly, and therefore
> > the pages are loaded slowly, on the order of more than 5 seconds for a
> > first time visitor.
> >
> >
> >
> > At this time, I don't know anything about fast_cgi or configuring
> > apache or what have you, to work with Catalyst, but before I take that
> > on, my question is, is it likely that the slow loading of very small
> > images has to do with the default myapp_server.pl, and switching to
> > something else will make a big difference with loading images and
> > possibly other files?
> >
> >
> >
> I don't recommend going live by running myapp_server.pl - this is
> intended for development and debugging. I do recommend using a
> standalone fastcgi process farm (which could have just a single
> instance), talking through a named pipe in the /tmp directory. The
> fastcgi process runs in your application user account, saving you from
> having to open up the permissions of your files to the www-data user.
>
> This is quite well documented, see
> http://search.cpan.org/~mramberg/Catalyst-
> Runtime/lib/Catalyst/Engine/FastCGI.pm
>
> Also apart from in special circumstances, there's usually no reason to
> serve images through your Catalyst application. The special
> circumstances I imagine could be if the image is being stored in a
> database blob, or being tweaked on the fly with ImageMagick.
>
> One option could be to change the URLs for the images to be absolute
> ones on the webserver, rather than static/images/powered_by.jpg etc.
> which will deliver performance results with myapp_server.pl. You'd need
> to copy the root/static/images directory to somewhere more public, where
> the www-data user can see and use it. A recommended, documented option
> is to configure Apache to handle /static rather than pass these requests
> to the application with the following config snippet:
>
> <Location /static>
> SetHandler default-handler
> </Location>
>
>
> For more on configuring Apache 2.0, see
> http://search.cpan.org/~agrundma/Catalyst-Engine-
> Apache/lib/Catalyst/Engine/Apache2/MP20.pm
>
> Please bear it in mind that most of the information in this Pod is about
> configuring your Catalyst app to run under mod_perl. I much prefer
> fastcgi as it gives me much more control and awareness of machine
> resources, keeps my permissions sane, and allows me to run multiple
> different Catalyst applications and versions on the same box.
>
>
> Ivor.
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
> archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


m9tn-oh4c at xemaps

Sep 16, 2008, 12:42 PM

Post #6 of 7 (1434 views)
Permalink
Re: Switching to a production server [In reply to]

Emily Heureux wrote:
> Thanks, I read your suggestions and opinions and am switching to fastcgi
> with apache. I'd like to do this in steps:
> 1. Install FCGI::ProcManager
> 2. Run myapp_fastcgi.pl from the command line, just like myapp_server.pl
> 3. Then go through apache with mod_fastcgi.
>
> I am on step 2, and I am thinking that I can't do that with that fastcgi
> script like I can with myapp_server.pl. I need to combine 2 and 3?
>
> E
>
>
I would do 3 before 2. Configure Apache to be ready to handle a fastcgi
connection through a socket (from the docs):

FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/myapp.socket
Alias /myapp/ /tmp/myapp/myapp.fcgi/

# Or, run at the root
Alias / /tmp/myapp.fcgi/

# Optionally, rewrite the path when accessed without a trailing slash
RewriteRule ^/myapp$ myapp/ [R]


Now having reloaded or restarted Apache2, you should be in a position to
point a browser at the new application, and get a 500 error page. The
logs should be able to tell you whether your Apache configuration is
doing the right thing.

>From your application user account shell, now run

$ script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 2

or however many server processes you want to run.
>> -----Original Message-----
>> From: ivorw [mailto:m9tn-oh4c [at] xemaps]
>> Sent: Wednesday, September 10, 2008 1:34 AM
>> To: catalyst [at] lists
>> Subject: Re: [Catalyst] Switching to a production server
>>
>> Emily Heureux wrote:
>>
>>> Hi, I have been developing a Catalyst application and just using the
>>> Catalyst myapp_server.pl script to run it. We server a very small
>>> market, currently less than 100 visits a day. The major issue we are
>>> having is that even small images are loaded very slowly, and therefore
>>> the pages are loaded slowly, on the order of more than 5 seconds for a
>>> first time visitor.
>>>
>>>
>>>
>>> At this time, I don't know anything about fast_cgi or configuring
>>> apache or what have you, to work with Catalyst, but before I take that
>>> on, my question is, is it likely that the slow loading of very small
>>> images has to do with the default myapp_server.pl, and switching to
>>> something else will make a big difference with loading images and
>>> possibly other files?
>>>
>>>
>>>
>>>
>> I don't recommend going live by running myapp_server.pl - this is
>> intended for development and debugging. I do recommend using a
>> standalone fastcgi process farm (which could have just a single
>> instance), talking through a named pipe in the /tmp directory. The
>> fastcgi process runs in your application user account, saving you from
>> having to open up the permissions of your files to the www-data user.
>>
>> This is quite well documented, see
>> http://search.cpan.org/~mramberg/Catalyst-
>> Runtime/lib/Catalyst/Engine/FastCGI.pm
>>
>> Also apart from in special circumstances, there's usually no reason to
>> serve images through your Catalyst application. The special
>> circumstances I imagine could be if the image is being stored in a
>> database blob, or being tweaked on the fly with ImageMagick.
>>
>> One option could be to change the URLs for the images to be absolute
>> ones on the webserver, rather than static/images/powered_by.jpg etc.
>> which will deliver performance results with myapp_server.pl. You'd need
>> to copy the root/static/images directory to somewhere more public, where
>> the www-data user can see and use it. A recommended, documented option
>> is to configure Apache to handle /static rather than pass these requests
>> to the application with the following config snippet:
>>
>> <Location /static>
>> SetHandler default-handler
>> </Location>
>>
>>
>> For more on configuring Apache 2.0, see
>> http://search.cpan.org/~agrundma/Catalyst-Engine-
>> Apache/lib/Catalyst/Engine/Apache2/MP20.pm
>>
>> Please bear it in mind that most of the information in this Pod is about
>> configuring your Catalyst app to run under mod_perl. I much prefer
>> fastcgi as it gives me much more control and awareness of machine
>> resources, keeps my permissions sane, and allows me to run multiple
>> different Catalyst applications and versions on the same box.
>>
>>
>> Ivor.
>>
>> _______________________________________________
>> List: Catalyst [at] lists
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-
>> archive.com/catalyst [at] lists/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


kakimoto at tpg

Jul 15, 2009, 5:06 AM

Post #7 of 7 (969 views)
Permalink
Re: Switching to a production server [In reply to]

hello. Emily,

how is your catalyst app now? Is it running smoothly with FastCGI?

thanks

K. akimoto



Re: [Catalyst] Switching to a production server

ivorw
Tue, 16 Sep 2008 12:53:47 -0700

Emily Heureux wrote:
> Thanks, I read your suggestions and opinions and am switching to fastcgi
> with apache. I'd like to do this in steps:
> 1. Install FCGI::ProcManager
> 2. Run myapp_fastcgi.pl from the command line, just like myapp_server.pl
> 3. Then go through apache with mod_fastcgi.
>
> I am on step 2, and I am thinking that I can't do that with that fastcgi
> script like I can with myapp_server.pl. I need to combine 2 and 3?
>
> E
>
>
I would do 3 before 2. Configure Apache to be ready to handle a fastcgi
connection through a socket (from the docs):

FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/myapp.socket
Alias /myapp/ /tmp/myapp/myapp.fcgi/

# Or, run at the root
Alias / /tmp/myapp.fcgi/

# Optionally, rewrite the path when accessed without a trailing slash
RewriteRule ^/myapp$ myapp/ [R]


Now having reloaded or restarted Apache2, you should be in a position to
point a browser at the new application, and get a 500 error page. The
logs should be able to tell you whether your Apache configuration is
doing the right thing.


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.