Emmanuel,
Both of assumptions you made are correct. I configured distributed
RAIDd-1, and benchmarking tool is at the URL you provided.
Regarding prepared statements, our application uses prepared
statements. When our application performed a task and it took few
minutes to do when going through Sequoia, and just few seconds going
directly to MySQL; That triggered our performance test to investigate
the issue.
Here is my group communications config:
=======================
<config>
<TCP start_port="7800"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
enable_bundling="true"/>
<!-- Using TCPPING instead. Need a dedicated gossip server otherwise. -->
<!--PING timeout="2000"
down_thread="false" up_thread="false" num_initial_members="3"/-->
<TCPPING
initial_hosts="10.10.10.10[7800],10.10.10.10.11[7800]"
port_range="5"
timeout="3000"
down_thread="false" up_thread="false" num_initial_members="3"/>
<MERGE2 max_interval="10000"
down_thread="false" up_thread="false" min_interval="5000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<!--VERIFY_SUSPECT timeout="1500" down_thread="false"/-->
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="100,200,300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<!-- UNICAST not needed for TCP -->
<!--UNICAST timeout="300,600,1200,2400,3600"
down_thread="false" up_thread="false"/-->
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<VIEW_SYNC avg_send_interval="60000" down_thread="false"
up_thread="false" />
<pbcast.GMS print_local_addr="true" join_timeout="5000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
handle_concurrent_startup="true" />
<SEQUENCER down_thread="false" up_thread="false" />
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<VERIFY_SUSPECT
timeout="1500"
down_thread="false"
up_thread="false"/>
<!-- FRAG2 frag_size="60000" down_thread="false" up_thread="true"/ -->
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/-->
</config>
======================
Thanks for clarification on the writes scale.
Huy
On Thu, Aug 28, 2008 at 2:56 PM, Emmanuel Cecchet <[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
