In another life, I did database management...which included creating a few that had more records than UO has any right to generate. None of them behaved like VS does unless there were structural or (far less often) hardware issues (unreliable connectivity or a dying HDD).
My guess is that the VS engine is trying to do too much at once: searching all the items based on keywords (multiple times?) and then caching all the item and multiple levels of location data (Geo, Vendor, subpack(s)) and whatever metrics, if any, they choose to track. Then that gets punted that to the client as a wall of text for it to generate the gump with. (I'd wager the CC gets all the same info the EC does, it just displays way less of it.)
So the server they put VS on
may be trying to handle way too many VS and non-VS things at once causing calls to time out along the way, but since these are supposedly on AWS blades, I find that really hard to believe. Unless they are housing it on the same C64 that runs the uo.com yoyo... Regardless, there is a
massive inefficiency somewhere.
Knowing that UO started as a hastily cobbled together flatfile and that shard settings were saved on easily broken in-world objects...
*shudders* I don't envy Bleak.
Exporting all vendor data to an external database (refreshed every 4 hours?) on its own server and then running in-game search through a stripped-down browser window might be a good alternative, assuming it could still generate the maps. That interface might be a way to reintroduce in-game email, a less clumsy IM system, and dynamic newspaper-like functionality as well...
Now that makes sense! Just like peculiar seeds! I hope you are correct! 
