Before we go any further, let’s check with Wikipedia:

Software bloat is a term used to describe the tendency of newer computer programs to have a larger installation footprint, or have many unnecessary features that are not used by end users, or just generally use more system resources than necessary, while offering little or no benefit to its users.

So what I need to provide is contra arguments that Zend Framework doesn’t do those.

“Large installation footprint”

25.8 MB and 2338 files. This is how much ZF weights and this is usually quoted as the main factor of bloatedness. First of all, 25.8 MB is a joke – full application takes maximum 50 MB. So unless you want to squeeze in 100’s of projects into a shared hosting, size of ZF shouldn’t matter at all. Price of hard-drive and RAM (for APC caches) is so low nowadays, that I don’t even remember last time I checked how much space my project takes up.

Same applies with files count – why would anyone even care how much files it has? As you probably know, PHP doesn’t compile your project into one binary, thus making it a big file. What it does, is it loads external code using include/require statements. Hence, from those 2338 you usually going to use around 300 (based on my tests). One can argue that this is still a lot of files, but this big number of files comes from ZF extensibility. A lot of functionality is separated into plugins, adapters etc.

“Unnecessary features”

ZF has massive amount of functionality: starting from web framework components and finishing up with services classes (I have written more about this here). There is a big chance that you are not going to use all of them, but because all components are decoupled (as much as possible) and as mentioned above, you don’t even notice them if you don’t include those files.

I’m one of those people who think that ZF has too much components, but this is rather my own personal preference rather than a problem. Nevertheless, I haven’t used only a few of available components as once you need something, it’s always very quick to just use it. No need to download anything more or look for available components. For serious components like Doctrine, you probably want to look around, but just for some regular code Zend provides all required features.

“Use more system resources”

This one is hot topic in ZF world. But the point here is that “features = slow”, especially in PHP. This happens because PHP as a language is not that fast and as you start adding more features and code, you get slower code. This where framework’s benchmarks are born, but as Pádraic mentions in his post about benchmarks:

To create a positive benchmark, you need to understand that all frameworks were born as festering piles of unoptimised stinking crap. They were all born bad and get worse with age. This sounds quite sad, but actually it’s an inevitable compromise between performance and features. It’s also a compromise between performance and ease-of-use

It’s inevitable to provide those features that ZF provides and still work faster than other frameworks. So considering the speed of development you need to know how much performance you actually need. Maybe rapid development is much more important? At least it’s for me, and by sacrificing some tenths of a second I can roll out projects in a few days. And as “bloated” definition states, something is not bloated if it provides benefits while using more system resources.

How to make it not bloated?

If you still consider ZF as bloated framework, let me give you some ideas how to make it work for you. First of all – profile, profile, profile! I keep mentioning this every time I talk about performance, but don’t judge performance of something without actually knowing why it’s not performing well. Xdebug helps here as it can provide profiling data, which you then can use to detect slow parts of code. From my experience this is usually I/O – DB calls, file reads etc. Get rid of those and you have some decent performance increase.

A lot of other performance factors come from knowing how framework works internally or really reading manual. For example Zend_Application is kind of slow, but it can be easily optimized by just getting rid of it. But this is only needed if you are running very big application, where every millisecond of execution matters, for normal application you’d hardly get any benefit. This is very ZF’s decoupled components start to shine, as you can just use those which work well and add some special sauce for other parts.

Conclusion

I use Zend Framework extensively, so I’m biased a lot here, but having this much of experience, I can at least judge it objectively (up to some degree). And what I can say is that ZF is not bloated, it can be slower than some other available frameworks, but widely popular method to judge its performance by the number of files it has is just wrong. Of course it’s not the easiest framework to get working with (and get it to perform efficiently), but don’t get put off just by archive size it comes in.

Doctrine is a very powerful framework, however you should study its behavior a little bit to get it working properly. As it turns out – it’s not that hard.

Speed

One of the first things I recommend looking at is query cache. Because there is quite a lot happening in turning DQL statement into the SQL query, caching that process can increase performance by a big margin. Best choice – APC, although robo47.net has an example code for use of Zend_Cache adapters, just don’t forget that file back-end is probably not the best pick.

Hydrators are probably the easiest thing to misuse. Hydration in Doctrine language is turning SQL query results into data graph. It can be an array, object or single value. It’s very nice to get results as PHP objects (in this case – models), however it’s slow. Slower than hydrating like array, and much slower than getting raw result from PDO. That’s why I always recommend answering one simple question: “will you be updating/deleting records?”. If the answer is no – hydrate as array, because you are not going to need an actual model (usually).

For this reason I always try to use array notation to access properties rather than like-object-vars one. Basically instead of $product->name I tend to write $product['name'], which returns the same result, but makes switching to array hydration very easy. You can find more tips and tricks at Doctrine manual here, but the key moment is to remember that the faster data structure in PHP is array (I believe so), so if application is not performing well – start playing with hydrations first.

Doctrine has a very nice support for relations, where they work like proxies and data can be retrieved when it’s needed (lazy-loading). However, this is wrong:

$user = Doctrine_Core::getTable('User')->find(1);
 
foreach ($user->Comments as $comment)
{
   print $comment->NewsItem->title . '<br />';
}

This code is bad, because for each comment you will load news item using a separate query, hence you are wasting db server resources and making code slower. Optimization is pretty straightforward:

$query = Doctrine_Query::create();
 
$query->from('Comments C')
        ->innerJoin('C.NewsItem N')
        ->where('C.user_id = ?');
 
foreach ($query->execute(array(1)) as $comment)
{
   print $comment->NewsItem->title . '<br />';
}

Here all the data is loaded in one query and everything happens much faster (and in this case making it to hydrate as array would also improve the performance).

However, make sure you know what you are joining. For example imagine that in previous example news item is also one-to-many (comment has many news items) relation and user 1 has written 1000 comments where each comment is attached to average news items. Query above will return 50′000 records (50 * 1000) which Doctrine will need to hydrate then. This will be very slow and probably going to kill your web server after some time. One day I had a query which was returning 2GB of data, server admins where probably not very happy about it…

Memory

One of my favorite parts of software development is playing with memory usage and making it efficient. Even though it sounds really simple, debugging it and finding it where the memory is leaking is not an easy task. Recently I was using Doctrine to work with quite big datasets (on average 50′000 of records) and probably have tried all the possible tricks to make Doctrine memory efficient. My code looked really simple:

$data = Doctrine_Query::create()->execute();
 
foreach ($data as $item)
{
    // do some work here
}

You might expect that memory usage would be steady, however it is not. Doctrine uses identity map and objects also have a lot of references which makes freeing up memory a tricky job. As my experience showed, even though records have a method free() which is supposed to de-reference it, sometimes it doesn’t help.

So to make memory management work, make sure to try these:

• $record->free(true) – deep free-up, calls free() on all relations too
• $collection->free() – free all collection references
• Doctrine_Manager::connection()->clean() – cleanup connection (and remove identity map entries)

With some debugging and profiling (and these methods) you hopefully can make memory usage to be low. I’m also using some custom iterators (available here) to divide query into chunks, because loading 50′000 of objects in one go is not going to work, so you might want to look at it too.

Another recommended tip: make sure to free queries too. As collections hold references to all records, query object also has some references to parsed sub-parts of query. For this I use auto-free setting enabled by (available in my first part post also here):

// enable automatic queries resource freeing
$manager->setAttribute(
	Doctrine_Core::ATTR_AUTO_FREE_QUERY_OBJECTS,
	true
);

It’s very easy to forget to free a query and it’s again creating these references which makes garbage collector’s work hard. Nevertheless, after enabling this one I don’t know any other place where the memory can start to leak.

