I am sure that you know Mysql quite well: this advanced, very used open source database is one of the key softwares behind the LAMP stack (Linux, Apache, MySQL, PHP). Sun (now Oracle) estimate that about 50% of all deployed databases are mysql installations.

Very often, these installations are kept at default settings – and for good reason: generally, default parameters are configured for safety and, if you don't really know what you are doing, you can severely impair your server reliability and/or performance. Moreover, many mysql installations deal with basic, simple tasks, where performance is not a crucial factor.

However, there are cases where you really need to speed up your mysql deployment: for example, think to a frequently visited web site with mysql backend, or an application that executes a lot of queries/transactions. In this case, what you can do to extract more speed from your beloved mysql server? This article will shed some light on this topic.

The smallest member of SonicWall's UTM firewall is the SonicWall TZ100, or TZ100 in short. This little, white-looking appliance, albeit low-end, is a 100% UTM-enabled device, capable of url/content filtering, antivirus inspection and IDS/IPS analysis. You can read the full SonicWall TZ 100 product specifications here, while you can download the complete SonicWall TZ's series PDF datasheet from http://www.sonicwall.com/emea/488_6392.html

Current bare hardware list price is 295$, while a 1 year UTM licenze (yes, you need a license for that) costs another 225$. If you buy the TotalSecure 100 bundle (hardware + 1 year license), list price is at 465$. List price are obviously subject to change; however, you can not expect prices to fall down by a great amount. The point is that we are dealing with a very capable SonicOS-based appliance that boast 5 Fast Ethernet port and quite interesting UTM throughput, as SonicWall state a ~25 Mbit/s full UTM (antivirus + IDS/IPS) performance. Firewall and VPN specifications are quite respectable, being rated at 100 Mbit/s and 75 Mbit/s respectively.

On 12 October 2011 AMD disclose its new flagship CPU: the Bulldozer-based FX-8150 processor. Equipped with 16 MB L2/L3 caches, eight integer cores and four beefed-up FMAC FPUs, the new architecture sound very promising.

However, as many online reviewers discovered, the new AMD Bulldozer architecture didn't performs so well, especially in desktop workloads. Sure, in many cases it was a significant improvement versus the old K10-based PhenomII processors. At the same time, it fail to impress in a large number of tests.

The key question is: why? Why the new AMD processor, with its massive 16 MB cache and 1.2B total transistors number, barely outperform the old Phenom processors? And why sometime it is even slower? This article is going to shed some light on the problem.

Almost one year ago, I checked how different cache settings affected KVM storage subsystem performance. Results were very clear: to obtain good I/O speed, you had to use the write-back or none cache policies, avoiding the write-through one. However, as the write-back policy intrinsic comported some data-loss risk, the safer bullet was to not use any host-based cache (the “nocache” KVM option).