[Catalyst] query once per session?

[Yuval Kogman]

On Fri, Apr 27, 2007 at 10:32:15 -0700, Michael Higgins wrote:

> Ah. Well, I got something working, I believe, using Cache::FileCache...
> which is marginally faster than retreieving it every time. Probably, I need
> a different cache method.

I recommend Cache::FastMmap. New versions of that module no longer
need the wrapped version I have on the CPAN
(Catalyst::Plugin::Cache::Backend::FastMmap or something like that,
don't use it ;-). I really need to upload one with a deprecation
notice) so it should be a drop-in replacement. This is shared by the
various webserver child processes and is supposed to be much more
efficient than Cache::FileCache.

Also make sure that you cache the most processed version of the data
structure that you can, and not a large object set (you might be
serializing the whole DBIC schema every time you cache if you're not
careful). If you're in doubt, use Data::Dumper to see what the
caching module will have to serialize and deserialize each time.
You can load the DBIx::Class::Serialize::Storable component if you
want to serialize row objects. Note that serializing resultsets is
probably meaningless since resultsets.

> It seems the most expensive part might be moving the data to the client.
> Maybe I could I speed that up somehow? 

look into mod_deflate if your server is apache, or similar
solutions. I think there is even a Catalyst plugin to do that.

> Or, I think you mentioned just coding it into a javascript and having that
> load into the page when requested. I like this idea. This data can persist
> for a while. I could have a link to explicitly refresh the list, no? This is
> for internal use, basically. Clients have this number hard-coded in their
> session.

If you make a catalyst URI that pretends to be a static, cachable
file then you can attach a Last-Modified header, and respect the
client's If-Modified-Since header, giving a not modified response
instead of the page content.

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25

> My javascript-fu is non-existing, but I've done things I didn't know how to
> do before, albeit with mixed results... Since I'm a one-man department, any
> highly-recommended free resources folks could point to for honing one's
> javascript-fu would be helpful. ;-)

I would look into a lightweight js/ajax toolkit like jquery to load
the JSON feed, and Catalyst::View::JSON to serialize the data feed.

You can also try Jemplate to write the widget in Template Toolkit,
and then run it on the server as a fallback in case the client
doesn't support javascript. Jemplate compiles TT templates into
javascript, and what you do is simply provide the same TT params as
you would the template in the JSON feed.

The combination of this with serverside caching and payload
compression should take care of the performance issues. If it
doesn't then I suggest thinking the design over so that the whole
data set doesn't have to be accessible at all times.

Good luck!

-- 
  Yuval Kogman <nothingmuch at woobling.org>
http://nothingmuch.woobling.org  0xEBD27418

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20070427/ab9a9e70/attachment.pgp