On the MySQL Performance Blog there's a recent post looking at the impact of SSL in regards to the overall performance of your application. This is part one of a two part series and focuses largely on the results of two tests - one with connection pooling and the other to evaluate connection time.

Some of you may recall my security webinar from back in mid-August; one of the follow-up questions that I was asked was about the performance impact of enabling SSL connections. My answer was 25%, based on some 2011 data that I had seen over on yaSSL’s website, but I included the caveat that it is workload-dependent, because the most expensive part of using SSL is establishing the connection. Not long thereafter, I received a request to conduct some more specific benchmarks surrounding SSL usage in MySQL, and today I’m going to show the results.

He details the environments used for testing including the hardware specs and the version of the software installed. The scripts (really just bash scripts that call sysbench) are included in the post and the results of the tests are both graphed out and dumped in tabular form. The results are pretty surprising, mostly having to do with just how much of an impact the SSL has on the the requests. He makes a few recommendations at the end of the post on how you can mitigate these problems though (hint: it's not about MySQL per se).

As a follow-up to his previous article about the (minimal) overhead from logging, Kevin Schroeder has this new post focusing on the common belief that writing to the file system is the slowest method.

I had a conversation the other day by a person I respect (I respect any PHP developer who knows how to use strace) about the cost of file IO. My assertion has been, and has been for a long time, that file IO is not the boogeyman that it is claimed to be. So I decided to test a cross between those two posts.

His test was to write one million log records to two different sources - the normal physical file system, a RAM drive - one run with a file handle that's left open and the other with a new handle each time. He shows how he made the RAM drive and the PHP he used for the test (running in a VM). He graphs out the results with some interesting results...but you'll have to read the post for that.

Kevin Schroeder has a new post to his site looking at the cost of logging in web applications. It's not so much about the theory behind what to log and when to log as it is the actual performance hit various kinds of logging take on your app.

So, I was having a discussion with a person I respect about logging and they noted that often logging poses a prohibitive cost from a performance perspective. This seemed a little odd to me and so I decided to run a quick series of benchmarks on my own system.

His tests ran through the types of logging available to PHP developers (like "debug", "notice" or "info") and wrote out the same message to a file ten thousand times each. He just did a simple microtime-based benchmark and graphed out the overall time it took. The differences between the tops of the bars is the time it took for that specific level of logging. He dropped it down to a more realistic level and notes that it only took "1/1000ths of a second per request."

The Agile Toolkit blog has a new post today that looks at speed in PHP frameworks the their relative speed (no, there's no benchmarks here).

This question is often asked, but is never answered properly. So how to measure framework speed? Let me also explain why “scalability” is more important than general “performance”. [...] This along with a general overheads of the framework greatly contributes to the “slowness” of your project. So how can framework contribute to performance of your project?

They touch a few different ways that frameworks can help execute things a bit faster like:

• Make Fewer SQL Queries
• Selective render
• Parallelization
• Overheads
• Caching

On the Ibuildings techPortal there's a new tutorial from Sam de Freyssinet that follows up on a previous article he wrote about using HMVC (Hierarchical-Model-View-Controller). In this new article, he talks about some of the things you can do with that pattern to increase performance.

Hierarchical-MVC has been shown to make large web applications easier to scale out, but there is a price to pay— namely overall performance. This article will investigate ways of improving performance within HMVC web applications using asynchronous processing and some good old caching techniques. Predominantly this article will use examples written for the Kohana Framework; however all the concepts portrayed here could apply to any framework or web application.

He starts by pointing out what's wrong with the typical HMVC application - namely that the clean separation of code structure (the hierarchical part) costs the application in overall speed and memory usage. He suggests a simple technology for helping ease the load - caching as much information as possible, mostly in the HTTP client code since HMVC applications rely heavily on it. Code samples includd show how to implement this in a simple Kohana application.

Sebastian Bergmann points out a new feature that PHPUnit (the popular PHP unit testing tool) now has - parallel_test_execution allowing for each test to execute on a separate PHP process.

The advantages of this include full test isolation and the fact that a test can now cause a PHP fatal error or even a segmentation fault of the PHP interpreter without interrupting the test execution.

He does mention, however, that it can cause a bit more overhead for larger testing suites since it needs to create a new process (complete with memory usage) for each running test. There are also coding issues that could be thrown off by this option (he gives an example of an inheritance issue with eZ Components).

He also notes some of his thoughts on how to control/configure the process (like in a configuration file) and via an "@isolated" notation to make it easy to do it dynamically.

Sebastian Bergmann points out a new feature that PHPUnit (the popular PHP unit testing tool) now has - parallel_test_execution allowing for each test to execute on a separate PHP process.

The advantages of this include full test isolation and the fact that a test can now cause a PHP fatal error or even a segmentation fault of the PHP interpreter without interrupting the test execution.

He does mention, however, that it can cause a bit more overhead for larger testing suites since it needs to create a new process (complete with memory usage) for each running test. There are also coding issues that could be thrown off by this option (he gives an example of an inheritance issue with eZ Components).

He also notes some of his thoughts on how to control/configure the process (like in a configuration file) and via an "@isolated" notation to make it easy to do it dynamically.

Despite some apparent time as a nurse for two small furry creatures, Scott Johnson as found time to get back into his "geekiness" in this new post on his blog.

He asks the question: "Is there significant overhead to the is_ functions like is_array, is_object, is_string in php?" He wonders if those kinds of functions, since they are on such a base level, could cause more trouble than their worth when used en masse. He asks because it's used heavily in an approach for his developing Ookles application.

There's already been one comment made on the post, and it mentions that they are, in fact, a trivial call to PHP. It's a simple test that validates simply without much need for too much background action. It does mentions some caveats - is_object, is_resource, and, at times, is_callable.

Despite some apparent time as a nurse for two small furry creatures, Scott Johnson as found time to get back into his "geekiness" in this new post on his blog.

He asks the question: "Is there significant overhead to the is_ functions like is_array, is_object, is_string in php?" He wonders if those kinds of functions, since they are on such a base level, could cause more trouble than their worth when used en masse. He asks because it's used heavily in an approach for his developing Ookles application.

There's already been one comment made on the post, and it mentions that they are, in fact, a trivial call to PHP. It's a simple test that validates simply without much need for too much background action. It does mentions some caveats - is_object, is_resource, and, at times, is_callable.