ezmlm-www-discuss

[ezmlm-www] scaling ezmlm-www 1.4x

[Glen S. <ro...@as...>]

The new mod_perl support in 1.4 seemed very interesting...but the script 
design doesn't seem to scale.  

Since I have 300 groups here, I had (several versions ago) decided to keep 
each config.pm file separate, so the system doesn't concurrently clobber the 
config.pm file when it (potentially) simultaneously updates or 
creates/deletes groups.

The problem with separate config.pm's, is that perperl (like mod_perl) gets 
confused about cached session variables, even when they come from the same 
script at different URLs.  So the messages listings for one group will appear 
when another is requested.

The only way I see to fix this is to load the list of groups into an array 
that specifies what the archive path is, driven by the index counter which is 
embedded in the URL.  This function is what a list of groups provides in the 
config.pm today.

Since the flat file is unsafe, it seems that a database is the faster and more 
scalable way to go.  I don't think performance from building the list 
dynamically from the filesystem would be adequate, unless all the values were 
static, except the group name/path.

Thoughts?


-- 
Associate.com - THE Place to Associate!                   http://associate.com
Is Your E-mail Group Here?   See http://associate.com/faq/your-group-here.html

Re: [ezmlm-www] scaling ezmlm-www 1.4x

[Alessandro R. <al...@pr...>]

On 16-11-2005 at 4:43, Glen Stewart wrote:

 >Since the flat file is unsafe, it seems that a database is the faster
 >and more scalable way to go.  I don't think performance from building
 >the list dynamically from the filesystem would be adequate, unless
 >all the values were static, except the group name/path.

One possibility is to dynamically load the group list from a database by
doing something like this in your config.pm:

use DBI;
use DBD::mysql;
my $dbh =3D DBI->connect(...);
my $sth =3D $dbh->prepare("SELECT * FROM groups");
$sth->execute;
while (my $group =3D $sth->fetchrow_hashref) {
    push @$lists, {
        name =3D> $group->{name},
        ...
    };
}

This is the main reason I chose to leave configuration in a Perl script
and not to move it to a text file.

Another more complicated but very efficient way would be to tie (see
perltie) the @$lists array, so that you just query your database for
information about the current request, without the need for loading the
full group list into memory:

package MyEzmlmConfig;
use DBI;
use DBD::mysql;
sub TIEARRAY {
    my $class =3D shift;
    my $dbh =3D> DBI->connect(...);
    return bless {
        STH =3D> $dbh->prepare("SELECT * FROM groups WHERE id =3D ?")
    }, $class;
}
sub FETCH {
    my $self =3D shift;
    $self->{STH}->execute(shift);
    my $group =3D $self->{STH}->fetchrow_hashref;
    return {
        name =3D> $group->{name},
        ...
    };
}

and then, in config.pm:
use MyEzmlmConfig;
tie @$lists, 'MyEzmlmConfig';

You could also do something similiar by writing a custom module named
'vpopmail' providing a vgetdomaindir() function which maps list name to
archive dir.

There are other thought about scaling ezmlm-www, but I'll leave them for
the future. Is all this of any interest?

  - alessandro ranellucci.
 =20