Ladsgroup added a comment.

  In T246415#6616074 <https://phabricator.wikimedia.org/T246415#6616074>, 
@Addshore wrote:
  
  > In T246415#6541422 <https://phabricator.wikimedia.org/T246415#6541422>, 
@Ladsgroup wrote:
  >
  >> In T246415#6536970 <https://phabricator.wikimedia.org/T246415#6536970>, 
@Addshore wrote:
  >>
  >>> Looking at the ACs I think we have some open questions still
  >>>
  >>> - How feasible is it to introduce a "client" and "repo" db load group and 
have it used in the right places in our code? / how could that be tackled.
  >>
  >> That's not easily feasible as lots of queries come from lib/ data-access/ 
or core itself (e.g. when looking up entity info using page info lookup) and 
it's pretty hard to find out what's the context this wiki is being ran.
  >
  > I guess all this needs though is an abstraction to the DB layer that deals 
with this and adds the groups where needed?
  
  Yup but LB/LB factory is being used directly in lots of places, and if we 
want to properly inject the abstraction, is going to be really complicated (and 
pretty big). Some of the core ones doesn't even accept the LB/LBFactory. I'm 
not saying it's not doable. I'm saying it'll be too much work for too little 
gain IMHO.
  
  > Even lib services ultimately are created by either client or repo?
  >
  >> - Having four groups, `client`, `repo`, `repo-terms`, `client-terms`: Not 
too harder the above but I don't see the point. It wouldn't take advantage of 
cache locality.
  >
  > I don't think we would benefit from having groups such as `repo-terms` or 2 
groups joined up for example as this removes flexibility from where DBAs can 
end up routing these? perhaps?
  > Might be worth checking with them?
  
  Yeah, I'm not sure splitting by both groups would be a good idea (unless we 
grow really really big.)
  
  > The final remaining thing to figure out here would be the AC that reads:
  >
  >> [ ] We can move forward from the results of this investigation and 
implement some db groups that will help the DBAs to split load in a way that 
will help prevent incidents.
  >
  > So we need to answer which direction we want to go in. Seemingly either 
terms, or client vs repo, or both?
  
  I'd say we should collectively decide this. Maybe a meeting would be good?
  
  > CC @Ladsgroup @Michael @WMDE-leszek Should this move back to todo? or do we 
want to try to come up with this final answer not on the camp (but I guess here 
in stalled/waiting nothing will happen)

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

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

To: Michael, Ladsgroup
Cc: ArielGlenn, Michael, Marostegui, Ladsgroup, WMDE-leszek, Aklapper, 
Addshore, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, 
alaa_wmde, joker88john, CucyNoiD, Nandana, jijiki, Klaas_Z4us_V, Gaboe420, 
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, Pablo-WMDE, 
GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, elukey, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, 
Jay8g
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to