Last step – PHP 5.3. I’ve been working with this version for a few months and it works great, so if it’s possible – I recommend using it (you will also help with testing frameworks, but both Zend Framework and Doctrine already should work fine). One important function here is improved garbage collector, so the actual script takes less memory to execute. I haven’t recorded benchmarks on this one, but what I’ve noticed during development is that 5.3 does in fact has a lower peak memory usage.

Conclusion

I think I haven’t missed anything here, or at least these are the tips which made applications work fast (if I have – let me know). To finish with – good optimizations are done by comprehensive benchmarking and profiling, so the fact that Doctrine is a big framework doesn’t necessary mean it’s slow too. At the end of the day, it’s usually only a matter of reading a manual.

All parts:

1. Zend Framework and Doctrine. Part 1
2. Zend Framework and Doctrine. Part 2
3. Zend Framework and Doctrine. Part 3

E-commerce tracker works like normal Google analytics code, it’s simply part of it. Your job is to decide when to supply Google with transaction information, but I see only one logical time – right after confirmed payment.

To track your transactions you need to have “Success page”, a page, where users will be redirected after successful payment. If you don’t have such, you probably won’t be able to track transactions – it’s possible to submit transactions in other pages, but only submitting them in success page would give correct results (further details below). If you have tried Goals in analytics, you know what I’m talking about.

In your success page you need to slightly modify current Analytics tracker code. Google has very good API documentation available at code.google.com/apis, and all required information for transactions tracking is here (yes, only 3 functions). Sample transaction code is this:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? 
"https://ssl." : "http://www.");
 
