On Fri, 29 Apr 2005, Magnus Hagander wrote:
>>> 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).
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 ?
>
> //Magnus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
