Ladsgroup added a comment.

  Now it's deployed across the fleet. Here's my analysis:
  
  - I was worried that constant decompressing of values coming from memcached 
would elevate the CPU usage but it didn't
  - I was worried that since wikibase has the caches keyed by entity id instead 
of revision id (which sqlblob store key them based on revision id) would 
increase the read on s8, this actually happened:
  
  F32083174: image.png <https://phabricator.wikimedia.org/F32083174>
  (You can guess when it got deployed everywhere)
  but it's not big enough to cause any major disruption (note that the graph 
doesn't start at zero).
  
  - Looking at mc* hosts and the overall network graphs of mcrouter/memcached, 
I see a rough 10% decrease in network but the noise makes it hard to show you.
  - When I deployed it, the hits of SqlBlobStore didn't change much (it's 
pretty high anyway, 1M/minute) but misses doubled which is expected, the cache 
is warm. It's still putting the long tail into memcached:
  
  F32083353: image.png <https://phabricator.wikimedia.org/F32083353>
  
  - Naturally External Storage had a little pressure but recovered.
  
  F32083384: image.png <https://phabricator.wikimedia.org/F32083384>
  
  - After TTL of Wikibase memcached entries expiring, evictions are going up:
  
  F32083477: image.png <https://phabricator.wikimedia.org/F32083477>
  
  No noticeable increase in user-facing error or fatals or timeouts has been 
observed.
  
  I leave Xghui of two client cases:
  
  - Article of Alan Turing in cawiki: before 
<https://performance.wikimedia.org/xhgui/run/view?id=5f343465bb85443a6277c569> 
after 
<https://performance.wikimedia.org/xhgui/run/view?id=5f343843bb85444a624c89b0>
  - Category:Alan Turing in commons: before 
<https://performance.wikimedia.org/xhgui/run/view?id=5f343460bb85443d625b9a8f> 
after 
<https://performance.wikimedia.org/xhgui/run/view?id=5f34383ebb85444862c7bc29>
  
  Both are the second time requests to warm up their caches. The increase in DB 
is obvious but the easiest solution is to use 
RevisionLookup::getKnownCurrentRevision() instead of 
PrefetchingWikiPageEntityMetaDataAccessor which has a much better cache.

TASK DETAIL
  https://phabricator.wikimedia.org/T255305

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ladsgroup
Cc: Ladsgroup, Michael, Addshore, Aklapper, Alter-paule, Hazizibinmahdi, 
Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, darthmon_wmde, Kent7301, 
alaa_wmde, joker88john, DannyS712, CucyNoiD, Nandana, Gaboe420, Jony, 
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Pablo-WMDE, 
GoranSMilovanovic, QZanden, LawExplorer, Vali.matei, Lewizho99, Maathavan, 
_jensen, rosalieper, Scott_WUaS, Jonas, Izno, Wikidata-bugs, aude, Dinoguy1000, 
Lydia_Pintscher, Mbch331, Jay8g
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to