Performance Of Panels

An actual performance test, like-for-like, of Panels versus Block

Photo of Greg Harvey
Thu, 2012-11-08 12:18By greg

Panels has been around for a long time now. It gets mixed reviews. It's a bit like the Marmite of Drupal - you either love it or you hate it. Personally, I'm a fan, for a number of reasons that warrant blog posts of their own. But one of the things I hear leveled against Panels fairly frequently is it has performance problems. Having never actually seen a straight test, I decided to benchmark Panels against Block, once and for all, to see what happens.

The Method

Edit: see the end of the post for additional test results.

Install Acquia Dev Desktop on a 13" Macbook Pro running a clean Drupal 7 install. Install a fairly standard set of core modules. Add Ctools, Views and Panels.

Drupal version : 7.17
Site URI : http://default
Database driver : mysql
Database hostname : 127.0.0.1
Database username : drupaluser
Database name : acquia_drupal
Database : Connected
Drupal bootstrap : Successful
Drupal user : Anonymous
Default theme : bartik
Administration theme : seven
PHP configuration :
Drush version : 5.4
Drush configuration :
Drupal root : /Users/greg/Sites/acquia-drupal
Site path : sites/default
File directory path : sites/default/files
temp : /tmp

Enable everything. Make sure it's all up to date:

Update status information on all installed and enabled Drupal projects:
Name Install Propose Status
ed d
version version
Drupal 7.17 7.17 Up to date
Chaos tools 7.x-1.2 7.x-1.2 Up to date
(ctools)
Entity API (entity) 7.x-1.0 7.x-1.0 Up to date
-rc3 -rc3
Panels (panels) 7.x-3.3 7.x-3.3 Up to date
Pathauto (pathauto) 7.x-1.2 7.x-1.2 Up to date
SQL Server (sqlsrv) 7.x-1.2 7.x-1.2 Up to date
Token (token) 7.x-1.4 7.x-1.4 Up to date
Views (views) 7.x-3.5 7.x-3.5 Up to date

Next the content. Create half a dozen nodes with some Lorum Ipsum in them. Then create a View, that exposes a block, listing the last five nodes. Then a couple of custom blocks, one for text, one for a picture, using different input formats. Using the Bartik theme, I put the text block and the core Navigation menu in the first sidebar and the picture block and my custom View in the second sidebar.

Then I disabled Block completely. Now for the Panels equivalent. Enable the node_view panel in Page Manager, edit, select a three-column layout, insert the Navigation menu on the left, the View on the right and all the various node elements in the middle column. Then create the two custom blocks as 'Custom panels panes' and mark them as re-usable.

The Results

Now let's test! All core caching is *off* and defaults are in use everywhere, there's no Panels time-based caching on or any other funny stuff. Using Apache's built in 'ab' benchmark testing program, we warmed up the site with a first run of 100 hits, then we hit Panels:

Server Software: Apache/2.2.21
Server Hostname: localhost
Server Port: 8082

Document Path: /content/test
Document Length: 5632 bytes

