[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

akosiaris added a comment. In T199219#5396104 , @Ladsgroup wrote: > The other thing I want to mention and was missing here is overhead of encryption and TLS handshakes. In the @BBlack's example, we still use TLS but if you use plain

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Ladsgroup added a comment. Given the recent issues with WDQS I would like this to have higher priority. Currently the Wikidata's top requests in any time I checked is from WDQS: 0: jdbc:hive2://an-coord1001.eqiad.wmnet:1000> select user_agent, count(*) as hitcount from wmf.webrequest

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Smalyshev added a comment. > Will WDQS fail in spectacular ways if it requests objects over the uncached endpoints? It won't fail, it would increase load on Wikidata from WDQS by several times since we have 14 servers (not counting external clients, test servers, etc.) that want these

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

akosiaris added a comment. In T199219#5234979 , @Smalyshev wrote: > But won't we lose use of the varnish cache if we use the internal endpoint? Yes that's true. That being said, is that particularly important? Will WDQS fail in

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Smalyshev added a comment. But won't we lose use of the varnish cache if we use the internal endpoint? TASK DETAIL https://phabricator.wikimedia.org/T199219 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: akosiaris, BBlack,

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

akosiaris added a comment. In T199219#5234041 , @Smalyshev wrote: > There's a change though that WDQS no longer uses `nocache` for cache-busting in most common cases (see T217897 for more

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

akosiaris added a comment. In T199219#4452041 , @Smalyshev wrote: > @BBlack I am getting rather strange result with `appservers-ro.discovery.wmnet` - if I call the URL you provided, the call takes a lot of time: > > real

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Smalyshev added a comment. @BBlack I am getting rather strange result with appservers-ro.discovery.wmnet - if I call the URL you provided, the call takes a lot of time: real0m4.270s while if I call to www.wikidata.org, I get: real0m0.127s Same with api-ro. appservers-rw is a bit

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

BBlack added a comment. It's a complicated topic I think, on our end. There are ways to make it work today, but when I try to write down generic steps any internal service could take to talk to any other (esp MW or RB), it bogs down in complications that are probably less than ideal in various

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Smalyshev added a comment. @BBlack following your comments on T199146, do you know a way to access via api.svc but still to have it routed to correct wiki?TASK DETAILhttps://phabricator.wikimedia.org/T199219EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:

[Wikidata-bugs] [Maniphest] [Commented On] T199219: WDQS should use internal endpoint to communicate to Wikidata

Smalyshev added a comment. Doesn't seem to work, if I go to https://api.svc.eqiad.wmnet/wiki/Special:EntityData/Q2408871.ttl?nocache=1530836328152=dump I get this: Domain not configured This domain points to a I guess it needs some kind of a hostname to work?TASK