Our solution for this is now live.
Here's an example of a media beacon hit:
http://bits.wikimedia.org/beacon/media?duration=3709&uri=http%3A%2F%2Fup...
Beta is currently hitting that endpoint and production wikis will start doing the same once they start running 1.25wmf22
All views coming from Media Viewer will be hitting that endpoint. Note that there might be some loss of hits on browsers that don't support sendBeacon, since our fallback is a simple async AJAX request (we haven't tried to go beyond that with local storage and replaying the event, etc.) and this event might be fired in situations of tab/browser close as well as navigating away from the page. Thus keep in mind that a steady small increase of those hits over a long period of time might simply be the natural process of people upgrading their browsers to more modern ones.
On Fri, Feb 6, 2015 at 4:46 PM, Nuria Ruiz nuria@wikimedia.org wrote:
A dummy image request seems rather reasonable. (I assume varnish can
handle such load of "atypical" requests.) Right, the filtering for beacons is already in place in vcl and responses are sent right away so as far as I know there is no better place than varnish for this code. See example:
https://github.com/wikimedia/operations-puppet/blob/production/templates/var...
On Thu, Feb 5, 2015 at 10:38 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gergo Tisza, 04/02/2015 21:00:
Do you see any fundamental problem with this?
A dummy image request seems rather reasonable. (I assume varnish can handle such load of "atypical" requests.) Making additional requests is ugly, but until we get SPDY our articles typically make dozens or hundreds requests, so the effect looks negligible.
Nemo
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics