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 <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418
pgpqnSTPwMHUJ.pgp
Description: PGP signature
_______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
