Re: pgfoundry moved ...

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pgfoundry moved ...
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C73C6@algol.sollentuna.se
обсуждение исходный текст
Ответ на pgfoundry moved ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: pgfoundry moved ...  (Oleg Bartunov <oleg@sai.msu.su>)
Список 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

В списке pgsql-www по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: pgfoundry moved ...
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: pgfoundry moved ...