[Systems] Discovery_One Was a.sl.o migration.

[Sascha Silbe]

On Wed, Nov 04, 2009 at 05:46:54PM -0600, David Farning wrote:

> The first step will be to add a Squid caching proxy in front of the
> PHP server.  It looks like we will be able to cache all of the images,
> html, JavaScript, and css files.  This will give us:
I'm not sure that'll work out as expected. See my mail 
<20091001212816.GB4941 at twin.sascha.silbe.org>:

>> activities.sugarlabs.org
>> ------------------------
>>
>> (Currently unreachable via IPv6)
>>
>> Does two redirections for start page (/ -> /en-US/ -> /en-US/sugar/), 
>> both times with caching disabled and probably incomplete Vary header 
>> (only gives Accept-Encoding, nothing language-related).
>> Remaining pages: Not cached when using default squid settings because 
>> LM is not given. Does not support IMS.

(LM=Last-Modified, IMS=If-Modified-Since)

> I _think_ that our current bottle neck is our Apache server.  Because
> we are running many services, we have several Apache mod_* enabled.
> This gives us heavy  Apache processes.
In theory, Linux is supposed to create COW (Copy-on-write) mappings on 
fork(), i.e. only memory that gets modified by the child process will be 
newly allocated.
How well that works in practice with Apache I don't know, but maybe 
bernie does.

> Because we are not using an caching proxy in front of Apache, all of 
> our static content is being handled by these processes.
Making static pages cachable is always a good idea, of course. :)

> Adding squid and removing the uneedded mod_* should increase overall
> system throughput.
Would (really) be curious to see actual measurements for the latter.

CU Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/private/systems/attachments/20091105/33ec2c2f/attachment.pgp