I also started seeing the symptoms described by Jonesey95 about a week ago on enwiki and the read/unread results on my watchlist remain essentially random now.

action=compare also appears to have no equivalent to diffto=prev to get a single diff content. What's the right way to get even a single diff of a page, where you only know a single revision id, without using the now-deprecated APIs? Are we supposed to request the page history first to get the adjacent revision ID?

I've only just become aware of this task. I use action=query&prop=revisions with rvdiffto=prev to get diff content for a number of revisions at once. Sometimes it returns notcached for a diff, but it's a good way of getting bulk diffs without imposing a big resource demand.

Okay then, so I'm guessing it's the GROUP BY / ORDER BY that are taking all the time, right?

Thanks for the logging_userindex suggestion. Using that table, then, what makes this so slow:

I've updated the wiki with some guidelines on how to get python3 working using this. The biggest problem seems to be that uWSGI mountpoints don't work with Python 3, but that's a uWSGI bug.

Yes, I guess that'd also work!

Or, in fact, even just reversing the order in which the --venv and --ini arguments are added to the args list would be good enough. If --ini comes first, then you can specify the plugin in the ini file, and then --venv will work.

On a little more investigation, it seems that --venv does work if --plugin python3 (or --plugin python) is also specified. Putting plugin = python3 in the ini file doesn't change anything. Perhaps adding this to modules/toollabs/files/tool-uwsgi-plain would be a workaround, though not very satisfactory:

Mmmmkay. I've put this in ~/uwsgi.ini:

I've followed the instructions above, and I'm reasonably confident I've done it as described. But when I try to start the webservice, I get this in the logs: