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 ...
|
Список | 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 по дате отправления: