Smalyshev added a comment.
Should be working now, with 1 minute lifetime for now. We'll see how it works
and if we want to change it.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev
gerritbot added a comment.
Change 274864 merged by Gehel:
Add caching headers for nginx
https://gerrit.wikimedia.org/r/274864
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: gerritbot
gerritbot added a comment.
Change 274864 had a related patch set uploaded (by Smalyshev):
Add caching headers for nginx
https://gerrit.wikimedia.org/r/274864
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
Smalyshev added a comment.
After talking about it, the first task to enable it seems to try and make
nginx buffer WDQS results - at least smaller ones.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
Jdforrester-WMF added a comment.
Understood, thanks!
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jdforrester-WMF
Cc: Jdforrester-WMF, JanZerebecki, Milimetric, Gehel, BBlack, GWicke, Bene,
Smalyshev added a comment.
@Jdforrester-WMF I'm not sure we have yet something for ArchCom here. We need
more discussion and form a coherent proposal, and also discuss it with ops.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
Jdforrester-WMF added a comment.
@Jonas – Did you mean to tag this as
https://phabricator.wikimedia.org/tag/archcom-rfc/ or do you not want their
input? Right now it's just generally tagged as
https://phabricator.wikimedia.org/tag/rfc/, which essentially is merely "needs
discussion".
TASK
Yurik added a comment.
That's relatively easy - I could disable wikidataquery: protocol in the client,
while still allowing it on the backend. Thing is, I highly doubt there are
that many people who will click on an interactive graph - simply because it
requires programming skills to create
Smalyshev added a comment.
> user views a page with an interactive graph and clicks it to interact with it
This is the scenario which IMHO can drive most load. The rest is either rare or
protected by cache already like this one:
> user views a page with a graph -> request to graphoid ->
Yurik added a comment.
Data is requested in these cases:
- user views a page with a graph -> request to graphoid -> varnish cache miss
-> graphoid re-renders the graph
- user views a page with an interactive graph and clicks it to interact with it
- editor clicks "page preview"
- editor changes
GWicke added a comment.
> some of my concerns about the affect of including a graph (with a slowish
> query) on page save timing, e.g. when just fixing a typo on a wikipedia page.
To get sensible hit rates for relatively rare events like edits, we would need
to cache results for a long time,
aude added a comment.
@gwicke afaik the data is only requested (?) when the graph is interacted with
+ on parcher cache miss + edit.
some of my concerns about the affect of including a graph (with a slowish
query) on page save timing, e.g. when just fixing a typo on a wikipedia page.
It still
GWicke added a comment.
> Since running the query each time graph is displayed is too expensive, we
> want some intermediate caching store that would store the results, possibly
> for the time defined in the query.
Is the graph extension actually re-requesting the data on each view, or would
Smalyshev added a comment.
@BBlack, thanks for raising these issues, this is definitely something we
should address.
> If it were sent un-chunked with a Content-Length, the varnish would have a
> chance at caching it.
It may be how Blazegraph sends it. But maybe we coould un-chunk it on the
BBlack added a comment.
In https://phabricator.wikimedia.org/T126730#2034900, @Christopher wrote:
> I may be wrong, but the headers that are returned from a request to the nginx
> server wdqs1002 say that varnish 1.1 is already being used there.
It's varnish 3.0.6 currently (4.x is coming
Christopher added a comment.
I may be wrong, but the headers that are returned from a request to the nginx
server wdqs1002 say that varnish 1.1 is already being used there. And, for
whatever reason,** it misses**, because repeating the same query gives the same
response time. For example,
Yurik added a comment.
@smalyshev, I agree - it would be much better to have a stable mature caching
technology for this - makes things much simpler.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
Christopher added a comment.
I perceive the use of Varnish as not directly related to how an object broker
could manage this use case (expensive querying of the wdqs nano sparql api),
though it is probably related to any UI elements (i.e. the query editor or
results renderer) that may
Smalyshev added a comment.
@BBlack this is not POST issue, we are still using GET since POST patch was
never approved.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev
Cc: BBlack,
Yurik added a comment.
@bblack, for some unknown reason our SPARQL installation uses GET.
TASK DETAIL
https://phabricator.wikimedia.org/T126730
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Yurik
Cc: BBlack, GWicke, Bene, Ricordisamoa, daniel,
BBlack added a comment.
IIRC, the problem we've beat our heads against in past SPARQL-related tickets
is the fact that SPARQL clients are using `POST` method for readonly queries,
due to argument length issues and whatnot. On the surface, that's a
dealbreaker for caching them as `POST` isn't
21 matches
Mail list logo
