Today I was doing some work on one of our database servers (each of them has 4 SAS disks in RAID10 on an Adaptec controller) and it required huge multi-thread I/O-bound read load. Basically it was a set of parallel full-scan reads from a 300Gb compressed innodb table (yes, we use innodb plugin). Looking at the iostat I saw pretty expected results: 90-100% disk utilization and lots of read operations per second. Then I decided to play around with linux I/O schedulers and try to increase disk subsystem throughput. Here are the results:

(more…)

How often do we think about our http sessions implementation? I mean, do you know, how your currently used sessions-related code will behave when sessions number in your database will grow up to millions (or, even, hundreds of millions) of records? This is one of the things we do not think about. But if you’ll think about it, you’ll notice, that 99% of your session-related operations are read-only and 99% of your sessions writes are not needed. Almost all your sessions table records have the same information: session_id and serialized empty session in the data field.

Looking at this sessions-related situation we have created really simple (and, at the same time, really useful for large Rails projects) plugin, which replaces ActiveRecord-based session store and makes sessions much more effective. Below you can find some information about implementation details and decisions we’ve made in this plugin, but if you just want to try it, then check out our project site.

(more…)

Looks like MySQL Camp 2006 was really interesting and useful for its attendees and for entire MySQL community. As the result of this meeting of many MySQL-related professionals we’ve got lots of interesting publications and I want to refer one of them in this post. Very interesting list of 84 MySQL performance tips has beed created on first day of this year MySQL Camp at Google headquarters:

  1. Index stuff.
  2. Don’t Index Everything
  3. Use benchmarking
  4. Minimize traffic by fetching only what you need.
    • Paging/chunked data retrieval to limit
    • Don’t use SELECT *
    • Be wary of lots of small quick queries if a longer query can be more efficient
  5. Use EXPLAIN to profile the query execution plan
  6. Use Slow Query Log (always have it on!)
  7. Don’t use DISTINCT when you have or could use GROUP BY
  8. Use proper data partitions (For Cluster. Start thinking about Cluster *before* you need them)
  9. Insert performance
    • Batch INSERT and REPLACE
    • Use LOAD DATA instead of INSERT
  10. LIMIT m,n may not be as fast as it sounds

So, I think this list can be really useful for all developers/DBAs working with MySQL and want to say “Thanks” to its authors.

This article is part of “Looking For Optimal Solution” series, devoted to testing various Ruby On Rails deployment schemes and doing some simple benchmarks on these schemes. General idea of testing is to find subset of most optimal RoR deployment schemes for different situations.

This small article is about Rails+Mongrel setup and its performance. List of other tested deployment schemes, description of testing methodology and, of course, all benchmark results you can find on “Ruby On Rails Benchmark Summary and Findings” page.

(more…)

Because of not fully correct testing methodology, benchmark results are not fully correct. So, I decided to redo all tests. New benchmark results you can get in “Looking For Optimal Solution” series Summary post.

This week we have started one new project with Ruby on Rails as primary framework. My first task was to prepare runtime environment for it on one of our development servers. When I have tried to research how people doing it, I noted that there is no information about how to deploy rails application with nginx as frontend and what is performance of such solution. Before blindly make any decisions about future platform I’ve decided to make some performance tests of the some most popular rails web servers/frontends. Results of these tests you can find here with configuration samples for all software that I have used.

(more…)

At this week I came across great blog of Peter Zaitsev and Vadim Tkachenko - two developers from High Performace Group at MySQL Inc. This blog’s name is MySQL Performance Blog and, as you probably assume, it is about misscelaneous sides of MySQL optimization and related stuff. So, if you are MySQL administrator or, even, developer, that works with MySQL, I would advise you to take a look at this blog - there are lots of useful MySQL optimization info.