Mostly thinking out loud here... but we welcome feedback if we're off track...<div><br></div><div>Okay, after some perl -D:NTYProf <a href="http://tester.pl">tester.pl</a> with 200 iterations:<div>70% of the time is taken up in five modules:</div>
<div>1) SQL::Abstract</div><div>2) DBIx::Class::ResultSet</div><div>3) Class::Accessor::Grouped</div><div>4) DBIx::Class::Storage::DBI</div><div>5) HTML::FormHandler::Field</div><div>...because in 200 iterations they were called millions of times each. (The form requested has several select/option menus.)<br>
<div><br></div><div>Most of the data won't change rapidly -- e.g. client lists, countries, employees just to populate a few popup menus -- so it seems like an opportunity to benefit from caching the results, and only invalidating the cache when a new record gets updated/deleted/added. Whole tables could be cached without having to return to SQL/DBIC for every form-screen.</div>
<div><br></div><div>So we're looking for documentation on a best-of-breed approach for doing this in a Catalyst environment...</div><br>Looking at Catalyst::TraitFor::Model::DBIC::Schema::Caching it looks like you specify when the cache will expire:</div>
<div><font class="Apple-style-span" face="'courier new', monospace"> $c->model('DB::Table')->search({ foo => 'bar' }, { cache_for => 18000 });</font></div><div>whereas we would prefer being able to invalidate-cache-for-table-XYZ-now.</div>
<div><br>Aha, DBIx::Class::Cursor::Cached does include a<br><font class="Apple-style-span" face="'courier new', monospace"> $rs->cursor->clear_cache;</font></div><div>method, we'll be tinkering with that, next!<br>
<div><div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Apr 12, 2011 at 8:14 AM, will trillich <span dir="ltr"><<a href="mailto:will.trillich@serensoft.com">will.trillich@serensoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks for the tips, Peter -- and for <a href="http://dragonstaff.blogspot.com/2009/05/testing-with-perl-catalyst.html" target="_blank">http://dragonstaff.blogspot.com/2009/05/testing-with-perl-catalyst.html</a>! Got some cranking to do...<div>
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Tue, Apr 12, 2011 at 2:30 AM, Peter Edwards <span dir="ltr"><<a href="mailto:peter@dragonstaff.co.uk" target="_blank">peter@dragonstaff.co.uk</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
<div class="gmail_quote"><div>On 12 April 2011 02:53, will trillich <span dir="ltr"><<a href="mailto:will.trillich@serensoft.com" target="_blank">will.trillich@serensoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks -- this may be more of a FormHandler question than a Catalyst question but I thought I'd check here to see if it's just us:<div><br></div><div>We've been using HTML::FormHandler and are basically happy with it... until the performance issue mentioned below hit us. Any Catalystas running into 50-second turnaround time with H:FH?<br clear="all">
<br></div><div><div><font face="'courier new', monospace">[info] Request took 51.956100s (0.019/s)</font></div><div><font face="'courier new', monospace">.------------------------------------------------------------+-----------.</font></div>
<div><font face="'courier new', monospace">| Action | Time |</font></div><div><font face="'courier new', monospace">+------------------------------------------------------------+-----------+</font></div>
<div><font face="'courier new', monospace">| /auto | 0.000181s |</font></div><div><font face="'courier new', monospace">| /auth | 0.001857s |</font></div>
<div><font face="'courier new', monospace">| /ticket/base | 0.004652s |</font></div><div><font face="'courier new', monospace">| /ticket/item | 0.005865s |</font></div>
<div><font face="'courier new', monospace">| /ticket/edit | 51.88091s |</font></div><div><font face="'courier new', monospace">| Base:EDIT | 51.88050s |</font></div>
<div><font face="'courier new', monospace">| get FORM | 0.000078s </font><span style="font-family:'courier new', monospace">|</span></div>
<div><span style="font-family:'courier new', monospace;background-color:rgb(255, 255, 153)">| process FORM | <b>51.87286s</b> |</span></div>
<div><span style="font-family:'courier new', monospace">| /end | 0.000290s |</span></div><div><font face="'courier new', monospace">'------------------------------------------------------------+-----------'</font></div>
</div><div><br></div><div>Turnaround time ranges from 6 seconds to 50+ seconds, with no discernable pattern to the delay. (We can edit the same record multiple times and get wildly differing lags.)</div><div><br></div><div>
<br></div></blockquote></div><div>Run your test server with perl -d:NYTProf <a href="http://myapp.pl" target="_blank">myapp.pl</a> and see which routines use the time <a href="http://search.cpan.org/perldoc?Devel::NYTProf" target="_blank">http://search.cpan.org/perldoc?Devel::NYTProf</a> .</div>
<div>Maybe it is blocking on DNS network lookups.</div><div>Or if the time isused around the database calls, run with DBIC_TRACE=1 perl <a href="http://myapp.pl" target="_blank">myapp.pl</a> and watch and see which are the slow ones, then run your database query optimiser like EXPLAIN SELECT foo; <a href="http://dev.mysql.com/doc/refman/5.0/en/explain.html" target="_blank">http://dev.mysql.com/doc/refman/5.0/en/explain.html</a> <a href="http://www.postgresql.org/docs/8.3/static/sql-explain.html" target="_blank">http://www.postgresql.org/docs/8.3/static/sql-explain.html</a> </div>
<div>Are other processes/users accessing the same database? If so check for lock competition. Also disk space.</div><div><br></div><div>Regards, Peter</div><div><br></div><div> </div></div>
<br></div></div>_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk" target="_blank">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>11 cheers for binary!<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>11 cheers for binary!<br>
</div></div></div></div>