Hi,
Let's assume you have configure Sequoia with a distributed RAIDb-1
configuration.
JDBCBench is an 'update intensive benchmark' as described at
http://mmmysql.sourceforge.net/performance/.
As writes have to be executed serially and synchronously in RAIDb-1 (you
have to wait for both controllers to execute the query before returning
the result to the client), writes will always be slower than on a single
database. It is like RAID-1 for disks, it only speedups reads not writes.
Let's assume you used the code that can be found at
http://developer.mimer.com/features/JDBCprogs/JDBCBench.java
The benchmark does not do real transactions but execute all requests in
autocommit. Each pseudo-transaction consists of:
UPDATE
SELECT with resultset parsing
UPDATE
UPDATE
INSERT
You currently obtain a throughput of 2.5tps which means 10 writes/second
and 2.5 reads&parsing/second (since the time is measured on the client
side). Also note that the benchmark does not use prepared statements
which forces statements to be re-created on each query.
MySQL achieves 400tps which means 1600writes/second +
400read&parsing/second. Therefore the average execution time on MySQL is
2.5ms.
As you are running everything on the same machine (controller, database
and recovery database) and let's assume that your group communication is
properly setup, the overhead of Sequoia per request is about 77.5ms. If
you use the same physical database for the recovery log and your
database, you will use 2 disk flushes (actually each autocommit has to
be flushed to disk) and local communications through the loopback
interface have to be configured properly to make sure they are fast.
Given how this benchmark is written, it is hard to conclude anything
since it mixes read and write requests in autocommit. One thing for sure
is that a properly configured Sequoia controller will add at least 4ms
of overhead per query and more if not optimally configured.
Also there will never be any benefit using Sequoia with a sequential
(single threaded) benchmark since there is no load to balance (Sequoia
does not do intra-query parallelism).
I hope this will clarify some points and help people understand what
they should look at and what they are really benchmarking. If you want
to scale writes, Sequoia or any multi-master replication architecture is
not the solution.
Thanks for your interest in Sequoia,
Emmanuel
I am trying to use Sequoia with MySQL backends, and I experiencing
major performance issue. I have browsed the archive of this mailing
list for everything from current date back to July 2007. I saw a
couple of threads on performance issue, but none of those help me
resolve the issue I have. So I have post this message hoping someone
can help. Here is my configuration
MySQL 5.0.51a
Ubuntu 8.0.5
CPU: 2.6 GHz
Memory: 1.7GB
Sun JDK 1.6.0_06
Server A: Controller-1, backend-db-1, recovery-db-1
Server B: Controller-2, backend-db-2, recovery-db-2.
I use jgroup with TCP for cluster communications.
When running JDBCBench via Sequoia driver with 1000 txn and single
client thread, I got 2.5 TPS.
When running JDBCBench using MySQL JDBC driver connecting directly to
any of the two backend DB with 1000 txn and single client thread, I
got over 400 TPS.
--
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