Concurrency Level: 1
Time taken for tests: 3.220 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Non-2xx responses: 100
Total transferred: 608500 bytes
HTML transferred: 563200 bytes
Requests per second: 31.05 [#/sec] (mean)
Time per request: 32.203 [ms] (mean)
Time per request: 32.203 [ms] (mean, across all concurrent requests)
Transfer rate: 184.53 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 26 10.4 31 46
Processing: 0 7 9.9 0 24
Waiting: 0 7 9.9 0 24
Total: 29 32 2.6 32 46

Percentage of the requests served within a certain time (ms)
50% 32
66% 32
75% 32
80% 33
90% 34
95% 35
98% 44
99% 46
100% 46 (longest request)

Then we disabled all the Panels-related modules, enabled Block again and...

Document Path: /content/test
Document Length: 9411 bytes

Concurrency Level: 1
Time taken for tests: 6.825 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Non-2xx responses: 100
Total transferred: 984200 bytes
HTML transferred: 941100 bytes
Requests per second: 14.65 [#/sec] (mean)
Time per request: 68.250 [ms] (mean)
Time per request: 68.250 [ms] (mean, across all concurrent requests)
Transfer rate: 140.83 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 65 68 3.5 68 89
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 65 68 3.5 68 89

Percentage of the requests served within a certain time (ms)
50% 68
66% 68
75% 69
80% 69
90% 70
95% 79
98% 80
99% 89
100% 89 (longest request)

Wow. Block is, on the face of it, significantly slower than Panels.

OK, so let's test a bit more (thanks, James, for the suggestions). Let's enable the core Block cache:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 64 68 3.7 67 87
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 64 68 3.7 67 87

Percentage of the requests served within a certain time (ms)
50% 67
66% 68
75% 68
80% 68
90% 70
95% 76
98% 82
99% 87
100% 87 (longest request)

Hardly any difference! So let's hide all our blocks to see if that changes anything. I edited the lot so they don't appear on the page we're testing but do appear in the region:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 30 11.6 35 45
Processing: 0 7 11.8 0 32
Waiting: 0 7 11.8 0 32
Total: 34 37 2.3 37 45

Percentage of the requests served within a certain time (ms)
50% 37
66% 38
75% 38
80% 39
90% 40
95% 41
98% 44
99% 45
100% 45 (longest request)

OK, now things are looking better. But of course, we're not doing anything! And what's this? The pages are *heavier* with core Block and Node doing the serving with no blocks than a fully rendered Panels page:

Document Path: /content/test
Document Length: 7322 bytes

So let's start putting blocks back in. Here's the result with everything back in except the View:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 37 40 2.7 40 51
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 37 40 2.7 40 51

Percentage of the requests served within a certain time (ms)
50% 40
66% 40
75% 41
80% 41
90% 43
95% 48
98% 50
99% 51
100% 51 (longest request)

What the...? That's actually not bad, which means... Ouch! Views + Block does something ugly. So I enabled Views time-based cache for the view to see if that helps. It knocked about 6ms off, but made no appreciable difference (to Block or Panels, I might add).

Conclusions

Panels is, in general, about 20% quicker than Block. Until you add in some Views blocks. Then big ouchy things start to happen (we haven't investigated why that is yet). Those big ouchy things *only* affect Block and not Panels. So all of a sudden Panels becomes about 100% quicker than Block if you have blocks lying about that are outputting Views through the traditional Block system. But any way you look at it, it seems Panels simply is indisputably quicker than Block, according to our quick benchmark results. Finding out why Views does such bad things to Block would be an interesting exercise, but to draw a line under the initial question, is Panels slower than Block?

No. It's quicker.

Another criticism sometimes leveled at Panels is the mark-up is too heavy. What's interesting here is the pages are much heavier when using the Block and Node modules and Bartik theme 'as is' than those pages generated by Panels only, overriding the core region and node systems. Again, we haven't looked closely into this, but it's an interesting observation.

A bit more on Block

There are other issues with systems requiring a lot of blocks. Let's not forget, the block system in Drupal has been around forever and it hasn't changed much. It's fine for simple implementations, but by way of an example of the kinds of issues you can hit upon if you try to stretch it too far, we have a client who has a few hundred blocks with differing visibility rules in the second sidebar of one of our sites. We have discovered (the hard way) that the new drag and drop UI doesn't quite work. There is a limited range of permitted block weights (about 400, if memory serves) and as you drag blocks up and down in admin, sooner or later they all end up either bunched at the top or bottom of the range. The result? No matter how much you drag them about, they all have an identical weight and display arbitrarily. The quickest fix is to disable JavaScript to see the old drop-down menu UI and manually re-assign all the weights over a sensible range. Laborious, I can assure you!


The point is this: Block serves a purpose and serves it well, but there are emerging techniques that work better and faster. This is true for more than just Block. As a general rule, it pays to keep an eye on contrib and examine your requirements well, test your assumptions and tread carefully before choosing your path. The core modules available may not always be the best solution to your specific problem.

A Caveat - Follow-up Testing

The day after the night before, I sprang out of bed (actually, that's not quite true... but you get the idea) and set up the tests again on my old HP EliteBook 8730w. This machine is running Fedora 14, Apache with mod_php, APC and MySQL, all pretty much as they are in the RedHat repository, instead of the Acquia Dev Desktop, which is only on my Macbook because I'm lazy and it was easy.

Here are the results:

Panels:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 105 106 1.3 106 112
Waiting: 100 102 1.3 101 107
Total: 105 106 1.3 106 112

Percentage of the requests served within a certain time (ms)
50% 106
66% 106
75% 107
80% 107
90% 108
95% 109
98% 112
99% 112
100% 112 (longest request)

Block:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 85 90 9.0 86 132
Waiting: 81 85 7.9 82 127
Total: 85 90 9.0 86 132

Percentage of the requests served within a certain time (ms)
50% 86
66% 88
75% 91
80% 91
90% 99
95% 115
98% 128
99% 132
100% 132 (longest request)

Block without Views:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 49 50 1.2 50 56
Waiting: 47 48 1.1 48 53
Total: 49 50 1.2 50 56

Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 52
95% 53
98% 53
99% 56
100% 56 (longest request)

Panels with Simplecache on the View:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 70 72 1.1 72 77
Waiting: 67 69 1.1 69 74
Total: 70 72 1.1 72 77

Percentage of the requests served within a certain time (ms)
50% 72
66% 72
75% 72
80% 72
90% 73
95% 74
98% 76
99% 77
100% 77 (longest request)

Panels without Views:

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 68 70 1.4 70 76
Waiting: 65 67 1.4 67 73
Total: 68 70 1.4 70 76

Percentage of the requests served within a certain time (ms)
50% 70
66% 70
75% 70
80% 70
90% 73
95% 73
98% 73
99% 76
100% 76 (longest request)

So, what do we draw from that? Well, firstly, clearly Drupal can behave quite differently on different systems. The HP is much slower and older than the Macbook Pro and it also has older versions of software running on it. The databases will also be a little different - probably cleaner on the HP, in truth - so that could skew things, though I wouldn't expect the effect to be large.

The HP bears out the finding that, in general, if you use Views extensively in your site, there's more to think about. Whether Panels has the edge or not *appears* to rely heavily on hardware, software and set-up. It varies hugely depending on those choices. The HP test also shows that Panels definitely handles displaying Views significantly better than Block does, as a percentage of the overall load time, and it's still the case that you get an *enormous* performance leap from Block if you don't use any Views.

However, the principle difference is on the HP a page rendered about 10% faster with Block than it did with Panels, which was the complete opposite of the findings on the Macbook Pro and complex pages on the Mac were *way* faster in Panels than in Block. Why that would be so warrants more investigation. If anyone wants to reproduce my test on another Macbook Pro, I'd be curious to see the result.

Finally, an additional test I did involved enabling Panels Simplecache on the View pane, which made a huge difference. It seems Simplecache is a big win, unsurprisingly, when it comes to serving lots of Views on a page. With Simplecache on there was little difference between the response time of a Panels page with Views and a Panels page without Views, and it trumps Block every time on any system.