Hi gaël,
A last thing to mention is that Sequoia mostly serializes writes which
will exhibit a significant slowdown on single-threaded benchmarks.
Performance scalability means that response time will remain constant
while load increases (and therefore throughput increases). If your
read/write ratio contains too many writes to a single table, this will
also hurt performance.
Keep us posted with your results, this looks very promising and instructive.
Emmanuel
Thank you for your reply. I will reconsider my architecture and make
the same tests with dedicated resources for each database. My goal is
to get an average response time during the execution of particular
repetitious requests scenarios.
Then I will compare obtained results with my two others architectures
which are MySQL cluster (NDB engine) and a Circular replication again
with MySQL 5.1.
I noticed significative difference with the two other architectures,
that's why I thought I made a mistake in the configuration, or I
forgot something important.
I'am conscious it will be difficult to draw precise conclusions with
such heterogeneous architectures, but I need to get an order of idea
to be able to select the best suitable architecture for my application.
Thank you for your advice.
gaël
On Thu, Jun 26, 2008 at 11:10 PM, Emmanuel Cecchet
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
gaël charrière wrote:
Actually the 2 backends are collocated on the same machine
with the controller precisely because I'm in testing mode. My
final goal is to compare the performance of different cluster
architecture without being impacted by some external noise.
My experience shows that such configuration has such a high
variance in performance measurements that it makes it impractical
to draw any useful conclusion.
With my sequoia architecture, as I explained, I still noticed
very slow responses, even if all my nodes are located on the
same machine. So I don't think it will be better through the
network... That's why I would like to improve it now before
involving myself into a much more complex architecture.
There is very little information going through the network and the
main cost is serialization of data, not the cost of sending on the
wires. So having dedicated resources for each database rather than
sharing resources (cpu, mem, and especially io) will make a
difference. Note that each database commit requires a flush to
disk so if you don't use different disks for each database,
performance will be horrendous.
What other architectures are you considering to compare Sequoia with?
Don't hesitate to let me know if your results are different from
my experience.
Emmanuel
On Thu, Jun 26, 2008 at 5:41 PM, Emmanuel Cecchet
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
wrote:
Hi Gael,
1 controller, 2 backends (MySQL 5.1) and 1 recovery
(MySQL 5.1)
You don't need group communication with a single
controller. The
performance might be altered by the way the group communication
handles loopback delivery.
I can start the controller and enable the backends. I
can also
access the cluster and perform some queries. Items
appeared on
the backends. Everything seems to work fine.
However, I noticed bad performances, especially for
insertion
queries. A simple insertion in a virtual database takes
about
0.500 s.
Does anybody already notice that kind of measures? I'm
looking
for a way to optimize these queries. I tried different
appia
configurations, but I wasn't able to find one which
correspond
to what I expected.
>From your config file it looks like the 2 backends are
collocated
on the same machine with the controller. This probably
defeats the
purpose of both performance scalability and availability, so I
don't know how relevant performance measurements on such
configuration could be. We usually use such config for testing
only (mostly functional) but not for performance.
Don't hesitate to keep us posted with your findings,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
