[11:02:55] o/ dcausse: you where right: Apps still use the action APIs, my apologies. Now I get numbers from webrequests. First sample: 3.x req/s of search session starts on en.wikipedia.org. I’ll broaden the time frame now. [11:03:59] p.s. There are definitely records from September, that came from apps and used the REST endpoints, however. [11:20:33] pfischer: no worries, thanks! [11:21:21] 3qps is definitely in the ballpark of what I would expect [11:36:38] lunch [13:43:30] dcausse: Alright, over 3 days in November, max: 4.1qps, avg: 3.3 (stddev: 0.44). So your estimates were spot on. :-) [13:43:58] cool, thanks for checking with actual data! :) [13:44:54] There’s another open question from ML regarding the expected query length. Can I extract that from the query logs somehow? [13:53:46] pfischer: from logs you might get very short queries, from what I understood the first query is going to be a page title [13:55:35] the model will get a prompt like "Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery:$query" this plus ~10 words should be the worscase scenario [13:55:50] hopefully the prompt will be mostly cached [14:02:34] from martin (https://phabricator.wikimedia.org/T404822#11189100) they're looking at queries with 8 words or more [14:03:19] but hard to tell what will be the query patterns here [14:04:38] from Erik analysis: https://phabricator.wikimedia.org/T404822#11220546 [14:05:13] note these are lexical tokens, the model will take wordpieces so likely higher (perhaps 2x?) [14:57:58] dcausse: Thanks! The search=title is only the case if the user selects one of the autocomplete suggestions. IIUC they may hit the search/enter button any time. [15:51:50] dcausse: I canceled todays retro blocker. [15:52:07] sure [17:10:03] dinner [18:41:05] taking dog out