Dec 16 2019
The work needed to support this in scap turns out to be relatively straightforward.
Nov 11 2019
Nov 8 2019
Oct 22 2019
Oct 21 2019
Still doesn't work for me.
Sep 19 2019
Sep 18 2019
Sep 16 2019
Aug 12 2019
Jul 16 2019
May 17 2019
May 13 2019
SGTM. UIDGenerator::newUUIDv4() uses a good source of randomness, and the rate of API requests is on the order of <100k/s, so the probability of ever having a collision is incredibly small.
May 10 2019
May 9 2019
SGTM; thank you.
I just came across https://www.mediawiki.org/wiki/Extension:Wikidiff2/Release_process. @Legoktm, who handles this nowadays?
May 8 2019
It's not blocking anything; I wanted it for a set of representative benchmarks but I ended up settling for something less representatives (pairs of consecutive revisions from Special:RecentChanges of various wikis). It's probably not worth the effort to be more methodical at this point. Thank you (really!) anyhow for the willingness to help.
Apr 15 2019
Feb 21 2019
Feb 7 2019
I don't understand the preference for sampling Swift requests rather than Varnish requests. You'd have greater resilience to overload (for the reasons I cited above), and you'd have looser coupling and better fault tolerance by building on top of kafka.
Feb 6 2019
Feb 5 2019
The worry I had was this: a thumbnail that is requested once a minute on average probably has an approximately similar varnish cache hit rate to a thumbnail that is requested a hundred times per second. If that's true, then both thumbnails would be retrieved from Swift about as often, and they would be equally likely to have their expiry renewed before they're vacuumed up. This increases the risk of overload in case of a varnish cold restart or failure.
(It might have to be X% of access on varnish, since I assume the most oft-requested thumbnails enjoy a very high varnish cache hit rate. You could do this asynchronously by having a daemon that samples thumbnail requests from the varnishkafka stream.)
It seems that Swift has built-in support for object expiration, which can be requested by setting a header (either X-Delete-After or X-Delete-At).
It also looks like the expiry can be re-set, either by first removing it via X-Remove-Delete-At, and then setting it anew, or by updating the metadata in-place.
Is there a reason why these mechanisms are not under consideration?
What orders of magnitude are we talking about with respect to: total number of thumbnails in Swift, and number of thumbnail requests per second?
Oct 3 2018
Tim's rationale for the callback interface makes sense to me. Thanks for the explanation.
Sep 24 2018
I wonder if a callback is the right choice, particularly for the periodic mode. Presumably you'd want the processing of samples to occur after response data has been flushed, in a context that is healthy (e.g., you can make use of storage and logging facilities, and you are not on the cusp of hitting the timeout). But if the callback can be called because the sample buffer is full, then the call could come at any time, no? Wouldn't it be better to leave it to PHP code to call $excimer->getLog(), and have that return null if the log is empty?
Aug 27 2018
Aug 23 2018
Aug 15 2018
@Krinkle OK, that makes sense to me. As a lead-up to that, would it make sense to run a brief study in which we log an event when an event fails validation on the client? The code for logging of the 'validation failed' event could use an alternate, light-weight code-path so we don't end up wondering how many 'validation failed' events failed validation.
Aug 7 2018
I think that Nuria was right to press for an evidence-based rationale, and I haven't seen one.
Aug 2 2018
Jul 23 2018
It'd be nifty if you got backtraces from Lua, too. Luasandbox is about ~7% of wall time.