I was trying to work out why my /admin/build/blocks page was so slow and after examining some xdebug dumps with KCachegrind, it seems to me that javascript_aggrigator is having a huge performance impact on my site.

Attached is a screenshot which shows data collected over 3 hits of the /admin/build/blocks page. As you can see. javascript_aggrigator and it's related functions feature very prominently on the list.

Disabling JavaScript minifying and requesting the same page 3 times again took the total time cost down from 46,211,550 to 34,094,609 - a considerable difference.

CommentFileSizeAuthor
#6 javascript_aggregator_options.patch8.58 KBNaX
cachegrind.png186.23 KBmrfelton

Comments

derjochenmeyer’s picture

Category: support » bug

Thanks for that hint/feedback!

Where you logged in as admin (user/1)? In theory javascript_aggregator should ONLY minify the javascript files ONCE, it writes it to a cache directory. Aggregation is done by Drupal Core since Drupal 6.

Edit: I will look into that soon. At the moment im very busy with own projects.
Edit: These performance impacts are caused by JSMIN and JSMIN+. Has anybody ideas how to solve this? Or an evaluation on how it affects the performace of a Drupal site in a production environment?

derjochenmeyer’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)
srobert72’s picture

Category: bug » support

I don't propose fix for this particular issue.
But maybe it's an occasion to consider Google Closure compression. It's already in this issue queue.
#632704: Support for google closure compiler

Avantage is that compression is assigned to Google servers as we upload original JS and download minified version.
If latency is low it could be a performance gain.

And JS refactored by Google Closure is supposed to be optimized and faster to execute in browser.

locomo’s picture

I'm also seeing a really big performance hit... particularly with JSmin+

@derjochenmeyer - what is the issue being logged in as user/1 - i frequently am logged in this way . is this causing my javascript to be re-minified? - i just looked in files/js and see multiple .js, .jsmin.js and .js.jsmin.gz files

locomo’s picture

would it make sense to *not* run the javascript aggregator for user/1 ?

i guess i'm trying to understand what conditions cause javascript to be re-minified?

NaX’s picture

Version: 6.x-1.2 » 6.x-1.x-dev
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new8.58 KB

The attached patch changes the JavaScript Aggregator performance options to have three radio buttons.

- Minify
- GZip
- Minify and GZip

This allows you to run GZip without JSMin.

The only thing missing is an update function.

Please note that each time you change one of the options you should also clear your cache or just delete everything in the files/js directory.

Hope somebody finds this helpful.

@locomo
I don't think your JS is being re-minified. It’s just each version of the cached file. The .js file is the core aggregated file, jsmin.js is the JSMin cached version and the .gz file is the GZip compressed cached version.

derjochenmeyer’s picture

@locomo: there are multiple files because drupal generates different "sets of js files". For example: If you use an image rotator script only on the frontpage the corresponding js files are only aggregated and minified for for the frontpage. Different pages with different js features have different sets of js files. This is how drupal works and has nothing to do with Javascript Aggregator.

locomo’s picture

Thanks for the explanations @Nax and @derjochenmeyer

This actually sounds potentially really inefficient in that as you go from page to page on a site a users browser will have to download different sets of js files - where they might otherwise be able to cache these. Seems like you should be able to specify a core set of js files that get aggregated and made available on every page on a site .. and then if needed additional js files could be added on a page by page basis

derjochenmeyer’s picture

Title: Performance issues? » Turn Javascript Aggregator performance options into radio buttons
Status: Needs review » Postponed

Changing title according to the patch provided. I'll take a close look when I have time.

derjochenmeyer’s picture

Status: Postponed » Postponed (maintainer needs more info)

@NaX: sorry for the delay and thanks for the patch. It does not apply anymore (even if I remove your local paths ;) ). What is the real benefit of turning it into options? You were also removing a lot of logic there, e.g. how the .gz is handled.

NaX’s picture

@derjochenmeyer
The main benefit is control and flexibility. The logic was not removed, just moved around a bit. If I remember correctly the gz functionality was moved into a function and the options logic put into a switch statement instead of if statements.

sinasalek’s picture

+1

sinasalek’s picture

+1