>> 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
I was talking about www.postgresql.org, not pgfoundry.org. I realise the
subject still says pgfoundry, but the discussion was more along the
performance of www.postgresql.org at this stage..
>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.
As long as it's not used, it hardly makes a difference. Anyway, we need
the distribution mainly for redundancy, not performance.
>> 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.
Again, we're discussing differen things.
As for pgfoundry, yes, it seems to put a very high load on the systems,
but I can't talk abuot any details there, since I don't know them. I'm
sure there are many different ways to solve those issues.
//Magnus
