Perl, singletons, DAOs oh my!

Lately I have been toying with Wicket , Hibernate and Spring for potentially writing a large complex site. Contrary to what people say about Java web development it isn't so bad, at least with Wicket. Since toying with Hibernate and DAOs, I came to the conclusion this can work really well in Catalyst!

Instead of micromanaging what to page cache, just cache the specific area that is the performance penalty: the database.

By utilizing the singleton data access object (DAO) pattern I can avoid the headache of micromanaging what gets page cached on my site. Furthermore, this pattern gives me the flexibility to still keep the dynamism of Template Toolkit and whatever code gets executed in my controller action.

This also solves my problem of exporting incrementally with DBIx::Class::Schema::Loader without over writing whatever business logic I might of added to my classes. This pretty much keeps my controllers clean of business logic. This pattern forces me to have clean separated code.

Lets get down the the beef of how to get this all setup.

Lets begin by setting up our first(?) DAO class

package DB::DAO::SupportedServiceDao;

# this class is a singleton!
  
  use base 'Class::Singleton';

use Cache::Memory;

# on first initiation setup the DAO's cache
  sub _new_instance {
      my $class = shift;
      my $self  = bless { }, $class;

$self->{cache} = Cache::Memory->new( namespace => 'dao',  default_expires => '600 sec' );

return $self;
  }

# a method we will call in our controller 
  # which will handle retrieving/caching data transparently for us in the controller
  
  sub get_service_by_type {
      my ($self,$rs,$type) = @_;

my $persist_key = 'SERVICE_BY_TYPE_' . $type;

my $result;
      unless($result = $self->{cache}->get($persist_key)) {
         $self->{cache}->set($persist_key,[$rs->search({type => $type},undef)->all()]);
         $result = $self->{cache}->get($persist_key);
      }

return $result;
  }
  
  sub save {
    my($self,$object) = @_;
    
    # just purge all data, though we can fine grain the caching here.
    
    $self->{cache}->clear;

# save in eval scope so we don't throw any errors
    # return undefined if insert/update failed else return the object
    
    eval { $object->insert_or_update(); }
    $@ ? return undef : return $object;
  }

Now here is our controller which utilizes are simple DAO.

So what do you think? makes sense? keeps the controllers nice and simple, without any business logic.

And time to test the performance of the implementation vs the page cache

PageCache run:

Requests per second: 97.30 [#/sec] (mean)
Time per request: 1027.70 [ms] (mean)
Time per request: 10.28 [ms] (mean, across all concurrent requests)

DAO run:

Requests per second: 66.05 [#/sec] (mean)
Time per request: 1514.10 [ms] (mean)
Time per request: 15.14 [ms] (mean, across all concurrent requests)

So it is a bit slower, well 31% slower to be exact. This is more than adequate performance for a relatively high traffic site.

Name
Email
Website
Body
Verification

May 2008
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Lets Get Dugg!

Perl, singletons, DAOs oh my!

Leave a Reply

Calendar

May 2008

Categories

Categories

Archives

Archives

Links

Links

Syndicate

Syndicate

Meta

Meta