Re: pgfoundry moved ...

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Cc: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, "Gavin M(dot) Roy" <gmr(at)ehpg(dot)net>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-www(at)postgresql(dot)org>
Subject: Re: pgfoundry moved ...
Date: 2005-04-29 20:11:17
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE6C73C6@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

>>>> Is't possible to understand what's an actual problem, database or
>>>> web part ? Is't possible to see timings for typical
>longest queries ?
>>>> Probably there is some profiling support which show timings for
>>>> each component used. If gbord would be Mason based
>>>> applications it could be
>>>> done very easy.
>>>
>>> We've spent time on that in the past, and nothing obvious
>is apparent,
>>> other than disk IO being slow in general. The same problem was
>>> seen when
>>> svr2 was on one of Marc's boxes. I'm fairly convinced it's a unionfs
>>> issue.
>>
>> In my experience, it's at least definitly not the db. Pages that have
>> nothing to do with the db has been equally slow. So I'm
>willing to buy
>> in with Daves guess.
>
>Ok, I think it's bad architecture. I already told Marc about that.
>It's very easy to separate processing binary static files like
>images from
>dynamic content. Just setup thttpd. Next step to setup
>frontend web server
>which should be very light with cacheing capability - we use
>mod_accel module
>for apache. It's frontentd which communicate with browser
>(probably slow link).

Um. You really aren't up to speed on how things are, are you? ;-) We
*do* use static frontends. Five of them actually, globally distributed.
This is not where the performance problem is.

>Backend, with PHP, mod_auth_pgsql should be use for page
>generation, it
>should communicate only with frontend. The main idea is that
>you need much
>less backends (plus postgres connection for each backend), so
>much lesser
>resources will be used. What's the problem to setup this ?

Nothing - though a slightly different method is used where the frontends
get their static content with rsync. But the main idea is the same.

Except the backend is slow *anyway* - even with just the
regen-for-frontend stuff loading it down. It doesn't show up for the end
user, but it does make the site rebuild slower, whjich means it has to
run less frequently (once/hour for the most often updated stuff, less
often for docs and ftp tree).

//Magnus

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Oleg Bartunov 2005-04-29 20:43:12 Re: pgfoundry moved ...
Previous Message Oleg Bartunov 2005-04-29 19:11:32 Re: pgfoundry moved ...