Message-ID: <4188F0AC.10106@cs.msu.su>
Date: Wed, 03 Nov 2004 17:52:28 +0300
From: Alexey Borzov <borz_off@cs.msu.su>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: "Marc G. Fournier" <scrappy@postgresql.org>
Cc: pgsql-www@postgresql.org
Subject: Re: Inadequate hosting for www.postgresql.org
References: 
 <E7F85A1B5FF8D44C8A1AF6885BC9A0E4306F1E@ratbert.vale-housing.co.uk>
	<41878616.70705@cs.msu.su> <20041102114746.R33702@ganymede.hub.org>
	<4187E864.5000703@cs.msu.su>
	<20041102163552.X82047@ganymede.hub.org>
	<20041102164614.I82047@ganymede.hub.org>
	<Pine.GSO.4.61.0411030400030.24492@ra.sai.msu.su>
	<4188B48C.9050103@cs.msu.su>
	<20041103074944.W82047@ganymede.hub.org>
In-Reply-To: <20041103074944.W82047@ganymede.hub.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Marc G. Fournier wrote:
>> That's because these pages are dynamic, too. But I think it's an error 
>> in webperf that it considers them part of index page.
>>
>>>     This is a classical 3 servers setup and it described in many 
>>> books and
>>>     success stories.
>>
>>
>> Your suggestion is nice and all, but right now we are discussing the 
>> fact that we don't even have *one* dedicated server. Only a shared 
>> account on substandard  hardware, incapable of running PHP scripts. :(
> 
> This has yet to be proven, IMHO ... Dave has already stated that the old 
> build scripts aren't nearly as slow as yours, and it was having to deal 
> with PHP as well ...
> 
> Your first "complaint" was that it wasn't loading the files fast enough 
> ... so, I enabled mmcache on that server with shared memory use only, so 
> that it doesn't use disk except for the first load ... the build is 
> still atrociously slow ... the servers are all setup so that shared 
> memory is locked into physical RAM, so now what?  The RAM is too slow?

In case I was unclear before: due to some f**kup in server configuration 
(probably well below the PHP level) file access is EXTREMELY slow. And there 
*is* file access now due to templates and gettext, even if PHP scripts are cached.

If you look at profiling information at http://alexey.beta.postgresql.org/, 
you'll see that just reading files (loadedTemplate, loadedInnerTemplate, 
loadedIndexTemplate) takes 0.2--0.5 seconds. Initializing gettext (which relies 
on files, too) takes 0.1 seconds (setLanguage).

One also has to wonder whether there is another configuration f**kup that makes 
script connect to PostgreSQL for 0.1--0.5 seconds.

One *also* has to wonder what (if not server overload) makes these times 
fluctuate a lot.

A well tuned webserver on adequate hardware will generate the whole page of 
alexey.beta in less than 0.1 second.

Current build scripts DO NOT DO FILE ACCESS, that's why they work faster. But 
that's irrelevant, 'cause there are pages on new website that should be dynamic 
and thus will be accessed by visitors on the master server. Page generation 
times of ~2 seconds will make PostgreSQL project look BAD.

As for the nature of aforementioned configuration f**kups --- no idea. *You* are 
the admin.