Last modified: 2014-08-05 12:25:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T71112, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 69112 - Drop by ~80% in zero=250-99 tagged lines with "/wiki/" in URL in zero logs
Drop by ~80% in zero=250-99 tagged lines with "/wiki/" in URL in zero logs
Status: RESOLVED FIXED
Product: Analytics
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Unprioritized normal
: ---
Assigned To: Nobody - You can work on this!
u=WikipediaZero c=General/Unknown p=0...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-04 17:38 UTC by christian
Modified: 2014-08-05 12:25 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
/wiki/ and ZeroRatedMobileAccess requests per hour for 250-99 (15.28 KB, image/png)
2014-08-04 17:38 UTC, christian
Details

Description christian 2014-08-04 17:38:19 UTC
Created attachment 16135 [details]
/wiki/ and ZeroRatedMobileAccess requests per hour for 250-99

Since 2014-07-29 ~23:00, zero tags for 250-99 look wrong:
* The zero=250-99 tagged log lines declined a bit in total numbers.
* The zero=250-99 tagged log lines with "/wiki/" in URL dropped by ~80%.
* The zero=250-99 tagged log lines with "ZeroRatedMobileAccess" in URL
  increased drastically.

The time of the change roughly matches

  I3ce7975705bd704f140a397f2233928a21ab39bd

which looks relevant.

Due to the "/wiki/" hits going down, the page views reported on the
dashboard are jumping down too.

See the attached plot of number of zero=250-99 tagged log lines per
hour with "/wiki/" in URL, and with ZeroRatedMobileAccess in URL.

(The short change on 2014-07-25 seems to match

  Ieeb940b27d75e73ce54ad0ab74ac9b72cdfbb881

and it's subsequent revert

  Ica00438edadc8cd06bc646ac1552c477e12dd0fa

)
Comment 1 christian 2014-08-04 17:39:44 UTC
The graph and above numbers were computed by the

  /a/squid/archive/zero/zero.tsv.log-*

files on stat1002.
Comment 2 Yuri Astrakhan 2014-08-04 17:56:21 UTC
This is per https://www.mediawiki.org/wiki/Requests_for_comment/Unified_ZERO_design#Analytics

The new requests should still have X-Analytics=X-CS=250-99, even though the X-CS header will be set to "ON". If it doesn't, its a bug.

Requests for ZeroRatedMobileAccess?zcmd=... should not be counted - they are resource requests to get the banner.

The change I3ce7975705bd704f140a397f2233928a21ab39bd is what switched zero to the new unified model. We plan to switch the rest of zero partners to the same model.
Comment 3 Toby Negrin 2014-08-04 18:03:11 UTC
Hi Yuri -- how was this change communicated? It seems like we were taken by surprise.

thanks,

-Toby
Comment 4 Gerrit Notification Bot 2014-08-04 18:48:54 UTC
Change 151693 had a related patch set uploaded by QChris:
Remove X-CS pre-deliver filtering

https://gerrit.wikimedia.org/r/151693
Comment 5 Gerrit Notification Bot 2014-08-04 18:51:04 UTC
Change 151693 merged by BBlack:
Remove X-CS pre-deliver filtering

https://gerrit.wikimedia.org/r/151693
Comment 6 christian 2014-08-04 19:48:08 UTC
(In reply to Yuri Astrakhan from comment #2)
> The new requests should still have X-Analytics=X-CS=250-99, even though the
> X-CS header will be set to "ON". If it doesn't, its a bug.

(I guess by 'X-CS' you're refering to 'zero' tags in the final X-Analytics
header.)

It was a vcl bug.
Preliminary checks show that Yuri's above patch (comment 4, and
comment 5) fixes it.

I'll do more checking, when more data has been fed into the pipeline.

> Requests for ZeroRatedMobileAccess?zcmd=... should not be counted - they are
> resource requests to get the banner.

No worries, they are not counted.
Comment 7 christian 2014-08-05 12:25:37 UTC
(In reply to christian from comment #6)
> I'll do more checking, when more data has been fed into the pipeline.

Things are back to normal.
Thanks for prompt fix Yuri!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links