ScaleArc Performance Benchmarking with sysbench

Size: px
Start display at page:

Download "ScaleArc Performance Benchmarking with sysbench"

Transcription

1 MySQL Performance Blog ScaleArc Performance Benchmarking with sysbench Peter Boros, 2014

2 1/31 Author: Peter Boros Revision: 2.0 Date: Mar 28, 2014 Customer: ScaleArc Contents 1 Executive Summary 3 2 About ScaleArc for MySQL 5 3 Benchmarking setup Client machines Database machines MySQL configuration ScaleArc software appliances Network 7 4 Measurements TTL-based caching Read-only Sysbench throughput Sysbench response time CPU utilization Effects of caching on read-only workload Sysbench throughput Sysbench response time CPU utilization Read-write Sysbench throughput Sysbench response time CPU utilization Effects of caching on read-write workload Sysbench throughput Sysbench response time CPU utilization 30

3 2/31 5 Conclusion 31

4 1 Executive Summary 3/31 1 Executive Summary ScaleArc hired Percona to perform various test on its database traffic management product. This document is the outcome of the benchmarks carried out by Uday Sawant (ScaleArc) and Peter Boros (Percona). The goal of these benchmarks is to identify the potential overhead of the ScaleArc software itself and the potential benefits of caching. The benchmarks were carried out with the trunk version of sysbench. For this reason, we used a very small set of data, so the measurements will be fast, and it's known that caching has huge benefits when the queries themselves are rather expensive. We decided that we would rather show that benefit with a real-world application, which is coming later is this series. In this summary graph it's visible that in terms of throughput (read-only benchmark, which is relevant for read mostly applications), ScaleArc doesn't have any significant overhead, while caching can have potentially huge benefits.

5 1 Executive Summary 4/31 The situation is pretty similar with response times. ScaleArc doesn't add any significant overhead, and caching can mean huge benefit in terms of response time as well. In case of this particular workload (which is read only sysbench), using caching means a roughly 3x increase in throughput and a roughly 80% drop in response time. Overall, ScaleArc is a good product in terms of performance and features as well. I would definitely recommend it.

6 2 About ScaleArc for MySQL 5/31 2 About ScaleArc for MySQL ScaleArc for MySQL is a software appliance that drops in transparently between applications and databases to improve application availability and performance. It requires no changes to applications or databases and delivers: Instant scale up - transparent connection pooling and multiplexing, TTL-based transparent caching, surge protection Transparent scale out - read/write split, load balancing, query routing, sharding Automatic high availability - automatic failover Real-time actionable analytics 3 Benchmarking setup 3.1 Client machines The client machines are running the benchmarking software like sysbench in case of these benchmarks. CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G We used 2 clients. The results of the 2 clients are graphed separately, so it's visible that they put the same amount of workload on the database or ScaleArc software. 3.2 Database machines CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G Running MySQL Community Edition

7 2 About ScaleArc for MySQL 6/ MySQL configuration [mysqld] max_allowed_packet = 64M thread_cache = 256 query_cache_size = 0 query_cache_type = 0 max_connections = max_user_connections = max_connect_errors = wait_timeout = interactive_timeout = log-error=/var/lib/mysql/mysql.err back_log=60000 innodb_buffer_pool_size = 3G innodb_additional_mem_pool_size = 16M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_open_files = 2000 innodb_file_per_table innodb_log_file_size=2g innodb_log_files_in_group=2 innodb_purge_threads=1 innodb_max_purge_lag=0 innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1 innodb_buffer_pool_instances=8 sql_mode=no_engine_substitution,strict_trans_tables The buffer pool of the database is intentionally small, so it's easy to generate a disk-bound workload. Please note that the following settings are not recommended in production. innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1 We used these settings to drive the node to its peak performance, avoiding any possible overhead which might be required on a production system. In typical production settings, these are not set, and binary logging is enabled, which potentially reduces ScaleArc's overhead further.

8 3.3 ScaleArc software appliances 7/ ScaleArc software appliances CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G The machines were running ScaleArc for MySQL Network The machines were connected using 10G connections.

9 4 Measurements 8/31 4 Measurements All of the measurements were done with a very small database that completely fits in memory. --oltp-table-size= oltp-tables-count=64 In these benchmarks, we expected both the database and ScaleArc to be CPU bound. In case of a disk-bound workload, ScaleArc would shine even more than in this benchmark. If the queries are more expensive (they have to hit storage), the overhead in % is smaller, and in case of caching the query-by-query benefit is bigger. We measured 3 different setups, both on read-only and read-write cases. These are the following. Direct connection to the database. Connection to the database through ScaleArc, where ScaleArc only acts as a pass-through filter (since it's a load balancer that speaks the MySQL wire protocol, all the mechanics for that are still in place). Please note that this setup doesn't make sense in real life. The purpose of this setup is to show the potential overhead of using ScaleArc and uncovering potential limitations of the ScaleArc software itself. In a more realistic case in this configuration ScaleArc would load balance between multiple servers. Connection to database through ScaleArc, where ScaleArc is allowed to cache. Caching in ScaleArc is TTL (Time To Live)-based caching, meaning that a read query's results are cached in ScaleArc. If that read query is seen again before expiring, the query is not run again on the database server but rather served from the cache. Once the timer for the cached query expires, the query will be issued on the database again. Caching of course only works for reads, which are not in an explicit transaction (autocommit is on and no START TRANSACTION is issued). Because of that, we used --oltp-skip-trx during cached benchmarks (read-only case). In case of these benchmarks, the TTL was 1 hour, because we wanted to saturate the ScaleArc software while serving cached queries. An 1 hour TTL might be unrealistic for some applications, while for other applications even an 1 day TTL is something they can live with for some queries. TTL can be as low as 1 second and as high as 199 days. In this case, we wanted to measure the cache's performance, so we wanted the queries to be cached during the entire benchmark run to show the potential gain even in case of very small queries. 4.1 TTL-based caching It's important to note that the cache's expiration is controlled by a TTL value - there is no other invalidation, so it's possible to read stale data when the query results is changed, but the cache is not expired. Reading stale data alone is ok for most applications, it can happen with a regular, asynchronous slave if it's lagging behind the master (and it always lagging behind somewhat). Otherwise, the cache is pretty similar to MySQL's query cache, which doesn't suffer from the stale read problem, but it has a coarse invalidation (if a table is written, the cache entries belonging to the given table are flushed). While the cache is flushed, the query cache mutex is held, which blocks reads even. Because of the mutex, the built-in query cache is a very usual performance bottleneck. ScaleArc's cache doesn't suffer from this. It's important to note that ScaleArc caches nothing by default. Also, there are other ways to invlidate cache entries apart from waiting for the TTL to expire.

10 4 Measurements 9/31 API Call based invalidation (you can clear the cache for an entire query pattern rule with one API call) Query comment based invalidation (you can put a comment /wipe/ before a query and wipe and refresh the cache) Cache Bypass (you can send a comment /nocache/ and bypass the cache for that specific query)

11 4.2 Read-only 10/ Read-only Sysbench throughput In the lower region of threads (up to 32), we see that the TPS value significantly drops in case of going through ScaleArc. That's nothing to be surprised about, the reason for that is network roundtrips. Because ScaleArc is a software appliance, it adds a hop between the database and the application, which introduces latency. If the number of threads is higher (32 and up), this starts to matter less and less, and performance is almost identical which is very impressive. It means that around the optimal degree of parallelism for these machines, ScaleArc introduces very little (barely measurable) overhead.

12 4.2 Read-only 11/ Sysbench response time This graph contains the response times belonging to the previous benchmarks. This is really hard to read because at 4096 threads, the system is overloaded, and the response time is much more than in the maximum throughput region. Because it's multiple orders of magnitude higher, the interesting response times are not readable from this graph.

13 4.2 Read-only 12/31 The following graph is the same as above, except that the y axis is limited to 250 ms, so the region which is not visible on the graph above is visible here. What we see there regarding the overhead is pretty much the same as we saw in case of the throughput graph, which means that ScaleArc by itself introduces immeasurably low latency (which explains the difference in cases when parallelism is low). Usually applications which are utilizing the database server are using significantly more than one thread (in MySQL a single query always uses a single thread, in other words there is no intra-query parallelism). The latency from 32 threads above is actually somewhat lower when going through ScaleArc (the exact tipping point can be different here based on the number of CPUs). The reason for that is ScaleArc itself uses an event loop to connect to MySQL, so at a high concurrency, and can schedule sending the traffic to MySQL differently. This only matters when otherwise the MySQL server is saturated CPU-wise.

14 4.2 Read-only 13/ CPU utilization Last but not least, this graph contains the CPU utilization of the different setups. The left-hand side shows the CPU utilization when connecting directly to the database, and the right-hand side shows connecting through ScaleArc. In both cases, the database server's CPU is the bottleneck. It's visible that the client node's CPU is more than 75% idle (only client1 is graphed to improve readability, client2 is practically the same). From 32 threads and up, the blue bar (CPU user%) is relatively high on the database servers, as is the green (CPU sys%). From 64 threads, the idle time is practically 0, until the systems are overloaded. On the right hand side, we can see that ScaleArc at this load still had 50% idle CPU, which means that we could practically do the same benchmark on another set of boxes through the very same ScaleArc, and only then it will be fully utilized. We are talking about 3000 sysbench tps here. One more interesting thing to note is the relatively high system time of ibd. This is also because of the way ScaleArc connects to the database (see the previous paragraph).

15 4.2 Read-only 14/31 [ 17s] threads: 64, tps: , reads/s: , writes/s: 0.00, response time: 35.22ms (95%) These threads are from a single client, which means that ScaleArc could keep up with parsing roughly statements / second with utilizing half of its CPU, which is impressive. Please note that the ScaleArc software in this case was tuned towards this type of workload, which means we had more query processing threads. In case of caching, we will have more cache handler threads.

16 4.3 Effects of caching on read-only workload 15/ Effects of caching on read-only workload Sysbench throughput The next set of graphs will compare the cases when cache is used and not used. The preceding TPS graph contains reads / second (because we measured with --oltp-skip-trx), so roughly reads corresponds to roughly 3000 transactions in the earlier setup (14 reads in a transaction). On the left-hand side of the graph, the cached throughput is visible with green - on the right-hand side, the non-cached throughput is visible with red (direct access) and blue (access through ScaleArc as a pass-through filter). It's visible that caching improves the speed drastically, but when ScaleArc becomes overloaded (8192 client threads, 4096 from each client), the performance becomes somewhat

17 4.3 Effects of caching on read-only workload 16/31 inconsistent, which is understandable considering how few cores ScaleArc was running on. On the graph, the dots are translucent, which means the colors are brighter in the areas that have more samples. Even in the overloaded case, the majority of the samples are in the region of 100k+ reads / second across two clients, which means that the performance degrades very gracefully even under heavy load.

18 4.3 Effects of caching on read-only workload 17/ Sysbench response time Like in the case of a non-cached workload, the response times are not too readable because of the very high response times when the systems are overloaded. But from the overloaded response times visible, it seems like using caching doesn't make response times worse.

19 4.3 Effects of caching on read-only workload 18/31

20 4.3 Effects of caching on read-only workload 19/31 Like in the case of non-cached workload, this graph is the zoomed version of the previous one. Here the maximum of the y axis is 100 ms. From this graph, it's visible that at lower concurrency and at the optimal throughput, caching actually helps response time. This is understandable, since in case of a cache hit, ScaleArc can serve the results, and the client (in our case here sysbench) doesn't have to go to the database, so a roundtrip and database processing time is spared. It's also worth mentioning that the data "comes from memory," it doesn't matter if we hit the ScaleArc cache of the database. When the ScaleArc cache is used, the response time is lower because the additional roundtrip to the database and potential database work (like parsing SQL) is avoided. This means that caching can have benefits even if the database fits in the buffer pool. The improvement is always subject to the workload - caching helps the most when it can cache relatively expensive queries like aggregations and queries hitting the storage.

21 4.3 Effects of caching on read-only workload 20/ CPU utilization Similarly to the previous case, the preceding graph shows CPU utilization of the various components. In case of the cached workload, the client itself is much more utilized (since it gets responses sooner, it has to generate the traffic faster). With this kind of workload, when using only one client, we would hit the client's CPU as the performance bottleneck. The database is interesting too. With caching, its CPU is barely used. This is because if a query is served from the cache, it never gets to the database, so the database's CPU utilization will be lower. In other words, using the cache helps to offload the database. If offloading is visible on ScaleArc's graphs, when caching is used, the CPU on the server hosting ScaleArc is much more utilized. For this benchmark, the ScaleArc software was tuned to handle a cached workload, which means more cache handler threads.

22 4.4 Read-write 21/ Read-write For read-write benchmarks, we had to create oltp_nontran.lua, which is the same sysbench benchmark as oltp.lua, except that it does the reads outside of the transaction and does only the writes in transaction, so caching can have an effect on read. The rest of the benchmarking setup is the same as the read-only case. In this benchmark, we did not utilize ScaleArc's read-write split feature, which could make the results better if we used multiple database servers Sysbench throughput Similarly to the read-only case, at a low concurrency, the overhead of ScaleArc is coming from the additional network roundtrip. At the optimal concurrency, the overhead is barely measurable (the dots are

23 4.4 Read-write 22/31 plotted practically on top of each other).

24 4.4 Read-write 23/ Sysbench response time

25 4.4 Read-write 24/31 The case is pretty similar with the response times as in the read-only case. Similarly, the second graph is a zoomed version of the first one, which a 250 ms maximum.

26 4.4 Read-write 25/ CPU utilization The CPU utilization graph shows that in this case, the database server's CPU is the bottleneck. What is interesting is that ScaleArc is using less CPU than in the read-only case. This is understandable, since a transaction now contains writes as well, which are expensive on the database side, but they are still just statements to route on the ScaleArc side.

27 4.5 Effects of caching on read-write workload 26/ Effects of caching on read-write workload Measuring caching here is interesting because the workload is no longer read-only of mostly reads. We have a very significant amount of writes. [ 16s] threads: 64, tps: , reads/s: , writes/s: , response time: 45.20ms (95%) For 30k reads, we get 8,5k writes. It's expected that caching won't help as much as in the previous case, because writes can't be cached and while they are in process, the benchmarking threads can't proceed with reads. Please note that this means that roughly 25% of the traffic is write, a typical application scaling out with additional slaves for reads doesn't have this kind of read-to-write ratio.

28 4.5 Effects of caching on read-write workload 27/ Sysbench throughput The first graph shows that in terms of total throughput, caching still helps.

29 4.5 Effects of caching on read-write workload 28/ Sysbench response time

30 4.5 Effects of caching on read-write workload 29/31 Similarly to the read-only case, caching also helps response time, because it reduces the time needed for the read part of the workload.

31 4.5 Effects of caching on read-write workload 30/ CPU utilization

32 5 Conclusion 31/31 This test really stresses the database server's CPU when not caching. With caching on, similarly to the read-only case, the client's workload increases somewhat (but not as much), and the database server's CPU usage decreases significantly. In the last row, the CPU utilization of ScaleArc shows that although it's somewhat higher with caching, it's still not that much higher. From these tests it's visible that caching can still be beneficial even if the write ratio is as high as in this test. 5 Conclusion Engineering is always about making the right tradeoffs. If one wants features that needs a protocol-level load balancer like ScaleArc, the price should be paid in the overhead of Layer 7 parsing and decision making. ScaleArc's engineering team did a great job minimizing this overhead. ScaleArc itself is very well tunable for different workload types (if caching is important, ScaleArc can be tuned for caching - if query rewriting, ScaleArc can be tuned for that).

MySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona

MySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona MySQL Performance Optimization and Troubleshooting with PMM Peter Zaitsev, CEO, Percona In the Presentation Practical approach to deal with some of the common MySQL Issues 2 Assumptions You re looking

More information

MySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona Percona Technical Webinars 9 May 2018

MySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona Percona Technical Webinars 9 May 2018 MySQL Performance Optimization and Troubleshooting with PMM Peter Zaitsev, CEO, Percona Percona Technical Webinars 9 May 2018 Few words about Percona Monitoring and Management (PMM) 100% Free, Open Source

More information

MySQL Database Scalability

MySQL Database Scalability MySQL Database Scalability Nextcloud Conference 2016 TU Berlin Oli Sennhauser Senior MySQL Consultant at FromDual GmbH oli.sennhauser@fromdual.com 1 / 14 About FromDual GmbH Support Consulting remote-dba

More information

Performance Test Results for ScaleArc for MySQL on Aurora RDS Nov ScaleArc. All Rights Reserved. 1

Performance Test Results for ScaleArc for MySQL on Aurora RDS Nov ScaleArc. All Rights Reserved. 1 Performance Test Results for ScaleArc for MySQL on Aurora RDS Nov 2016 2016 ScaleArc. All Rights Reserved. 1 ScaleArc for MySQL Aurora RDS Testing ScaleArc has updated its ScaleArc for MySQL database load

More information

InnoDB Scalability Limits. Peter Zaitsev, Vadim Tkachenko Percona Inc MySQL Users Conference 2008 April 14-17, 2008

InnoDB Scalability Limits. Peter Zaitsev, Vadim Tkachenko Percona Inc MySQL Users Conference 2008 April 14-17, 2008 InnoDB Scalability Limits Peter Zaitsev, Vadim Tkachenko Percona Inc MySQL Users Conference 2008 April 14-17, 2008 -2- Who are the Speakers? Founders of Percona Inc MySQL Performance and Scaling consulting

More information

Performance improvements in MySQL 5.5

Performance improvements in MySQL 5.5 Performance improvements in MySQL 5.5 Percona Live Feb 16, 2011 San Francisco, CA By Peter Zaitsev Percona Inc -2- Performance and Scalability Talk about Performance, Scalability, Diagnostics in MySQL

More information

How to Fulfill the Potential of InnoDB's Performance and Scalability

How to Fulfill the Potential of InnoDB's Performance and Scalability How to Fulfill the Potential of InnoDB's Performance and Scalability MySQL Conference & Expo 21 Yasufumi Kinoshita Senior Performance Engineer Percona Inc. MySQLPerformanceBlog.com -2- About me... http://mysqlperformanceblog.com

More information

Scaling Without Sharding. Baron Schwartz Percona Inc Surge 2010

Scaling Without Sharding. Baron Schwartz Percona Inc Surge 2010 Scaling Without Sharding Baron Schwartz Percona Inc Surge 2010 Web Scale!!!! http://www.xtranormal.com/watch/6995033/ A Sharding Thought Experiment 64 shards per proxy [1] 1 TB of data storage per node

More information

Improvements in MySQL 5.5 and 5.6. Peter Zaitsev Percona Live NYC May 26,2011

Improvements in MySQL 5.5 and 5.6. Peter Zaitsev Percona Live NYC May 26,2011 Improvements in MySQL 5.5 and 5.6 Peter Zaitsev Percona Live NYC May 26,2011 State of MySQL 5.5 and 5.6 MySQL 5.5 Released as GA December 2011 Percona Server 5.5 released in April 2011 Proven to be rather

More information

Innodb Performance Optimization

Innodb Performance Optimization Innodb Performance Optimization Most important practices Peter Zaitsev CEO Percona Technical Webinars December 20 th, 2017 1 About this Presentation Innodb Architecture and Performance Optimization 3h

More information

What s New in MySQL 5.7 Geir Høydalsvik, Sr. Director, MySQL Engineering. Copyright 2015, Oracle and/or its affiliates. All rights reserved.

What s New in MySQL 5.7 Geir Høydalsvik, Sr. Director, MySQL Engineering. Copyright 2015, Oracle and/or its affiliates. All rights reserved. What s New in MySQL 5.7 Geir Høydalsvik, Sr. Director, MySQL Engineering Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes

More information

What's new in MySQL 5.5? Performance/Scale Unleashed

What's new in MySQL 5.5? Performance/Scale Unleashed What's new in MySQL 5.5? Performance/Scale Unleashed Mikael Ronström Senior MySQL Architect The preceding is intended to outline our general product direction. It is intended for

More information

Solid State Disk Benchmarking

Solid State Disk Benchmarking Solid State Disk Benchmarking Matt Yonkovit Senior Consultant, MySQL AB This document shows performance benchmark tests using a 32GB Mtron MSP Solid State Disk Drive in a Linux Environment. The focus of

More information

PhxSQL: A High-Availability & Strong-Consistency MySQL Cluster. Ming

PhxSQL: A High-Availability & Strong-Consistency MySQL Cluster. Ming PhxSQL: A High-Availability & Strong-Consistency MySQL Cluster Ming CHEN@WeChat Why PhxSQL Highly expected features for MySql cluster Availability and consistency in MySQL cluster Master-slaves replication

More information

Choosing Hardware and Operating Systems for MySQL. Apr 15, 2009 O'Reilly MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc

Choosing Hardware and Operating Systems for MySQL. Apr 15, 2009 O'Reilly MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc Choosing Hardware and Operating Systems for MySQL Apr 15, 2009 O'Reilly MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc -2- We will speak about Choosing Hardware Choosing Operating

More information

Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan

Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan Agenda OLTP status quo Goal System environments Tuning and optimization MySQL Server results Percona Server

More information

MySQL 8.0 Performance: InnoDB Re-Design

MySQL 8.0 Performance: InnoDB Re-Design MySQL 8.0 Performance: InnoDB Re-Design Insert Picture Here Dimitri KRAVTCHUK MySQL Performance Architect @Oracle Copyright 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection

More information

The Role of Database Aware Flash Technologies in Accelerating Mission- Critical Databases

The Role of Database Aware Flash Technologies in Accelerating Mission- Critical Databases The Role of Database Aware Flash Technologies in Accelerating Mission- Critical Databases Gurmeet Goindi Principal Product Manager Oracle Flash Memory Summit 2013 Santa Clara, CA 1 Agenda Relational Database

More information

Technology Overview ScaleArc. All Rights Reserved.

Technology Overview ScaleArc. All Rights Reserved. 2014 ScaleArc. All Rights Reserved. Contents Contents...1 ScaleArc Overview...1 Who ScaleArc Helps...2 Historical Database Challenges...3 Use Cases and Projects...5 Sample ScaleArc Customers...5 Summary

More information

Optimizing MySQL Configuration

Optimizing MySQL Configuration Optimizing MySQL Configuration 10 November,2016 Peter Zaitsev CEO, Percona Agenda MySQL Configuration Tuning Basics What s new with MySQL Looking at Most Important Options 2 Things to Know About MySQL

More information

Architectural Differences nc. DRAM devices are accessed with a multiplexed address scheme. Each unit of data is accessed by first selecting its row ad

Architectural Differences nc. DRAM devices are accessed with a multiplexed address scheme. Each unit of data is accessed by first selecting its row ad nc. Application Note AN1801 Rev. 0.2, 11/2003 Performance Differences between MPC8240 and the Tsi106 Host Bridge Top Changwatchai Roy Jenevein risc10@email.sps.mot.com CPD Applications This paper discusses

More information

InnoDB: Status, Architecture, and Latest Enhancements

InnoDB: Status, Architecture, and Latest Enhancements InnoDB: Status, Architecture, and Latest Enhancements O'Reilly MySQL Conference, April 14, 2011 Inaam Rana, Oracle John Russell, Oracle Bios Inaam Rana (InnoDB / MySQL / Oracle) Crash recovery speedup

More information

ScaleArc for SQL Server

ScaleArc for SQL Server Solution Brief ScaleArc for SQL Server Overview Organizations around the world depend on SQL Server for their revenuegenerating, customer-facing applications, running their most business-critical operations

More information

RocksDB Key-Value Store Optimized For Flash

RocksDB Key-Value Store Optimized For Flash RocksDB Key-Value Store Optimized For Flash Siying Dong Software Engineer, Database Engineering Team @ Facebook April 20, 2016 Agenda 1 What is RocksDB? 2 RocksDB Design 3 Other Features What is RocksDB?

More information

OPTIMIZING MYSQL SERVER ON SUN X64 SERVERS AND STORAGE. Luojia Chen, ISV Engineering. Sun BluePrints Online February 2008

OPTIMIZING MYSQL SERVER ON SUN X64 SERVERS AND STORAGE. Luojia Chen, ISV Engineering. Sun BluePrints Online February 2008 OPTIMIZING MYSQL SERVER ON SUN X64 SERVERS AND STORAGE Luojia Chen, ISV Engineering Sun BluePrints Online February 2008 Part No 820-4498-10 Revision 1.0, 2/20/08 Edition: February 2008 Sun Microsystems,

More information

Everything You Need to Know About MySQL Group Replication

Everything You Need to Know About MySQL Group Replication Everything You Need to Know About MySQL Group Replication Luís Soares (luis.soares@oracle.com) Principal Software Engineer, MySQL Replication Lead Copyright 2017, Oracle and/or its affiliates. All rights

More information

Practical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 20 th, 2016 Percona Technical Webinars

Practical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 20 th, 2016 Percona Technical Webinars Practical MySQL Performance Optimization Peter Zaitsev, CEO, Percona July 20 th, 2016 Percona Technical Webinars In This Presentation We ll Look at how to approach Performance Optimization Discuss Practical

More information

MySQL High Availability

MySQL High Availability MySQL High Availability And other stuff worth talking about Peter Zaitsev CEO Moscow MySQL Users Group Meetup July 11 th, 2017 1 Few Words about Percona 2 Percona s Purpose To Champion Unbiased Open Source

More information

Best Practices. Deploying Optim Performance Manager in large scale environments. IBM Optim Performance Manager Extended Edition V4.1.0.

Best Practices. Deploying Optim Performance Manager in large scale environments. IBM Optim Performance Manager Extended Edition V4.1.0. IBM Optim Performance Manager Extended Edition V4.1.0.1 Best Practices Deploying Optim Performance Manager in large scale environments Ute Baumbach (bmb@de.ibm.com) Optim Performance Manager Development

More information

Optimizing MySQL Configuration. Peter Zaitsev,CEO Technical Webinars Series March 2012

Optimizing MySQL Configuration. Peter Zaitsev,CEO Technical Webinars Series March 2012 Optimizing MySQL Configuration Peter Zaitsev,CEO Technical Webinars Series March 2012 Agenda MySQL Configuration Tuning Basics Tools to Configure MySQL Looking at Most Important Options Things to know

More information

How To Rock with MyRocks. Vadim Tkachenko CTO, Percona Webinar, Jan

How To Rock with MyRocks. Vadim Tkachenko CTO, Percona Webinar, Jan How To Rock with MyRocks Vadim Tkachenko CTO, Percona Webinar, Jan-16 2019 Agenda MyRocks intro and internals MyRocks limitations Benchmarks: When to choose MyRocks over InnoDB Tuning for the best results

More information

MySQL Performance Improvements

MySQL Performance Improvements Taking Advantage of MySQL Performance Improvements Baron Schwartz, Percona Inc. Introduction About Me (Baron Schwartz) Author of High Performance MySQL 2 nd Edition Creator of Maatkit, innotop, and so

More information

Switching to Innodb from MyISAM. Matt Yonkovit Percona

Switching to Innodb from MyISAM. Matt Yonkovit Percona Switching to Innodb from MyISAM Matt Yonkovit Percona -2- DIAMOND SPONSORSHIPS THANK YOU TO OUR DIAMOND SPONSORS www.percona.com -3- Who We Are Who I am Matt Yonkovit Principal Architect Veteran of MySQL/SUN/Percona

More information

Improving overall Robinhood performance for use on large-scale deployments Colin Faber

Improving overall Robinhood performance for use on large-scale deployments Colin Faber Improving overall Robinhood performance for use on large-scale deployments Colin Faber 2017 Seagate Technology LLC 1 WHAT IS ROBINHOOD? Robinhood is a versatile policy engine

More information

Replication features of 2011

Replication features of 2011 FOSDEM 2012 Replication features of 2011 What they were How to get them How to use them Sergey Petrunya MariaDB MySQL Replication in 2011: overview Notable events, chronologically: MySQL 5.5 GA (Dec 2010)

More information

Optimizing MySQL Configuration. Peter Zaitsev,CEO OSCON 2012, Portland,OR July 20, 2012

Optimizing MySQL Configuration. Peter Zaitsev,CEO OSCON 2012, Portland,OR July 20, 2012 Optimizing MySQL Configuration Peter Zaitsev,CEO OSCON 2012, Portland,OR July 20, 2012 Agenda Approach to getting great MySQL Configuration Types of Configuration Options Tools to Configure MySQL Looking

More information

Innodb Architecture and Performance Optimization

Innodb Architecture and Performance Optimization Innodb Architecture and Performance Optimization MySQL 5.7 Edition Peter Zaitsev April 8, 206 Why Together? 2 Advanced Performance Optimization Needs Architecture Knowledge 2 Right Level 3 Focus on Details

More information

System Characteristics

System Characteristics System Characteristics Performance is influenced by characteristics of the system hosting the database server, for example: - Disk input/output (I/O) speed. - Amount of memory available. - Processor speed.

More information

Highly Available Database Architectures in AWS. Santa Clara, California April 23th 25th, 2018 Mike Benshoof, Technical Account Manager, Percona

Highly Available Database Architectures in AWS. Santa Clara, California April 23th 25th, 2018 Mike Benshoof, Technical Account Manager, Percona Highly Available Database Architectures in AWS Santa Clara, California April 23th 25th, 2018 Mike Benshoof, Technical Account Manager, Percona Hello, Percona Live Attendees! What this talk is meant to

More information

To Shard or Not to Shard That is the question! Peter Zaitsev April 21, 2016

To Shard or Not to Shard That is the question! Peter Zaitsev April 21, 2016 To Shard or Not to Shard That is the question! Peter Zaitsev April 21, 2016 Story Let s start with the story 2 First things to decide Before you decide how to shard you d best understand whether or not

More information

Multiprocessor System. Multiprocessor Systems. Bus Based UMA. Types of Multiprocessors (MPs) Cache Consistency. Bus Based UMA. Chapter 8, 8.

Multiprocessor System. Multiprocessor Systems. Bus Based UMA. Types of Multiprocessors (MPs) Cache Consistency. Bus Based UMA. Chapter 8, 8. Multiprocessor System Multiprocessor Systems Chapter 8, 8.1 We will look at shared-memory multiprocessors More than one processor sharing the same memory A single CPU can only go so fast Use more than

More information

A Fast and High Throughput SQL Query System for Big Data

A Fast and High Throughput SQL Query System for Big Data A Fast and High Throughput SQL Query System for Big Data Feng Zhu, Jie Liu, and Lijie Xu Technology Center of Software Engineering, Institute of Software, Chinese Academy of Sciences, Beijing, China 100190

More information

Massive Scalability With InterSystems IRIS Data Platform

Massive Scalability With InterSystems IRIS Data Platform Massive Scalability With InterSystems IRIS Data Platform Introduction Faced with the enormous and ever-growing amounts of data being generated in the world today, software architects need to pay special

More information

XtraDB 5.7: Key Performance Algorithms. Laurynas Biveinis Alexey Stroganov Percona

XtraDB 5.7: Key Performance Algorithms. Laurynas Biveinis Alexey Stroganov Percona XtraDB 5.7: Key Performance Algorithms Laurynas Biveinis Alexey Stroganov Percona firstname.lastname@percona.com XtraDB 5.7 Key Performance Algorithms Focus on the buffer pool, flushing, the doublewrite

More information

Hive Metadata Caching Proposal

Hive Metadata Caching Proposal Hive Metadata Caching Proposal Why Metastore Cache During Hive 2 benchmark, we find Hive metastore operation take a lot of time and thus slow down Hive compilation. In some extreme case, it takes much

More information

Multiprocessor Systems. COMP s1

Multiprocessor Systems. COMP s1 Multiprocessor Systems 1 Multiprocessor System We will look at shared-memory multiprocessors More than one processor sharing the same memory A single CPU can only go so fast Use more than one CPU to improve

More information

Evaluation of Chelsio Terminator 6 (T6) Unified Wire Adapter iscsi Offload

Evaluation of Chelsio Terminator 6 (T6) Unified Wire Adapter iscsi Offload November 2017 Evaluation of Chelsio Terminator 6 (T6) Unified Wire Adapter iscsi Offload Initiator and target iscsi offload improve performance and reduce processor utilization. Executive Summary The Chelsio

More information

Multiprocessor Systems. Chapter 8, 8.1

Multiprocessor Systems. Chapter 8, 8.1 Multiprocessor Systems Chapter 8, 8.1 1 Learning Outcomes An understanding of the structure and limits of multiprocessor hardware. An appreciation of approaches to operating system support for multiprocessor

More information

Innodb Architecture and Performance Optimization. Peter Zaitsev, CEO Percona 25 September 2017

Innodb Architecture and Performance Optimization. Peter Zaitsev, CEO Percona 25 September 2017 Innodb Architecture and Performance Optimization Peter Zaitsev, CEO Percona 25 September 2017 Why Together? Advanced Performance Optimization Needs Architecture Knowledge 2 Right Level Focus on Details

More information

PolarDB. Cloud Native Alibaba. Lixun Peng Inaam Rana Alibaba Cloud Team

PolarDB. Cloud Native Alibaba. Lixun Peng Inaam Rana Alibaba Cloud Team PolarDB Cloud Native DB @ Alibaba Lixun Peng Inaam Rana Alibaba Cloud Team Agenda Context Architecture Internals HA Context PolarDB is a cloud native DB offering Based on MySQL-5.6 Uses shared storage

More information

Exadata X3 in action: Measuring Smart Scan efficiency with AWR. Franck Pachot Senior Consultant

Exadata X3 in action: Measuring Smart Scan efficiency with AWR. Franck Pachot Senior Consultant Exadata X3 in action: Measuring Smart Scan efficiency with AWR Franck Pachot Senior Consultant 16 March 2013 1 Exadata X3 in action: Measuring Smart Scan efficiency with AWR Exadata comes with new statistics

More information

Bottleneck Hunters: How Schooner increased MySQL throughput by more than 800% Jeremy Cole

Bottleneck Hunters: How Schooner increased MySQL throughput by more than 800% Jeremy Cole Bottleneck Hunters: How Schooner increased MySQL throughput by more than 800% Jeremy Cole On the genesis of Schooner: Hardware is massively under-utilized I/O has long

More information

Practical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 02, 2015 Percona Technical Webinars

Practical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 02, 2015 Percona Technical Webinars Practical MySQL Performance Optimization Peter Zaitsev, CEO, Percona July 02, 2015 Percona Technical Webinars In This Presentation We ll Look at how to approach Performance Optimization Discuss Practical

More information

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University of California, Berkeley Operating Systems Principles

More information

Deploying MySQL in Production Daniel Kowalewski Senior Technical Operations Engineer, Percona

Deploying MySQL in Production Daniel Kowalewski Senior Technical Operations Engineer, Percona Deploying MySQL in Production Daniel Kowalewski Senior Technical Operations Engineer, Percona daniel.kowalewski@percona.com 1 Deploying MySQL in Production Installation Configuration (OS and MySQL) Backups

More information

IX: A Protected Dataplane Operating System for High Throughput and Low Latency

IX: A Protected Dataplane Operating System for High Throughput and Low Latency IX: A Protected Dataplane Operating System for High Throughput and Low Latency Belay, A. et al. Proc. of the 11th USENIX Symp. on OSDI, pp. 49-65, 2014. Reviewed by Chun-Yu and Xinghao Li Summary In this

More information

Which technology to choose in AWS?

Which technology to choose in AWS? Which technology to choose in AWS? RDS / Aurora / Roll-your-own April 17, 2018 Daniel Kowalewski Senior Technical Operations Engineer Percona 1 2017 Percona AWS MySQL options RDS for MySQL Aurora MySQL

More information

Handlersocket. Ryan Lowe Percona Live London 2011

Handlersocket. Ryan Lowe Percona Live London 2011 Handlersocket Ryan Lowe Percona Live London 2011 Agenda What is Handlersocket mysqlds vs libhsclient How much does it save? How is it used? When can it be used? Other nosql alternatives for MySQL What

More information

Aerospike Scales with Google Cloud Platform

Aerospike Scales with Google Cloud Platform Aerospike Scales with Google Cloud Platform PERFORMANCE TEST SHOW AEROSPIKE SCALES ON GOOGLE CLOUD Aerospike is an In-Memory NoSQL database and a fast Key Value Store commonly used for caching and by real-time

More information

Using PostgreSQL in Tantan - From 0 to 350bn rows in 2 years

Using PostgreSQL in Tantan - From 0 to 350bn rows in 2 years Using PostgreSQL in Tantan - From 0 to 350bn rows in 2 years Victor Blomqvist vb@viblo.se Tantan ( 探探 ) December 2, PGConf Asia 2016 in Tokyo tantanapp.com 1 Sweden - Tantan - Tokyo 10 Million 11 Million

More information

A Brief Introduction of TiDB. Dongxu (Edward) Huang CTO, PingCAP

A Brief Introduction of TiDB. Dongxu (Edward) Huang CTO, PingCAP A Brief Introduction of TiDB Dongxu (Edward) Huang CTO, PingCAP About me Dongxu (Edward) Huang, Cofounder & CTO of PingCAP PingCAP, based in Beijing, China. Infrastructure software engineer, open source

More information

Accelerate Applications Using EqualLogic Arrays with directcache

