The CHANGELOG
has all the details about the changes and you can even have a look at the full
diff.

Besides small bug fixes, it also fixes a regression in the
SensioFrameworkExtraBundle introduced in the 2.0.13 release.

If you are starting a new project, you can get the Symfony Standard Edition
distribution on the download page.

If you already have a project based on the Symfony Standard Edition 2.0.x, you
can easily upgrade to 2.0.13 by getting the new
deps and
deps.lock
files.

Then, run the vendors script (it also clears your cache):

$ ./bin/vendors install

Remember that the Symfony2 Components are also available as standalone
libraries. You can get them via their dedicated read-only repositories on
Github (https://github.com/symfony/Finder for instance), install them via
PEAR (pear install symfony2/Finder), or even
install them via Composer.

You will also get a signed copy of High Performance MySQL 3rd edition as an attendee.

OK, let’s start off with the configuration details.

Configuration

First of all let me describe the EC2 instance type that I used.

EC2 Configuration

I chose m2.4xlarge instance as that’s the instance type with highest memory available, and memory is what really really matters.

High-Memory Quadruple Extra Large Instance
68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge

As for the IO configuration I chose 8 x 200G EBS volumes in software RAID 10.

Now let’s come to the MySQL configuration.

MySQL Configuration

I used Percona Server 5.5.22-55 for the tests. Following is the configuration that I used:

## InnoDB options
innodb_buffer_pool_size         = 55G
innodb_log_file_size            = 1G
innodb_log_files_in_group       = 4
innodb_buffer_pool_instances    = 4
innodb_adaptive_flushing        = 1
innodb_adaptive_flushing_method = estimate
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method             = O_DIRECT
innodb_max_dirty_pages_pct      = 50
innodb_io_capacity              = 800
innodb_read_io_threads          = 8
innodb_write_io_threads         = 4
innodb_file_per_table           = 1

## Disabling query cache
query_cache_size                = 0
query_cache_type                = 0

You can see that the buffer pool is sized at 55G and I am using 4 buffer pool instances to reduce the contention caused by buffer pool mutexes. Another important configuration that I am using is that I am using “estimate” flushing method available only on Percona Server. The “estimate” method reduces the impact of traditional InnoDB log flushing, which can cause downward spikes in performance. Other then that, I have also disabled query cache to avoid contention caused by query cache on write heavy workload.

OK, so that was all about the configuration of the EC2 instance and MySQL.

Now as far as the benchmark itself is concerned, I made no code changes to iiBench, and used the version available here. But I changed the table to use range partitioning. I defined a partitioning scheme such that every partition would hold 100 million rows.

Table Structure

The table structure of the table with no secondary indexes is as follows:

CREATE TABLE `purchases_noindex` (
  `transactionid` int(11) NOT NULL AUTO_INCREMENT,
  `dateandtime` datetime DEFAULT NULL,
  `cashregisterid` int(11) NOT NULL,
  `customerid` int(11) NOT NULL,
  `productid` int(11) NOT NULL,
  `price` float NOT NULL,
  PRIMARY KEY (`transactionid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (transactionid)
(PARTITION p0 VALUES LESS THAN (100000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (200000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (300000000) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (400000000) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN (500000000) ENGINE = InnoDB,
 PARTITION p5 VALUES LESS THAN (600000000) ENGINE = InnoDB,
 PARTITION p6 VALUES LESS THAN (700000000) ENGINE = InnoDB,
 PARTITION p7 VALUES LESS THAN (800000000) ENGINE = InnoDB,
 PARTITION p8 VALUES LESS THAN (900000000) ENGINE = InnoDB,
 PARTITION p9 VALUES LESS THAN (1000000000) ENGINE = InnoDB,
 PARTITION p10 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

While the structure of the table with secondary indexes is as follows:

CREATE TABLE `purchases_index` (
  `transactionid` int(11) NOT NULL AUTO_INCREMENT,
  `dateandtime` datetime DEFAULT NULL,
  `cashregisterid` int(11) NOT NULL,
  `customerid` int(11) NOT NULL,
  `productid` int(11) NOT NULL,
  `price` float NOT NULL,
  PRIMARY KEY (`transactionid`),
  KEY `marketsegment` (`price`,`customerid`),
  KEY `registersegment` (`cashregisterid`,`price`,`customerid`),
  KEY `pdc` (`price`,`dateandtime`,`customerid`)
) ENGINE=InnoDB AUTO_INCREMENT=11073789 DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (transactionid)
(PARTITION p0 VALUES LESS THAN (100000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (200000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (300000000) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (400000000) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN (500000000) ENGINE = InnoDB,
 PARTITION p5 VALUES LESS THAN (600000000) ENGINE = InnoDB,
 PARTITION p6 VALUES LESS THAN (700000000) ENGINE = InnoDB,
 PARTITION p7 VALUES LESS THAN (800000000) ENGINE = InnoDB,
 PARTITION p8 VALUES LESS THAN (900000000) ENGINE = InnoDB,
 PARTITION p9 VALUES LESS THAN (1000000000) ENGINE = InnoDB,
 PARTITION p10 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

Also, I ran 5 instances of iiBench simultaneously to simulate 5 concurrent connections writing to the table, with each instance of iiBench writing 200 million single row inserts, for a total of 1 billion rows. I ran the test both with the table purchases_noindex which has no secondary index and only a primary index, and against the table purchases_index which has 3 secondary indexes. Another thing I would like to share is that, the size of the table without secondary indexes is 56G while the size of the table with secondary indexes is 181G.

Now let’s come down to the interesting part.

Results

With the table purchases_noindex, that has no secondary indexes, I was able to achieve an avg. insert rate of ~25k INSERTs Per Second, while with the table purchases_index, the avg. insert rate reduced to ~9k INSERTs Per Second. Let’s take a look at the graphs have a better view of the whole picture.

Note, in the above graph, we have “millions of rows” on the x-axis and “INSERTs Per Second” on the y-axis.
The reason why I have chosen to show “millions of rows” on the x-axis so that we can see the impact of growth in data-set on the insert rate.

We can see that adding the secondary indexes to the table has decreased the insert rate by 3x, and its not even consistent. While with the table having no secondary indexes, you can see that the insert rate is pretty much constant remaining between ~25k to ~26k INSERTs Per Second. But on the other hand, with the table having secondary indexes, we can see that there are regular spikes in the insert rate, and the variation in the rate can be classified as large, because it varies between ~6.5k to ~12.5k INSERTs per second, with noticeable spikes after every 100 million rows inserted.

I noticed that the insert rate drop was mainly caused by IO pressure caused by increase in flushing and checkpointing activity. This caused spikes in write activity to the point that the insert rate was decreased.

Conclusion

As we all now there are pros and cons to using secondary indexes. While secondary indexes cause read performance to improve, but they have an impact on the write performance. Well most of the apps rely on read performance and hence having secondary indexes is an obvious choice. But for those applications that are write mostly or that rely a lot on write performance, reducing the no. of secondary indexes or even going away with secondary indexes causes a write throughput increase of 2x to 3x. In this particular case, since I was mostly concerned with write performance, so I went ahead to choose a table structure with no secondary indexes. Other important things to consider when you are concerned with write performance is using partitioning to reduce the size of the B+tree, having multiple buffer pool instances to reduce contention problems caused by buffer pool mutexes, using “estimate” checkpoint method to reduce chances of log flush storms and disabling the query cache.

Based on MySQL 5.5.23, including all the bug fixes in it, Percona Server 5.5.23-25.3 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the release can be found in the 5.5.23-25.3 milestone at Launchpad.

Bugs Fixed:

• Percona Server would crash on a DDL statement if an XtraDB internal SYS_STATS table was corrupted or overwritten. This is now fixed by detecting the corruption and creating a new SYS_STATS table. Bug fixed #978036 (Laurynas Biveinis).

Release notes for Percona Server 5.5.23-25.3 are available in our online documentation.

List of changes:

• Fixes merged from upstream (Codership-mysql)
• Support for MyISAM, now changes to MyISAM tables are replicated to other nodes
• Improvements to XtraBackup SST methods, better error handling
• New SST wsrep_sst_method=skip, useful when you start all nodes from the same sources (i.e. backup)
• Ability to pass list of IP addresses for a new node, it will connect to the first available

Binaries are available from downloads area or from our repositories.

For this release we will provides binaries for Ubuntu 12.04, they are coming soon.

If you want to know more how to migrate to XtraDB Cluster, we will be giving a free webinar on June 6th.

This is an General Availability release. We did our best to eliminate bugs and problems during alpha and beta testing release, but this is a software, so bugs are expected. If you encounter them, please report to our bug tracking system.

Links:

• We provide tar.gz and RPM binaries for RedHat (CentOS, Oracle Linux) 5 and 6, and Debian packages.
  Downloads: http://www.percona.com/downloads/Percona-XtraDB-Cluster/
• Documentation
  Codership Wiki
• General Discussion group
• Launchpad project
• Bug reports

I’m going to use some of the aggregated results for my Symfony Live
keynote, and all the aggregated results will be
published on this blog after the conference.

Not convinced yet? Enter your SensioLabs Connect username at the end of the
survey to get a cool badge and to be included in a raffle with great Symfony
goodies up for grabs (t-shirts and caps).

Would you mind spending a few minutes to answer these questions?

Development mailing list

• Empty square brackets in Symfony2 log using Monolog

Symfony2 development highlights

Master branch:

• 23e15bb:
  [Validator] fixed a bug in the ExecutionContext
• ead4908:
  [Validator] some cleanup of the GraphWalker
• bdc21b4:
  [Validator] added a base AbstractLoader
• 3719c70:
  updated minimum PHP version to 5.3.3 (5.3.3 has some interesting fixes and this is the version used by Redhat 6 and Debian 6)
• 23b5e60:
  [DependencyInjection] fixed anonymous services handling in XmlFileLoader
• 43249de:
  [DependencyInjection] added support for anonymous services as properties
• 906f6f6:
  [DependencyInjection] fixed private services removal when used as configurators
• f14961b:
  [DomCrawler] converted all usage of filter() to filterXPath() in unit tests to be less dependent on CssSelector
• c9ebe67:
  [DomCrawler] fixed encoding when using addHtmlContent()
• 3d9990a:
  [DependencyInjection] added ParameterBag::remove
• 80a2a92:
  [Yaml] fixed value of mapping (even if value is sequence) doesn’t have to be indented
• 0216e05:
  [Session] assume that memcache(d) instances are already configured
• b865b09:
  [Session] fixed the PDO handler for mysql concurrent write
• 51b753a:
  [Session] cleanup of the PDO storage
• 709be4b:
  [WDT] added documentation link
• e193452:
  switched to use mbstring whenever possible instead of iconv

2.0.x branch:

• 906f6f6:
  [DependencyInjection] fixed private services removal when used as configurators
• cbc3ed3:
  [HttpKernel] added some constant for better forward compatibility
• c642a5e:
  [CssSelector] ignored an optional whitespace after a combinator

Repository summary: 4,645 watchers (#1 in PHP, #30 overall) and 1207 forks (#1 in PHP, #12 overall).

Updated plugins

• apostrophe:
  • fixed link_to is not suitable for user-supplied URLs
• apostropheBlog:
  • set a-blog-has-filters flag slot when the filter sentence is present

They talked about us

• ?????????????? ??????????? ???????? ? SonataAdminBundle ? Symfony2
• Symfony Live Paris 2012 by SensioLabs du 6 au 9 juin
• Guía de Symfony2 – Capítulo 12 – Integrando jQuery
• Query parameter handling in Symfony2
• Symfony Live Paris 2012 by SensioLabs
• Symfony2 Config Component: Config Definition and Processing
• Custom bulk actions in SonataAdminBundle
• Symfony Live Paris 2012
• Symfony??
• Symfony pada Netbean
• BrainDUG meeting 12 mai 2012: Découverte de Symfony
• Using PHP – Resque with Silex and the Symfony2 Classloader
• Nelmio is coming to a conference near you
• ??????????? ??????????? ? symfony
• How to configure the writable directories in Symfony2′ on Mac OS
• ??????? PHP??????????????????????? ?symfony??? ?
• Using orm designer with Symfony2
• Reverse Engineer (Doctrine, Workbench, Symfony2) with annotation
• Fast symfony2 served on a stable Xubuntu
• Symfony2 & Sessions
• CoreServer?symfony1.4?????????

Fusion-io ioDrive2 Firmware v6.0.0, rev 107004 Public, Fusion-io driver version: 3.1.1.

Now to the results.
For this test I also use Cisco UCS C250 server, and on the graph I show the results for both single card and raid (Duo).

Random writes, async:

We see stable and predictable write performance, with throughput: 660 MiB/s for single, and 1300 MiB/s for Duo

Random reads:

Again both modes provides stable level of throughput. 1350 MiB/s for single and 2300 MiB/s for Duo.

Now with separation per thread for random read synchronous IO:

There is also excellent response time characteristics. 0.25ms and 0.19ms for 8 threads, single and Duo cases.

In general ioDrive2 seems to provide better and more stable performance results comparing to previous generation ioDrive.

Follow @VadimTk

Obviously with ?=0 we are getting uniform distribution – each row is accessed equal times ( for row X: 1/(X^0) ).

There is a research that shows that user behavior can be described by this distribution: Zipf, Power-laws, and Pareto – a ranking tutorial

To see distribution on graphs, I took tables with 1mln rows and run row lookup 1 million times.

There are histograms on how many times each row selected for different ?: 0.5, 0.9, 1.1:

The curve is very skewed, so I zoomed graphs to show only 0-100k level:

I implemented Zipf for sysbench, right now it is in a separate tree https://code.launchpad.net/~vadim-tk/sysbench/zipf-distribution, you are welcome to try if it sounds interesting.

I am going to run couple incoming benchmarks with this distribution.

Follow @VadimTk