@bking @dcausse @EBernhardson @Gehel @pfischer @RKemper @TJones would you please review and, as appropriate, edit https://www.mediawiki.org/wiki/Draft:ABaso_(WMF)/Wikimedia_Search_Platform/Decision_Records/Search_backend_replacement_technology by close of business Thursday, 25-July-2024? If there are things where you're not sure about editing but would like me to figure out how to word or resolve a tension, please by all means feel free to use the Discussion page on this Draft:ABaso_(WMF) page.

I've posted this at https://www.mediawiki.org/wiki/Draft:ABaso_(WMF)/Wikimedia_Search_Platform/Decision_Records/Search_backend_replacement_technology .

I'd like to be able to delineate logged out versus logged in (what is referred to as "editor status" in the parent task) as well. I believe the line charts can stay as is, meaning we don't need to have separate lines based on logged in versus logged out but it would just be nice to be able to click a button or two from the dashboard in order to check the metrics for a particular population. @Gehel any problem if I adjust the Title and Description of the task?

Thanks, the nginx logs are accessible on tools-proxy-7 and tools-proxy-8 for me now.

I remembered I should post this:

I'll set some time.

In T259883#9872704, @SNowick_WMF wrote:

Hi @dr0ptp4kt - I am still working on the abandonment rate queries, what I can measure is not exactly as your metric describes because we don't have a 'user enters some text' event (which would kick off autocomplete/suggest) - I can measure Search start events and search result clicks by unique session_ids.

Thanks @SNowick_WMF , just acknowledging receipt! Catching up on things, will circle back

In T365155#9851601, @xcollazo wrote:

I vote on setting the $wgXmlDumpSchemaVersion so that it applies universally. One consistent way to dump all around.

Here's the verbiage for the email.

The next steps are:

I scheduled a meeting tomorrow afternoon UTC+2 time with @Ladsgroup @daniel @xcollazo @Milimetric to troubleshoot.

Cool, thanks @SNowick_WMF !

Reopening, per face-to-face with @SNowick_WMF . Thanks Shay for taking time today to discuss!

@EBernhardson I was showing this today and we realized one more thing - would you please adjust the permissions for the underlying HDFS path to the data so that the analytics-privatedata-users group has read permissions? This should then make the dashboard viewable to all users on the cluster instead of just the analytics-search-users group members.

This is now marked as a Published Superset dashboard at https://superset.wikimedia.org/superset/dashboard/search . These dashboards are internally accessible.

Thanks @Aklapper

@Aklapper I'm not in a good position to triage this task, but have mostly cleared out #reading-admin.

Clearing out some old tasks that pertained to a different time.

Clearing out some old tasks that pertained to a different time. There is some level of access to some of these providers, covered elsewhere.

Clearing out some old tasks that pertained to a different time. Pageviews continue to be used in impact analysis and other types of analysis.

Clearing out some old tasks that pertained to a different time. Caching matters are covered elsewhere.

Clearing out some old tasks that pertained to a different time. Topic-based analysis is covered elsewhere.

Clearing out some old tasks that pertained to a different time.

Clearing out some old tasks that pertained to a different time. Support of technical volunteers is covered in other places.

Clearing out some old tasks that pertained to a different time. Maintenance expectations are covered in other places.

Here is what I propose for dashboarding. I've put this into "3 important metrics areas". In addition to expressing the ratios, provide the raw counts used for those ratios.

Thanks @bking!

I actually just added a link to https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update#See_also . Marking this here ticket as resolved after noticing it was still open.

The immediate term thing I'm checking is query density for WDQS, in particular for scholarly article oriented queries as part of the WDQS graph split.

I'm to have "3 important metrics" set for Erik's dashboarding.

Seems to be working.

Peter's on a WDQS task, Erik will take this after the Discolytics search metrics task.

Thanks @RKemper ! These speed gains are welcome news. We should discuss in a near future meeting if there are any further actions. I can see how we may want to set the bufferCapacity to 1000000 for imports, whereas we may want to just continue running with a bufferCapacity of 100000 once a node is in serving mode, but good topic for discussion.

