For consideration in the next week; at least to see if there are some concrete actions we can take to address such releases.

Does Picard seriously need that much data? 1.2MB of XML is returned there. Though of course, that's no excuse for us to be slow

Also, from the forum posts it appears most of the time is spent in the Amazon plugin? Here, the above URL takes 5 seconds, which doesn't add up to the >1min time between messages

The Amazon/cover art requests are irrelevant here - it's not where the time is being spent in this example. The forums discussion was after this was logged, so I guess that link is a bit of a red herring now as it seems that user's issue was to do with AMZ (which is also pretty borked for me ). I'll remove it from description to avoid further confusion.

In the Picard timestamps above there is nothing else happening between other than the XML parsing (which may be slow, given such a large document, to be fair); but that's 74 seconds.

If I open that URL in a browser, right now, it takes 49 seconds to return/parse, and I have a very fast PC, and one of the fastest connections it is possible to purchase in Singapore (100Mbit). Which implies that if it takes 5 seconds for you, that MB's bandwidth to a user in Asia is ~28Kb/s - which seems pretty bad to me. Perhaps that's also why the rest of the site feels slower to me than other people describe though!

I guess if it's not server time, it's not a generalized problem that can be addressed this week. How do you suggest we proceed? I see a few possible issues:

1) With analysis, ~1172 / 1223Kb (95.8%) of the XML data is work level ARs back to /other/ recordings - it's 50kB without these. Pretty sure the numbers are correct; I manually went through the XML and cut out these blocks. Nirvana is especially bad, probably due to the live bootlegs project, and likely a large number of unmerged recordings, however I'm not sure whether Picard uses these back-references, but given the impact they have - perhaps there needs to be a way to filter these work <- has performance of -> recording ARs out, but still get composer ARs and the like?

2) perhaps Picard may be able to request less (but I doubt it, if one wants to tag with composer ARs)

3) is compression still not enabled on MB servers due to CPU considerations? This should be ~111kB + transport overhead, with compression.

4) is the bandwidth to Asia really that bad? (I get an unstable 35->55kB/s on the DB dumps as a vague test - not sure what you get Ollie...?)

Ahh looks like compression on main site, but not WS. Possibly compatibility issues here with some HTTP clients I guess?

Created MBS-3168 for the compression part.