Rules-enabled site requests/sec hit [#2630636]

Hi.

I did some benchmarking on a site with rules enabled and with rules disabled to see the performance impact. Rules gives a LOT of flexibility to the site administrator, so some performance impact is to be expected, but the results were very surprising.

I'd like to start by asking if anybody else has done this before, and if my results are understandable.

Apachebench reports only about 25% the requests/second than a stock drupal install on the stock home page. The performance hit is without any rules even set, and it's on EVERY page (even the stock drupal homepage), not just pages relevant to rules.

I even wrote a really short page callback that returns nothing (to skip all rendering and emulate an ajax call), and that's impacted even more.

Here are the details. Numbers are in requests/second reported by apachebench. The first number is the short ajax callback I mentioned, and the second number is the stock drupal home page.

With 86 contrib module dependencies enabled (including rules)...
AJAX CALLBACK: 55, HOME: 47
Rules disabled...
AJAX CALLBACK: 200, HOME: 113
ALL OTHER 85 DEPENDENCIES DISABLED (Stock installation profile)...
AJAX CALLBACK: 225, HOME: 130

So the 85 other modules took ~15% the requests/sec away from stock (no big deal), but rules by itself cut it by 3/4 on ajax and more than half on the stock home page.

The web server and the DB server are both on linode 4GB nodes. I took care of the usual suspects for performance (opcache, memcache, apache/php-fpm tuning, etc) and tried to compare my site to a stock drupal install.

Does this seem reasonable? Does anybody have any benchmarking results to the contrary? I tried to search the issue queue but couldn't find anything.

Oh, and no... I haven't done any profiling yet. I wanted to first see if 2x-4x is anything to be alarmed about first. Maybe you'd say it's unavoidable with the level of flexibility rules provides.

Thanks!

Comments

Comment #1

7 December 2015 at 22:50

captainack created an issue. See original summary.

Comment #2

captainack CreditAttribution: captainack commented 11 December 2015 at 00:09

Issue summary:

View changes

Just a quick FYI -

I tried the test again with NO OTHER MODULES - similar results:

Rules disabled: 136 requests/sec
Rules enabled: 68 requests/sec

Again, this is on the stock drupal 7 front page - login and registration pages showed similar results too.

Also, here's what devel says (after a few refreshes):
Without rules:
Executed 19 queries in 8.18 ms. Queries exceeding 5 ms are highlighted. Page execution time was 26.33 ms. Memory used at: devel_boot()=0.5 MB, devel_shutdown()=2.25 MB, PHP peak=2.75 MB.
With rules:
Executed 28 queries in 13.32 ms. Queries exceeding 5 ms are highlighted. Page execution time was 44.45 ms. Memory used at: devel_boot()=0.5 MB, devel_shutdown()=3.35 MB, PHP peak=3.75 MB.

As I said, I don't have a profiler going, but as far as devel's query printout shows, there aren't any crazy additional queries going on (just a few cache hits clocking in at ~0.5-1.5ms each). So an extra ~5ms spent in queries, but an extra ~18ms spent in PHP.

I'd love it if someone just says "yes, this is understandable - this is the cost of giving the site admin developer-like-powers", or "no, your test setup must have a problem".

Thanks.

Comment #3

captainack CreditAttribution: captainack commented 7 March 2016 at 01:14

I decided to revisit this issue to see if there were any comments and I realized I forgot to mention something very important:

This difference was just by enabling the rules module and not even setting any rules.

Comment #4

fago

German

Vienna

CreditAttribution: fago at drunomics commented 7 March 2016 at 16:49

This sounds really bad indeed - I could imagine what leads it to be so worse other than Rules building up caches. With built up caches, there should be no single db-query hit when rules are evalutated except if the actions/conditions do so.
Could check the content of your rules_event_whitelist? Maybe, if there are no rules at all it stays NULL instead being an empty array and the cache is rebuilt for ever. (see rules_invoke_event()).

Comment #5

captainack CreditAttribution: captainack commented 7 March 2016 at 22:14

Thanks for the reply!

I'll have to poke around the code and schema a little to understand what you are referring to fully. But thanks for giving me a direction to look! And also for letting me know that this is indeed unexpected.