achingbrain
commented
6 years ago The deployment is one replication master and a bunch of registry mirrors. The mirrors have an incomplete registry index while the replication master makes it's initial run & broadcasts the availability of new modules to the mirrors. During this time the mirrors will go off to npm and fetch missing dependencies, then add them to their local registry index. If npm is under load or fails to respond or 404s during this time it'll retry the requests which can be slow, and there's also a limit on how many concurrent requests each mirror will send to npm, all of which can lead to slow response times. Subsequent requests to the same mirror for the same module will be fast(er) as it'll come out of that module's IPFS repo.
One caveat is that each request the npm client makes is round-robbined to one of these mirrors, so requesting the same module repeated can have different response times based on if you happen to get directed to a mirror that has the module you are after.
A combination of these two things is why some requests take a second and some take considerably longer.
As the replication master gets further into it's replication run, requests to npm will become less frequent so it'll get faster, and before that's complete, the more each mirror gets used, the more modules will be available, so the faster it'll get.
I'll increase the connection pool size, it's probably on the conservative side.
alanshaw
Currently starting pretty slow and then getting slower and slower....