Last modified: 2014-07-02 13:27:48 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 T38483, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36483 - Parser cache hit rate seems abnormally low
Parser cache hit rate seems abnormally low
Status: RESOLVED INVALID
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-03 15:49 UTC by Jarry1250
Modified: 2014-07-02 13:27 UTC (History)
3 users (show)

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


Attachments

Description Jarry1250 2012-05-03 15:49:06 UTC
Around the time of the 1.19 deployments back in February-time, there
was some concern on this list about the downwards spike in the parser
cache hit rate, as shown on [1]. There was, however, also evidence
that it was returning to "normal" (previous) rates and so the concern
dissipated.

Contrary to expectation, however, we're now two months on and the new
"normal" rates are still significantly below the old "normal" rates
(or to put it another way, the miss rate is still considerably higher
than it used to be). 

[1] http://bit.ly/JI41CR
Comment 2 Jarry1250 2012-05-20 16:29:40 UTC
Any further thoughts?

Looking at the graph, it's almost as though "MISS" is tracking "EXPIRED" but plus a couple of percent. Not sure if that helps diagnose the problem, if there is one.
Comment 3 Andre Klapper 2013-03-13 12:33:57 UTC
jarry1250: Is this still worth to investigate (recent similar incidents), or should this report be closed (e.g. WORKSFORME)?
Comment 4 Jarry1250 2013-03-13 13:30:08 UTC
There was an unexplained step-change in February 2012 which has not been fully explained and which suggests to me that some optimisation remains possible. Thus, my instinct is to leave this bug open until the parser cache miss rate is reduced or the change has been explained (e.g. as an artefact of a change in recording methodology).

That said, I'm happy to go with Ops' assessment as to the merits of the point. Alas, they tend to live on RT rather than here.
Comment 5 Jarry1250 2014-07-02 13:27:48 UTC
Probably too late on to debug or gain further insight into this, so closing.

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


Navigation
Links