tag:blogger.com,1999:blog-768233104244702633.post3286869890190902065..comments2023-11-16T03:16:54.746-08:00Comments on The Scale-Out Blog: Benchmarking Tungsten Parallel ReplicationRobert Hodgeshttp://www.blogger.com/profile/05379726998057344092noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-768233104244702633.post-13153288933427512882011-11-01T09:50:02.962-07:002011-11-01T09:50:02.962-07:00@Marcus, the #1 thing for performance on the JDBC ...@Marcus, the #1 thing for performance on the JDBC driver is to get real support for statement batching at the network level in order to reduce the number of round trips. We have a prototype of this already implemented but have not profiled it very extensively yet. Otherwise JDBC batches end up doing a round trip for each statement, which our profiling indicates is a performance hit for cache-resident workloads.Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-16790772768122021442011-11-01T09:36:13.405-07:002011-11-01T09:36:13.405-07:00have you compared jdbc driver perf? im pretty sure...have you compared jdbc driver perf? im pretty sure there are lots of improvements i could do regarding garbage collection in drizzle-jdbcMarcus Erikssonhttps://www.blogger.com/profile/13317356508042328314noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-32110632172804889002011-10-31T15:31:21.862-07:002011-10-31T15:31:21.862-07:00@hingo, Good guess but I'm unable to find any ...@hingo, Good guess but I'm unable to find any evidence this is the case. Slave updates are unlogged. The mystery deepens!Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-77711584296381149292011-10-31T15:21:52.247-07:002011-10-31T15:21:52.247-07:00@Robert: But your slaves are writing a binlog too?...@Robert: But your slaves are writing a binlog too?hingohttps://www.blogger.com/profile/09201666166374161923noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-68232452413584032322011-10-31T15:06:47.807-07:002011-10-31T15:06:47.807-07:00@hingo, It also struck me as suspicious. On the o...@hingo, It also struck me as suspicious. On the other hand the graphs track slave apply position, which is decoupled from the master read position in both MySQL (it's the relay thread) and Tungsten (it's a couple stages up the replication pipeline, where we extract from the master). In both cases slaves can read from the master a lot faster than they can apply SQL, so delays on the master should not be visible. Hence my curiosity about the measurements. <br /><br />Happily the overall timings are not in doubt. Giuseppe uses a completely different way of counting the elapsed time and gets the same or even better results.Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-7912297974729331462011-10-31T14:56:41.639-07:002011-10-31T14:56:41.639-07:00Robert: good point about the binlog being 1GB. I t...Robert: good point about the binlog being 1GB. I think this is one of the issues in Domas' MySQL at Facebook talk (same talk that you sometimes hear being given by Mark too) that MySQL takes some global lock while rotating the binlogs. I might remember wrong, but it seems like a good guess at least.hingohttps://www.blogger.com/profile/09201666166374161923noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-27896142621269008712011-10-31T11:40:53.138-07:002011-10-31T11:40:53.138-07:00@Austin, ouch and thanks! The numbers are indeed ...@Austin, ouch and thanks! The numbers are indeed reversed. Should be fixed now.Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-45166298547752798762011-10-31T11:31:53.196-07:002011-10-31T11:31:53.196-07:00Hi Robert,
Are your table columns reversed for I/...Hi Robert,<br /><br />Are your table columns reversed for I/O bound numbers? Looks like it should be MySQL:228 and Tungsten:51 according to the graph. <br /><br />Cool article. We might get to a point of checking this out at Vimeo some day. It is good to see the numbers.<br /><br />AustinAustin Swinneyhttp://vimeo.comnoreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-2380849139787008382011-10-31T11:20:12.079-07:002011-10-31T11:20:12.079-07:00First of all you are all welcome!
@Baron, if you ...First of all you are all welcome!<br /><br />@Baron, if you mean the notches that are particularly prominent in the first graph I had assumed they correspond to checkpoints in InnoDB. However, as I recall from one of your Xaprb articles InnoDB does fuzzy checkpoints usually so you would not expect these stalls. <br /><br />It is interesting that both MySQL replication and Tungsten get the same behavior. Moreover if you multiply out the area under the graph it's about one GB, which is also the binlog size. So, perhaps there's something related to binlogs at work here. One possibility I need to check is that my algorithm for counting bytes somehow marks the progress incorrectly when the slave moves to transactions from the next binlog. <br /><br />Meanwhile the ugly blue line for Tungsten on the second graph is an artifact of the way Tungsten parallel replication marks progress. Overall progress is based on the oldest committed transaction is reported. This number may appear not to budge across several seconds when there are a lot of channels, because inactive channels do not update their position unless they receive a transaction. Tungsten generates fake transactions periodically to force updates on all channels, but it makes the graph very choppy and requires a trend line to sort out.Robert Hodgeshttps://www.blogger.com/profile/05379726998057344092noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-35742925377508941712011-10-31T11:01:06.183-07:002011-10-31T11:01:06.183-07:00Thank you for including the time-series graphs ins...Thank you for including the time-series graphs instead of just a single number. The spikes and notches are interesting. Have you tracked down the source of that? Is it due to MySQL, or Tungsten?Baronhttps://www.blogger.com/profile/01621441847303652718noreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-15438812406989757742011-10-31T09:48:37.382-07:002011-10-31T09:48:37.382-07:00Thanks for sharing the results, would definitely b...Thanks for sharing the results, would definitely be interesting to see round two of mysql native replication vs tungsten replicator but with SSD in place :)Georgehttp://vbtechsupport.comnoreply@blogger.comtag:blogger.com,1999:blog-768233104244702633.post-60513737241520583942011-10-31T09:12:34.602-07:002011-10-31T09:12:34.602-07:00It's really great to see Tungsten getting air ...It's really great to see Tungsten getting air time. Thanks for the effort and analysis!randyhttp://randymelder.com/noreply@blogger.com