document.write(unescape("%3Cscript src='" + gaJsHost + 
"google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
 
<script type="text/javascript">
  var pageTracker = _gat._getTracker("UA-ANALYTICS-ID");
 
  pageTracker._trackPageview(); // Track pageview
 
  pageTracker._addTrans(
    "1234",                    // Order ID
    "Mountain View",           // Store name
    "11.99",                   // Total
    "1.29",                    // Tax
    "5",                       // Shipping
    "San Jose",                // City
    "California",              // State
    "USA"                      // Country
  );
 
  pageTracker._addItem(
    "1234",                    // Order ID
    "DD44",                    // Product code
    "T-Shirt",                 // Product Name 
    "Green Medium",            // Category
    "11.99",                   // Price
    "1"                        // Quantity
  );
 
  pageTracker._addItem(..);    // Another Item
 
  pageTracker._trackTrans();   // Track transaction
 
</script>

What you do, is tell Google unique order ID, prices, shipping location and items information. All these parameters will later be used to analyse your sales and give information about popular products, customers habits, etc. Basically, Google analytics is easy way to merge your traffic and sales statistics.

E-commerce tracking has problems too. Most problems arise from success page requirement. For example, in PayPal customer can choose not to go back to shop. PayPal will send payment notification, but because user doesn’t visit your website, you’ve lost one transaction. It’s possible to supply transaction information as soon as user visits website again, but statistics won’t be accurate – user will probably come again from different source, different keywords, or even different month.

However, I recommend trying Google E-commerce tracking for all shops, especially small ones, because they probably don’t have good inside statistics. Statistics in back-end are always much more accurate and informative, but they require much more time and are really harder to implement than adding 20 lines of code. I’d vote for good back-end statistics and Google analytics for visitors vs. buyers analysis.

Zend Server is a complete, enterprise-ready Web Application Server for running and managing PHP applications that require a high level of reliability, performance and security.

I haven’t tried it – probably it will be commercial solution (Zend Studio == Zend Platform?) and I’m not looking for one right one. So I jumped over to Zend Server CE (Community Edition) which is:

The free community edition of Zend Server enables you to set up a complete PHP environment in minutes, and run non-critical PHP applications in development, testing and production

Main differences lie deep inside PHP configuration – not-community version is much more tweaked for performance and production servers, where community edition is for development environments.

To start with, installing Zend Server is a joke and can be done in no-time. Download one file from here, extract it and run in terminal. Thats it! After installation web server was accessible on localhost:10088 and web-based configuration on localhost:10082/ZendServer. Everything worked smoothly and without any errors.

Web interface gives access to server logs, PHP parameters (allows  you to change them, restart server), extensions, debugger, Zend products configuration (Optimizer, Java Bridge, etc.) and some more. If they just add Apache VirtualHosts configuration it would be perfect for me, because I’m still doing it by hand.

Performance is subjective and can’t be judged fast, so I’m not going to compare this package to standalone servers. Probably it will run faster or at least as fast as default configuration Apache+PHP. I do believe that Zend made some configuration improvements, but you only need them if you can’t (or are to lazy) do them yourself.

I have been using standard Apache, PHP, MySQL servers for ages, and haven’t really ever tried anything like this. It’s really user friendly, gives a lot of power through simple interface, and what’s most important is very easy to setup. Probably Xampp (or just running sudo apt-get install apache2 php5) can be installable as fast as Zend Server, but in my belief, Zend Server is much more production-like environment. Depends what you need.

Our task is to give browser enough information to identify content, which later can be used to decided if content has changed, and if not – say it to browser without sending content again. Bigger picture is explained here, I really recommend analysing it a little bit – it gives better understanding how headers work and what they mean.

As you saw in headers map, there are many possible headers to send, but we can focus on three of them:

1. Etag. Unique identified for output data (maybe hash)
2. Last-Modified. Date of last data modification
3. Expires. When to expire content

Constructing algorithm is pretty simple, it can be explained in pseudo-code:

get request headers
   is content expired
      send content, new headers
   else is content different (Etag)
      send content, new headers
   else
      304 header, no content

I’ve created outputCacheHeaders(…) function which (available here) outputs all required headers and returns true if you need to output content or false if not. All you need to do is pass modification time, live time and data (two last ones are not required). Live time says how long should cache be kept and data is used to generate Etag. Very simple!

After enabling correct headers sending, my websites started to feel much faster, because HTTP requests takes much less time. Also, Yahoo performance tips are really worth reading, really. There are many great tips and I have been using many of them for a long time. These tricks are much much more significant than 0.1 s. faster PHP rendering time.

eval(function(p,a,c,k,e,r){...

To start with, it’s very easy to have dynamically packed files (no one wants to pack them by hand, packed versions are only useful for production, debugging them is harder) with PHP. One of many PHP packers is available on-line at http://joliclic.free.fr/php/javascript-packer/en/. It’s simple one-file script which works really well.

JavaScript packing is as simple as:

require 'class.JavaScriptPacker.php';
 
$src = 'my_script.js'; // Script file
$script = file_get_contents($src);
 
$packer = new JavaScriptPacker($script, 'Normal', true, false);
$packed = $packer->pack();
 
header ("Content-type: text/javascript; charset=utf-8");
header ("Content-Length: " . strlen($packed));
echo $packed;

* Parameters for JavaScriptPacker object can be easily tested in project website. Sometimes packed javascripts don’t work because of missing “;” symbols. I used FireBug extension for Firefox to find actual problematic lines in unpacked version and correct them.

Using this class I created controller for all my JavaScripts, which gets JavaScript name from GET call, checks for cached version and if packed version is not cached – creates 1 day cache and outputs it. Also, I pass JavaScript name in special form: “filename1-filename2-… .js” what let’s me merge multiple files into one packed version. (it can be optimized even more by storing cached versions as static files and accessing them directly)

Packer alone cannot make a big difference, but by combining it with:

• multiple files merging
• caching (correct headers)
• then packing
• putting JavaScripts at the bottom of document

gives very good results, not only decreasing HTTP calls count, but also time required to render whole website. Still, it’s very easy to implement whole system since all required libraries (packer, caching, etc.) are available on-line for free.