FAQ
I'm wondering if the following plugin I've written is misguided..
It enables proxy caches and browsers to better cache the files served
by Static::Simple..
However, I suppose in situations where that matters, you shouldn't be
serving files via Static::Simple..
And the regular Static::Simple still provides Last-Modified headers,
which do allow browsers to perform some caching.

What do you think?

To enable this plugin, you need:

use Catalyst qw(
...
Static::Simple
Static::Caching
);


-------------------------Caching.pm----------------------------------
package Catalyst::Plugin::Static::Caching;
use Moose::Role;
requires '_serve_static'; # From Catalyst::Plugin::Static::Simple

after _serve_static => sub {
my $c = shift;
# Avoid setting an expires if the parent never found the file..
return unless (defined $c->response->body
and ref($c->response->body) eq 'IO::File');

# Tell browsers they can cache files for a couple of hours:
$c->res->headers->expires(time() + 7200);
# Tell Firefox it's OK to cache, even over SSL:
$c->res->headers->header('Cache-control' => 'public');
};

1;

Search Discussions

  • Tomas Doran at Jan 31, 2011 at 8:03 am
    On 31 Jan 2011, at 07:17, Toby Corkindale wrote:

    <snip>
    However, I suppose in situations where that matters, you shouldn't be
    serving files via Static::Simple..
    And the regular Static::Simple still provides Last-Modified headers,
    which do allow browsers to perform some caching.

    What do you think?
    Pretty much that - Static::Simple is really meant for development
    only, and in such a situation, you really want to not serve cache
    headers, as you don't want things cached when you're developing.

    That said, this isn't the first time someone has suggested this
    recently, so maybe it's worth just adding as an option in
    Static::Simple directly (with suitable warnings about production use
    in the documentation).

    Cheers
    t0m
  • Toby Corkindale at Feb 1, 2011 at 2:17 am

    On 31 January 2011 19:04, Tomas Doran wrote:
    On 31 Jan 2011, at 07:17, Toby Corkindale wrote:
    <snip>
    However, I suppose in situations where that matters, you shouldn't be
    serving files via Static::Simple..
    And the regular Static::Simple still provides Last-Modified headers,
    which do allow browsers to perform some caching.

    What do you think?
    Pretty much that - Static::Simple is really meant for development only, and
    in such a situation, you really want to not serve cache headers, as you
    don't want things cached when you're developing.

    That said, this isn't the first time someone has suggested this recently, so
    maybe it's worth just adding as an option in Static::Simple directly (with
    suitable warnings about production use in the documentation).
    The case that I find having the headers enabled is as follows:

    Front end load-balancing proxies, talking to app servers running
    starman, running catalyst apps.
    If you use Static::Simple, this does make the pipeline configuration
    nice and simple.
    I like simplicity.
    If you enable caching on your static content, then your
    reverse-proxies at the front will cache things, and take the load of
    static content off Catalyst at the back.

    I'd like to see it as an option on Static::Simple; I could mod that
    and send a patch over if you liked?

    Toby
  • Tomas Doran at Feb 1, 2011 at 12:26 pm

    On 1 Feb 2011, at 02:17, Toby Corkindale wrote:
    The case that I find having the headers enabled is as follows:
    Yep, perfectly reasonable really.
    I'd like to see it as an option on Static::Simple; I could mod that
    and send a patch over if you liked?
    Sure, or just commit into a branch (you already have a commit bit,
    right)?

    Cheers
    t0m
  • Aristotle Pagaltzis at Feb 1, 2011 at 1:08 pm

    * Toby Corkindale [2011-02-01 03:25]:
    The case that I find having the headers enabled is as follows:

    Front end load-balancing proxies, talking to app servers
    running starman, running catalyst apps.
    If you use Static::Simple, this does make the pipeline
    configuration nice and simple.
    I like simplicity.
    If you enable caching on your static content, then your
    reverse-proxies at the front will cache things, and take the
    load of static content off Catalyst at the back.

    I'd like to see it as an option on Static::Simple; I could mod
    that and send a patch over if you liked?
    You may be interested in my setup:
    http://blogs.perl.org/users/aristotle/2011/01/some-nifty-things-you-can-do-with-catalyst-on-plack.html

    --
    *AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined wantarray]/e;chop;$_}
    &Just->another->Perl->hack;
    #Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Toby Corkindale at Feb 2, 2011 at 2:06 am

    On 2 February 2011 00:08, Aristotle Pagaltzis wrote:
    * Toby Corkindale [2011-02-01 03:25]:
    The case that I find having the headers enabled is as follows:

    Front end load-balancing proxies, talking to app servers
    running starman, running catalyst apps.
    If you use Static::Simple, this does make the pipeline
    configuration nice and simple.
    I like simplicity.
    If you enable caching on your static content, then your
    reverse-proxies at the front will cache things, and take the
    load of static content off Catalyst at the back.

    I'd like to see it as an option on Static::Simple; I could mod
    that and send a patch over if you liked?
    You may be interested in my setup:
    http://blogs.perl.org/users/aristotle/2011/01/some-nifty-things-you-can-do-with-catalyst-on-plack.html
    Thanks - that's a really good example setup.

    How do you find Plack at serving static files (via Middleware::Static
    / App::Static)? Compared to Static::Simple, and compared to native
    HTTPD. I guess it sits in between the two in terms of performance, but
    wondered how much of an improvement it was?

    I might have to borrow the bit about auto-extending expiry times for
    versioned static files :)

    cheers,
    Toby
  • Andrew Rodland at Feb 2, 2011 at 2:43 am

    On Tuesday, February 01, 2011 08:06:08 PM Toby Corkindale wrote:
    How do you find Plack at serving static files (via Middleware::Static
    / App::Static)? Compared to Static::Simple, and compared to native
    HTTPD. I guess it sits in between the two in terms of performance, but
    wondered how much of an improvement it was?
    All of them will give perfectly acceptable throughput -- even Static::Simple
    isn't *slow*. The real concern is that with Static::Simple or with
    Plack::App::File, you're tying up one of your webapp processes to serve the
    file -- and your webapp processes are usually fairly limited in number, and
    fairly memory-hungry (which prevents you from just making more). On the other
    hand, if you let the frontend httpd serve the file, the cost of serving a
    static file ranges from one lightweight httpd thread (for a threaded model) to
    nearly nothing at all (with an async model). Either way, it's not tying up a
    process that could be running Catalyst.

    If you're serving up a fairly small number of fairly small files, then this
    probably doesn't make any difference to you, but if you're serving a larger
    number of larger files (that will take several seconds or more to transfer)
    then you should probably be thinking about ways to do it outside of your
    webapp process.

    Andrew
  • Toby Corkindale at Feb 2, 2011 at 6:39 am

    On 2 February 2011 13:43, Andrew Rodland wrote:
    On Tuesday, February 01, 2011 08:06:08 PM Toby Corkindale wrote:
    How do you find Plack at serving static files (via Middleware::Static
    / App::Static)? Compared to Static::Simple, and compared to native
    HTTPD. I guess it sits in between the two in terms of performance, but
    wondered how much of an improvement it was?
    All of them will give perfectly acceptable throughput -- even Static::Simple
    isn't *slow*. The real concern is that with Static::Simple or with
    Plack::App::File, you're tying up one of your webapp processes to serve the
    file -- and your webapp processes are usually fairly limited in number, and
    fairly memory-hungry (which prevents you from just making more). On the other
    hand, if you let the frontend httpd serve the file, the cost of serving a
    static file ranges from one lightweight httpd thread (for a threaded model) to
    nearly nothing at all (with an async model). Either way, it's not tying up a
    process that could be running Catalyst.

    If you're serving up a fairly small number of fairly small files, then this
    probably doesn't make any difference to you, but if you're serving a larger
    number of larger files (that will take several seconds or more to transfer)
    then you should probably be thinking about ways to do it outside of your
    webapp process.
    Which neatly loops around to my original post! :D

    My suggestion being to continue to use Static::Simple, but with
    cache-related headers added so that the reverse-proxy in front of
    Starman will cache-and-serve them itself.

    It's simple, and IMHO, ends up as the fastest, most light-weight way
    to serve those static files too.

    -T

    --
    Turning and turning in the widening gyre
    The falcon cannot hear the falconer
    Things fall apart; the center cannot hold
    Mere anarchy is loosed upon the world
  • Aristotle Pagaltzis at Feb 2, 2011 at 8:20 am

    * Toby Corkindale [2011-02-02 07:50]:
    My suggestion being to continue to use Static::Simple, but with
    cache-related headers added so that the reverse-proxy in front
    of Starman will cache-and-serve them itself.
    Exactly. HTTP has great scaling features. There is no need to
    invent special-purpose mechanisms to achieve the same things.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 31, '11 at 7:17a
activeFeb 2, '11 at 8:20a
posts9
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase