About a year ago, I was introduced to Zend Framework as the framework I was going to be working with almost every day. And for nearly a year now, every day I have worked closely with Zend Framework, learning it’s intricacies and dealing with its warts. I sat down in March of last year and wrote a case study about learning Zend Framework. A year after adopting it seemed like a good time to reevaluate the framework and reflect.
Learning Zend Framework was a daunting, challenging experience that tested myself and those I worked with. I learned a few lessons that I think are important, and I think are worth sharing.
In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.
I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:
One of the things I’m always looking for is ways to improve performance with the applications I write. While a few applications are write-heavy, most are read-heavy: that is, reading the database is the predominant behavior (for example, this WordPress blog reads the database far more often than it writes to the database). Additionally, Zend Framework is (comparatively) slow at handling requests, offering a throughput of about 67 requests per second on my machine, while loading static pages came in at a whopping 750 requests per second.*
So, given this performance difference, how do we improve the performance of Zend Framework while still retaining its functionality and ease-of-use? Well, we employ caching, of course!
Zend yesterday released a beta of it’s release candidate for both Zend Server and Zend Server CE (Community Edition). Zend Server is not available for the Mac, but Zend Server CE is, so I decided to give it a try.
There are many good things in this product. Among them, is the ability to easily activate and deactivate most of the plugins and extensions that come bundled with PHP by default. I was able to turn imagick on with no trouble – something I’d been unable to previously compile on the Mac myself (problems with libraries and a lack of time). Most of the extensions are included by default, and it’s easy to configure the directives that PHP has for extensions and core alike. Plus, restarting PHP is as easy as a click of a button.
ZendCon is over, and it’s time for a roundup of the best and worst of ZendCon 2008.
Zend did a fantastic job, and it showed in the organization and execution of the event. ZendCon was one of the best organized conferences I’ve been to in a while. As a presenter I was given (most of) the things I needed, the food was higher quality than I had anticipated, and I really enjoyed the speakers. Some of the best included Chris Shiflett, Eli White, Elizabeth M. Smith and many others.
There were a number of great receptions, including the ZCE reception, the welcome reception and the vendors reception. The only exception was the Yahoo! party, which did not live up to expectations. However, a lot of people seemed to enjoy it, which was great.