Accelerate Applications Using EqualLogic Arrays with directcache Accelerate Applications Using EqualLogic Arrays with directcache Abstract This paper demonstrates how combining Fusion iomemory products with directcache software in host servers significantly improves

More information

Deploying MySQL in Production

Deploying MySQL in Production Deploying MySQL in Production Daniel Kowalewski (Percona) Senior Technical Operations Engineer daniel.kowalewski@percona.com @dankow Deploying MySQL in Production Installation Configuration (OS and MySQL)

More information

Scaling App Engine Applications. Justin Haugh, Guido van Rossum May 10, 2011

Scaling App Engine Applications. Justin Haugh, Guido van Rossum May 10, 2011 Scaling App Engine Applications Justin Haugh, Guido van Rossum May 10, 2011 First things first Justin Haugh Software Engineer Systems Infrastructure jhaugh@google.com Guido Van Rossum Software Engineer

More information

Migrating To MySQL The Live Database Upgrade Guide

Migrating To MySQL The Live Database Upgrade Guide Migrating To MySQL 5.7 - The Live Database Upgrade Guide October 4, 2016 Krzysztof Książek Severalnines krzysztof@severalnines.com 1 Agenda! Why upgrading to MySQL 5.7?! Preparing an upgrade - changes

More information

Optimizing MySQL Configuration. Peter Zaitsev,CEO Percona Live, Washington DC 11 January 2012

Optimizing MySQL Configuration. Peter Zaitsev,CEO Percona Live, Washington DC 11 January 2012 Optimizing MySQL Configuration Peter Zaitsev,CEO Percona Live, Washington DC 11 January 2012 Agenda Approach to getting great MySQL Configuration Types of Configuration Options Tools to Configure MySQL

More information

Real World Web Scalability. Ask Bjørn Hansen Develooper LLC

Real World Web Scalability. Ask Bjørn Hansen Develooper LLC Real World Web Scalability Ask Bjørn Hansen Develooper LLC Hello. 28 brilliant methods to make your website keep working past $goal requests/transactions/sales per second/hour/day Requiring minimal extra

More information

NetApp AFF A300 Review

NetApp AFF A300 Review StorageReview StorageReview takes an in-depth look at features, and performance of NetApp AFF A300 storage array. 1395 Crossman Ave Sunnyvale, CA 94089 United States Table of Contents INTRODUCTION... 3-5

More information

FuxiSort. Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc

FuxiSort. Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc Fuxi Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc {jiamang.wang, yongjun.wyj, hua.caihua, zhipeng.tzp, zhiqiang.lv,

More information

MySQL Performance Tuning 101

MySQL Performance Tuning 101 MySQL Performance Tuning 101 Hands-on-Lab Mirko Ortensi Senior Support Engineer MySQL Support @ Oracle October 3, 2017 Copyright 2017, Oracle and/or its affiliates. All rights reserved. Safe Harbor Statement

More information

MySQL Replication. Rick Golba and Stephane Combaudon April 15, 2015

MySQL Replication. Rick Golba and Stephane Combaudon April 15, 2015 MySQL Replication Rick Golba and Stephane Combaudon April 15, 2015 Agenda What is, and what is not, MySQL Replication Replication Use Cases Types of replication Replication lag Replication errors Replication

More information

Accelerating OLTP performance with NVMe SSDs

Accelerating OLTP performance with NVMe SSDs Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan Memory Solutions Lab. Samsung Semiconductor, Inc. 9/01/2016 Version 3.0 Page 1 Table of Contents 1. Introduction...

More information

Percona XtraDB Cluster

Percona XtraDB Cluster Percona XtraDB Cluster Ensure High Availability Presenter Karthik P R CEO Mydbops www.mydbops.com info@mydbops.com Mydbops Mydbops is into MySQL/MongoDB Support and Consulting. It is founded by experts

More information

MySQL High Availability Solutions. Alex Poritskiy Percona

MySQL High Availability Solutions. Alex Poritskiy Percona MySQL High Availability Solutions Alex Poritskiy Percona The Five 9s of Availability Clustering & Geographical Redundancy Clustering Technologies Replication Technologies Well-Managed disasters power failures

More information

Recovering Disk Storage Metrics from low level Trace events

Recovering Disk Storage Metrics from low level Trace events Recovering Disk Storage Metrics from low level Trace events Progress Report Meeting May 05, 2016 Houssem Daoud Michel Dagenais École Polytechnique de Montréal Laboratoire DORSAL Agenda Introduction and

More information

GFS-python: A Simplified GFS Implementation in Python

GFS-python: A Simplified GFS Implementation in Python GFS-python: A Simplified GFS Implementation in Python Andy Strohman ABSTRACT GFS-python is distributed network filesystem written entirely in python. There are no dependencies other than Python s standard

More information

A Guide to Architecting the Active/Active Data Center

A Guide to Architecting the Active/Active Data Center White Paper A Guide to Architecting the Active/Active Data Center 2015 ScaleArc. All Rights Reserved. White Paper The New Imperative: Architecting the Active/Active Data Center Introduction With the average

More information

Manual Mysql Query Cache Hit Rate 0

Manual Mysql Query Cache Hit Rate 0 Manual Mysql Query Cache Hit Rate 0 B) why the Table cache hit rate is only 56% How can i achieve better cache hit rate? (OK) Currently running supported MySQL version 5.5.43-0+deb7u1-log or complex to

More information

White Paper. Major Performance Tuning Considerations for Weblogic Server

White Paper. Major Performance Tuning Considerations for Weblogic Server White Paper Major Performance Tuning Considerations for Weblogic Server Table of Contents Introduction and Background Information... 2 Understanding the Performance Objectives... 3 Measuring your Performance

More information

Migrating to XtraDB Cluster 2014 Edition

Migrating to XtraDB Cluster 2014 Edition Migrating to XtraDB Cluster 2014 Edition Jay Janssen Managing Consultant Overview of XtraDB Cluster Percona Server + Galera Cluster of Innodb nodes Readable and Writable Virtually Synchronous All data

More information

Scalability of web applications

Scalability of web applications Scalability of web applications CSCI 470: Web Science Keith Vertanen Copyright 2014 Scalability questions Overview What's important in order to build scalable web sites? High availability vs. load balancing

More information

Why Choose Percona Server For MySQL? Tyler Duzan

