Dulu sebelum saya mengenal Ubuntu, saya sering menggunakan aplikasi Paint.NET atau Adobe Photoshop (versi bajakan tentunya ^^) untuk menyunting gambar. Nah, saat saya menggunakan Ubuntu, saya merasa kurang nyaman menggunakan aplikasi penyunting gambar bawaannya, yaitu GIMP. Mengapa? Karena pengaturan jendela di GIMP agak kacau (menurut saya), tidak seperti pada Paint.NET atau Photoshop yang menggunakan gaya single window (jendela tunggal).

useradd dan adduser, dua-duanya adalah perintah untuk menciptakan user account di linux. Walaupun sama-sama digunakan untuk menciptakan user, namun ternyata hasil yang didapatkan berbeda. Apa bedanya?

1. useradd akan menciptakan user tanpa diminta untuk mengeset password user tersebut. Sedangkan adduser akan menciptakan user dengan mengeset password user tersebut sekaligus.
2. useradd akan menciptakan user tanpa ada sebuah home directory. Sedangkan adduser akan menciptakan user sekaligus dengan home directory.
3. useradd akan menciptakan user tanpa memberikan informasi lebih lengkap tentang user. Sedangkan adduser akan menciptakan user sekaligus dapat memberikan keterangan lebih lengkap tentang user.

Untuk lebih jelasnya bisa melihat gambar berikut:

The server isnbsp;similarnbsp;to the one from the previous post. Its a 4 year old, but quite meaty server.

The server ran triggers and stored functions that I wrote to help connect different data sets together. Basically reference another table using fairly complicated search logic, get an ID back and store it. The code was then tweaked to be as fast and light as possible.

This time I ran:

99 million row table to reference a 101 million row table
45 million row table to reference the same 101 million row table
35 million row table (same reference)
29 million row table (same reference)
28 million row table (same reference)

All at the same time..

The server hovered consistently around the 300k QPS mark, with a here and there high of 322-328k.
Also, I had to modify the code of Mtop (the application used to monitor MySQL in the picture) to ask for Queries and not Questions from MySQL after I upgraded it.

Performance patches for InnoDB ?. Although many patches are present in XtraDB / InnoDB-plugin, the RC status of plugin does not allow to install it on product for some customer#8217;s policies.
Important fixes are:

- InnoDB IO threads
- Adaptive checkpointing
- Buffer pool mutex split
- Reimplemented read-write locks

Diagnostic patches.

#8211; We provide much more statistics in slow.log, i.e. execution plan, InnoDB timing, profiling info
- Userstat patch

Different patches to help with day to day usage of MySQL ?

Two new features which not available for 5.0:

In slow.log for Stored Procedure call you can see profiling for each individial query from this procedure, not just call storproc()
With userstat you can get additional THREADS_STATISTICS which show similar information to USER/CLIENT_STATISTICS but per THREAD granularity (it#8217;s useful if you have connection pool)

On this stage the patches are available only in source code, you
can get them from Launchpad https://code.launchpad.net/~percona-dev/percona-patches/5.1.43.? Binaries are also on the way, and will be ready soon. We are running intensive stress testing loads on them to provide stable and quality packages.
And to finalize are results for tpce-like benchmark, where I compare MySQL-5.1.43 vs percona-5.1.43.
The results made for TPCE configuration with 2000 customers and 300 tradedays and 16 concurrent users on our R900 server. The dataset is about 25GB, fully fitting into buffer_pool, so disk does not really matter, but data was stored on FusionIO 320GB MLC card.
On chart with results I show amount of TradeResults transactions per 10 sec during 3600 session (more is better)

As you see with percona patches you can get just about 10x improvement.
Yeah, that sounds too cool, but let me explain where difference comes from.
As I mentioned in tpce workload details the load is very SELECT intensive and these SELECTS are mainly scans by secondary keys ( not Primary Keys), so it hits problems in InnoDB rw-lock implementations and in buffer_pool mutex contention, which alredy fixed in percona-patches ( and in XtraDB and InnoDB-plugin also).
So you are welcome to try it!