On 3 Jul 2008, at 12:57, Oleg Pronin wrote:

DBIx::Class::Cursor::Cached is too slow for production use. It caches only data from DB making it impossible so store virtual data in objects and after fetching data from cache it has to construct a row object which is a expensive action for CPU, running all the 'inflate_result', and possibly other hard tasks.

When you use DBIC::C::C - it slows down the request by 2 times (based on local CPU usage - not DB).

With solution i posted, request is 3-4x faster than original for local CPU.

2008/7/3 Andreas Pronakis <[EMAIL PROTECTED]>:
I was wondering if anyone has tried using the module DBIx::Class::Cursor::Cached but replacing the cache engine Cache::FileCache with Memcache?

I will try it out and let you know the results, but if someone else has already tried it would be nice to know what their findings were

Andreas


--- On Wed, 6/25/08, Oleg Pronin <[EMAIL PROTECTED]> wrote:

> From: Oleg Pronin <[EMAIL PROTECTED]>
> Subject: Re: [Dbix-class] DBIx::Class and caching
> To: [EMAIL PROTECTED], "DBIx::Class user and developer list" <[email protected] >
> Date: Wednesday, June 25, 2008, 9:23 AM
> These approach caches ready objects, not just a data from
> database, so it
> quite fast, and lets you to cache any data with object,
> even not from DB.


Please don't spread FUD.

Yes you can't store virtual data with Cursor::Cached, but then I'd argue that you shouldn't be doing that anyway.

And no it doesn't have to construct a row object if you don't want to See <http://search.cpan.org/~ash/DBIx-Class-0.08010/lib/DBIx/Class/ResultClass/HashRefInflator.pm > . Yes object construction can be expensive, but its what you want most of the time. If you dont want objects don't use an ORM. (The 'O' there stands for Object, dontcha know.)

Which solution? Link to archives please.
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]

Reply via email to