Why Choose Percona Server For MySQL? Tyler Duzan Why Choose Percona Server For MySQL? Tyler Duzan Product Manager Who Am I? My name is Tyler Duzan Formerly an operations engineer for more than 12 years focused on security and automation Now a Product

More information

Azure database performance Azure performance measurements February 2017

Azure database performance Azure performance measurements February 2017 dbwatch report 1-2017 Azure database performance Azure performance measurements February 2017 Marek Jablonski, CTO dbwatch AS Azure database performance Introduction The popular image of cloud services

More information

Column Stores vs. Row Stores How Different Are They Really?

Column Stores vs. Row Stores How Different Are They Really? Column Stores vs. Row Stores How Different Are They Really? Daniel J. Abadi (Yale) Samuel R. Madden (MIT) Nabil Hachem (AvantGarde) Presented By : Kanika Nagpal OUTLINE Introduction Motivation Background

More information

- SLED: single large expensive disk - RAID: redundant array of (independent, inexpensive) disks

- SLED: single large expensive disk - RAID: redundant array of (independent, inexpensive) disks RAID and AutoRAID RAID background Problem: technology trends - computers getting larger, need more disk bandwidth - disk bandwidth not riding moore s law - faster CPU enables more computation to support

More information

1 Copyright 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8

1 Copyright 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 1 Copyright 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 ADVANCED MYSQL REPLICATION ARCHITECTURES Luís

More information

Bullet Cache. Balancing speed and usability in a cache server. Ivan Voras

Bullet Cache. Balancing speed and usability in a cache server. Ivan Voras Bullet Cache Balancing speed and usability in a cache server Ivan Voras What is it? People know what memcached is... mostly Example use case: So you have a web page which is just dynamic

More information

Performance comparisons and trade-offs for various MySQL replication schemes

Performance comparisons and trade-offs for various MySQL replication schemes Performance comparisons and trade-offs for various MySQL replication schemes Darpan Dinker VP Engineering Brian O Krafka, Chief Architect Schooner Information Technology, Inc. http://www.schoonerinfotech.com/

More information

Upgrading MySQL Best Practices. Apr 11-14, 2011 MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc

Upgrading MySQL Best Practices. Apr 11-14, 2011 MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc Upgrading MySQL Best Practices Apr 11-14, 2011 MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc MySQL Upgrade How many of you have performed MySQL upgrade? Home many of you have done

More information

Performance Benchmark and Capacity Planning. Version: 7.3

Performance Benchmark and Capacity Planning. Version: 7.3 Performance Benchmark and Capacity Planning Version: 7.3 Copyright 215 Intellicus Technologies This document and its content is copyrighted material of Intellicus Technologies. The content may not be copied

More information

0-1 Million in 46 Days Scaling a Facebook Application in Rails

0-1 Million in 46 Days Scaling a Facebook Application in Rails 0-1 Million in 46 Days Scaling a Facebook Application in Rails Ikai Lan Linkedin Ikai Lan From 0 to 1,000,000 in 46 Days: Scaling a Facebook Application in Rails Slide 1 Hi! I m Ikai Lan Ikai Lan From

More information

Forecasting MySQL Scalability. Baron Schwartz O'Reilly MySQL Conference & Expo 2011

Forecasting MySQL Scalability. Baron Schwartz O'Reilly MySQL Conference & Expo 2011 Forecasting MySQL Scalability Baron Schwartz O'Reilly MySQL Conference & Expo 2011 Consulting Support Training Development For MySQL Percona Server Replaces MySQL Faster Queries More Consistent More Measurable

More information

SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT

SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT QlikView Technical Brief February 2012 qlikview.com Introduction When it comes to the enterprise Business Discovery environments, the ability of the

More information

SSD/Flash for Modern Databases. Peter Zaitsev, CEO, Percona November 1, 2014 Highload Moscow,Russia

SSD/Flash for Modern Databases. Peter Zaitsev, CEO, Percona November 1, 2014 Highload Moscow,Russia SSD/Flash for Modern Databases Peter Zaitsev, CEO, Percona November 1, 2014 Highload++ 2014 Moscow,Russia Percona We love Open Source Software Percona Server Percona Xtrabackup Percona XtraDB Cluster Percona

More information

CISC 7610 Lecture 2b The beginnings of NoSQL

CISC 7610 Lecture 2b The beginnings of NoSQL CISC 7610 Lecture 2b The beginnings of NoSQL Topics: Big Data Google s infrastructure Hadoop: open google infrastructure Scaling through sharding CAP theorem Amazon s Dynamo 5 V s of big data Everyone

More information

IBM V7000 Unified R1.4.2 Asynchronous Replication Performance Reference Guide

IBM V7000 Unified R1.4.2 Asynchronous Replication Performance Reference Guide V7 Unified Asynchronous Replication Performance Reference Guide IBM V7 Unified R1.4.2 Asynchronous Replication Performance Reference Guide Document Version 1. SONAS / V7 Unified Asynchronous Replication

More information

Choosing a MySQL High Availability Solution. Marcos Albe, Percona Inc. Live Webinar June 2017

Choosing a MySQL High Availability Solution. Marcos Albe, Percona Inc. Live Webinar June 2017 Choosing a MySQL High Availability Solution Marcos Albe, Percona Inc. Live Webinar June 2017 Agenda What is availability Components to build an HA solution HA options in the MySQL ecosystem Failover/Routing

More information

Distributed File Systems

Distributed File Systems Distributed File Systems Today l Basic distributed file systems l Two classical examples Next time l Naming things xkdc Distributed File Systems " A DFS supports network-wide sharing of files and devices

More information

WHITE PAPER AGILOFT SCALABILITY AND REDUNDANCY

WHITE PAPER AGILOFT SCALABILITY AND REDUNDANCY WHITE PAPER AGILOFT SCALABILITY AND REDUNDANCY Table of Contents Introduction 3 Performance on Hosted Server 3 Figure 1: Real World Performance 3 Benchmarks 3 System configuration used for benchmarks 3

More information

Load Testing Tools. for Troubleshooting MySQL Concurrency Issues. May, 23, 2018 Sveta Smirnova

Load Testing Tools. for Troubleshooting MySQL Concurrency Issues. May, 23, 2018 Sveta Smirnova Load Testing Tools for Troubleshooting MySQL Concurrency Issues May, 23, 2018 Sveta Smirnova Introduction This is very personal webinar No intended use No best practices No QA-specific tools Real life

More information