[wp-trac] [WordPress Trac] #28722: Boost performance with ETag in load-scripts.php and load-styles.php

[WordPress Trac]

#28722: Boost performance with ETag in load-scripts.php and load-styles.php
-----------------------------+------------------------------------------
 Reporter:  sergej.mueller   |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Script Loader    |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  administration, performance
-----------------------------+------------------------------------------
Changes (by dd32):

 * keywords:   => has-patch


Comment:

 The proposed patch looks like a good start to me, however, have you
 considered the impacts of using the available `$wp_version` and script
 versions instead of a md5 of the content?

 Although we set a 1 year expiry on the document, browsers will still check
 it, as you can see.
 We cache bust the document based on `$wp_version` so the suggestion of
 using the individual script versions is probably over-the-top..

 I only ask about the alternatives, as in many environments the disk IO of
 reading the files and then MD5'ing it may be significant, and maybe
 useless given the above caching we do.

 [attachment:28722.diff 28722.diff] is an implementation that avoids disk
 IO by basing the etag on the the `$wp_version` + script handle versions.
 [attachment:28722.diff 28722.2.diff] is a implementation that simply uses
 our cache buster (`$wp_version`) as the etag (etags don't need to be an
 md5, although that's the most common implementation)

 I did a quick apachebench (1000 req's, 1 thread, between two local VM's)
 against 4.0-beta1 with a large script loader request, and came up with
 some interesting results:

 ||Patch||with eTag||time per request(ms)||req/s||req size(bytes)||
 ||No Patch||NO||19.292ms||51.83||169,411||
 ||[attachment:wp-admin.patch wp-admin.patch]||NO||19.962||50.10||169,411||
 ||[attachment:wp-admin.patch wp-admin.patch]||YES||19.240||51.97||0||
 ||[attachment:28722.diff 28722.diff]||NO||19.670||50.84||169,411||
 ||[attachment:28722.diff 28722.diff]||YES||6.919||144.54||0||
 ||[attachment:28722.2.diff 28722.2.diff]||NO||19.380||51.60||169,411||
 ||[attachment:28722.2.diff 28722.2.diff]||YES||6.818||146.68||0||

 URL requested: `wp-admin/load-scripts.php?c=1&load[]=hoverIntent,common
 ,admin-bar,wp-ajax-response,jquery-color,wp-lists,quicktags,jquery-query
 ,admin-comments,jquery-ui-core,jquery-&load[]=ui-widget,jquery-ui-mouse
 ,jquery-ui-sortable,postbox,dashboard,customize-base,customize-
 loader,thickbox,plugin-install,underscor&load[]=e,shortcode,media-upload
 ,svg-painter,heartbeat,wp-auth-check,word-count,wplink&ver=4.0-beta1`

 The ApacheBench testing shows, that at least when on a local network, the
 network IO is minimal, but the time spent doing file operations is
 significant.

 Just for fun, I ran it against a real server, as the above synthetic tests
 don't really show much (other than PHP executed faster)
 ||Patch||with eTag||time per request(ms)||req/s||req size(bytes)||
 ||[attachment:28722.2.diff 28722.2.diff]||NO||886.781||1.13||169,028||
 ||[attachment:28722.2.diff 28722.2.diff]||YES||162.478||6.15||0||
 ||[attachment:wp-admin.patch wp-admin.patch]||YES||164.223||6.09||0||
 I had to reduce this to 100 requests (still 1 thread), but as expected,
 DiskIO/CPU/NetworkIO were as I’d expect, pretty high for the no-etag test,
 disk/CPU spiking with wp-admin.patch but network stayed low, and hardly
 anything showing up for 28722.2.diff

 The only thing I get out of this is, adding an Etag seems like a good
 idea, it's just a question of what's the best data for us to use for it.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28722#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform