>>>> 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
