Re: pgfoundry moved ... - Mailing list pgsql-www

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

I see that your static frontend has PHP compiled and other stuff.

curl -I http://pgfoundry.org/
HTTP/1.1 200 OK
Date: Fri, 29 Apr 2005 19:04:14 GMT
Server: Apache/1.3.33 (Unix) mod_auth_pgsql/0.9.12 PHP/4.3.11
X-Powered-By: PHP/4.3.11
Content-Type: text/html; charset=UTF-8

it's silly. All that stuff eat resources. Even old pentium would
serve a lot of *static* pages without problem, you don't need "globally distributed"
frontends.

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

Hmm, not very nice. I don't think pgfoundry is very busy site.
Is there some web stat available ? How many pages generated dynamically ?
Could you run simple ab benchmark ? Technology I described is simple, commonly
adopted and proven in rather busy sites (millions visitors per day).
Anyway, I just tried to help. Probably, you know more information why
services are so slow and has clever idea how to improve situation.


>
> //Magnus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq
>

     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