Mirroring comment in T359062#9783010:

On the gaming-class 2018 desktop, although the bufferCapacity value at 1000000 sped things up as described on this here ticket, application of the CPU governor change did not seem to have any additional bearing (it took 2.47 days as compared to its previous record of 2.44). It's possible that the existing BIOS configuration of the gaming-class 2018 desktop (which was already set to a high performance mode) was already squeezing out optimal performance, for example, or something else about the processor architecture's interaction with the rest of the hardware and operating system is just different as contrasted with the data center server. In any case, it's nice to see that the data center server is faster!

And for the second run in T362920: Benchmark Blazegraph import with increased buffer capacity (and other factors) we saw that this took about 3089 minutes, or about 2.15 days, for the scholarly article entity graph with the CPU governor change (described in T336443#9726600 ) plus the bufferCapacity at 1000000 on wdqs2023.

In T362920#9776418, @RKemper wrote:

@dr0ptp4kt

we saw that this took about 3702 minutes, or about 2.57 hours

Typo you'll want to fix here and in the original: 2.57 days

Mirroring comment in T359062#9775908:

In T362920: Benchmark Blazegraph import with increased buffer capacity (and other factors) we saw that this took about 3702 minutes, or about 2.57 days, for the scholarly article entity with the CPU governor change (described in T336443#9726600 ) alone on wdqs2023.

Another thing that can be nice for figuring out stuff later is to add some timing and a simple log file. A command like the following was helpful when I was trying this out on the gaming-class desktop (you may not need this if your tmux session lets you scroll back really far, but it's kind of nice for tailing even without tmux).

@RKemper I think that's captured in P54284 . If you need to get a copy of the files, there's a pointer in T350106#9381611 for how one might go about copying from HDFS to the local filesystem and then there's other stuff in the rest of the ticket about the data transfer. I kept a copy of the files at stat1006:/home/dr0ptp4kt/gzips/nt_wd_schol so those should be ready to be copied over if that helps at all.

Following up from IRC, as I don't remember: @bking is there a patch needing review here? Or is this treated in a different ticket perhaps? If we should move it back to Ready for Dev, feel free to slide it back over.

For those following along, have a look at the comment in T358349#9727873 to identify the notebook helping to fill a table in @EBernhardson's namespace and an example Superset.

Updated AC to say daily where it incorrectly said monthly within the Preferred section. It already said "estimated daily unique devices" so was hopefully sufficiently clear, but still. Sorry!

@EBernhardson I had duplicated the verbiage "estimated daily unique devices, based on unique_devices_per_domain_monthly" (emphasis on incorrect "monthly" in Preferred section), but have now updated the Preferred section to say "estimated daily unique devices, based on unique_devices_per_domain_daily" to correct this glitch. I think you have this covered already, but just wanted to make sure the edit was obvious.

@EBernhardson I had duplicated the verbiage "estimated daily unique devices, based on unique_devices_per_domain_monthly", but have now updated the Preferred section to say "estimated daily unique devices, based on unique_devices_per_domain_daily". I think you have this covered already, but just wanted to make sure the edit was obvious.

Running time
Total Uptime: 55 min

I kicked off a run using the current version of the patch with the following command and backing table, and its status should be able to be followed here: https://yarn.wikimedia.org/cluster/app/application_1713178047802_16409

@EBernhardson I updated the AC.

Short run we determined that the following are the initial focus:

(Updated previous comment. Do this in conjunction with the other tickets, not necessarily afterward.)

@EBernhardson I updated the AC to capture the essence of IRC discussion and the what we went over in Etherpad.

@EBernhardson I updated the AC to indicate that this should only be specified where there is high confidence signaling.

@EBernhardson should we close this as a duplicate and move "(full text search, go bar, ...)" as a dimension aspect in T358352: Search Metrics - Number of user sessions using search?