perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Chudov <ichu...@gmail.com>
Subject Re: Ways to scale a mod_perl site
Date Wed, 16 Sep 2009 16:20:31 GMT
On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters <mpeters@plusthree.com>wrote:

> On 09/16/2009 11:49 AM, Igor Chudov wrote:
>
>  1) Use a load balancer like perlbal (I am already doing that)
>>
>
> A load balancer is good but so are proxies. If you can separate your
> application server from the server that servers static content then you'll
> get a boost even if they are on the same machine.
>

I have very little static content. Even images are generated. My site
generates images of math formulae such as (x-1)/(x+1) on the fly.,


>
>  2) Separate a MySQL database server from webservers.
>>
>
> This is probably the first and easiest thing you should do.
>
>
 agreed

 3) Being enabled by item 2, add more webservers and balancers
>> 4) Create a separate database for cookie data (Apache::Session objects)
>> ??? -- not sure if good idea --
>>
>
> I've never seen the need to do that. In fact, I would suggest you drop
> sessions altogether if you can. If you need any per-session information then
> put it in a cookie. If you need this information to be tamper-proof then you
> can create a hash of the cookie's data that you store as part of the cookie.
> If you can reduce the # of times that each request needs to actually hit the
> database you'll have big wins.
>

I use sessions to keep users logged on. So the cookie is just an ID, and the
sessions table stores data such as authenticated userid.

I will double check, however, whether I give people sessions even if they
are not logged in.

Or maybe I can give them a cookie that will say "I am not logged in, do not
bother looking up my session".

Hm


>  5) Use a separate database handle for readonly database requests
>> (SELECT), as opposed to INSERTS and UPDATEs. Use replication to access
>> multiple slave servers for read only data, and only access the master
>> for INSERT and UPDATE and DELETE.
>>
>
> Reducing DB usage is more important than this. Also, before you go down
> that road you should look at adding a caching layer to your application
> (memcached is a popular choice).
>
>
It is not going to be that helpful due to dynamic content. (which is my
site's advantage). But this may be useful for other applications.

i

Mime
View raw message