[Systems] pointing activities.sugarlabs.org at the proxy

Bernie Innocenti bernie at codewiz.org
Mon Nov 16 11:05:57 EST 2009


El lun, 16-11-2009 a las 02:27 -0600, David Farning escribió:

> Let's agree to disagree on this until we get the benchmarks in place.
> The knowledge I am gaining running reliable benchmarks is probably
> worth the effort.  If the the experiment fails, I will gladly throw it
> out.

Ok. This effort is certainly justified for the sake of science and
good-looking charts :)


> Ideally this will be the case.  Have you talked to Steve at RIT?
> Apparently they have an entire rack of blade servers sitting idle in
> the inovation center.

That would be amazing. I'll write him again.


> > Actually, I'd propose an opposite strategy: create MySQL replica slaves
> > on each aslo-web node to maximize throughput.
> 
> Eventually we are going to need both.  The downsides of depending on
> master slave databases for scalability is that:
> a. each db server caches that same hot data.  -  If we set up a
> master-slave combo each with 8GB of cache, the same 8GB of objects
> with be cached on each machine.  Memcached, while slower, shares the
> same cache across multiple php servers and db servers.

Hmmm.... it's "more data sharing" VS "more network traffic". Hard to
tell which one would perform better. I guess we could measure in both
configurations to find out what the impact really is.


> Currently,
> aslo is getting a ratio of about 90% reads to 10% writes.
> aslo-db is getting a cache hit rate of just below 90% with 4GB of
> memory and 3GB of dedicated innodb_cache.
> The entire database is about 70GB

Does it make sense to have the table cache bigger than the actual data
set? (the query cache may, indeed, need to be much bigger than the
dataset).


> Yes, I agree VMs incur an unavoidable cost in complexity, fragility,
> and overhead.  At our currently scale they are nothing more than a
> pain in the ass:(  Note--dfarning does not like using vms
> unnecessarily in production.
> 
> My goal is to learn to set up, learn to test, learn to benchmark, and
> learn to maintain aslo when it is spread across multiple physical
> machines.

I agree, this is a valuable goal even if it makes performance suffer
initially.


> > If you agree, I'll migrate also-db, aslo-web and aslo-proxy to their
> > partitions.
> 
> Yes, I think that would help significantly.

Ok then, I'll see if I could do it on the fly.


> yummmm.  I have been going to a different pizzeria every evening for a
> pizza and beer.  I'll take you up on that bet.

GRRR!!! You guys had way too much fun in Bolzano!

Make sure you write a great report to make the rest us even more
envious.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



More information about the Systems mailing list