On Feb 8, 2014, at 6:25 PM, Robert Collins <robe...@robertcollins.net> wrote:
> On 9 February 2014 11:15, Ernest W. Durbin III <ewdur...@gmail.com> wrote: >> Since the launch of the new infrastructure for PyPI two weeks ago, I've been >> monitoring overall performance and reliability of PyPI for browsers, >> uploads, installers, and mirrors. >> The initial rates will be limited to 5 req/s per IP with bursts of 10 >> requests allowed. Client requests up to the burst limit will be delayed to >> maintain a 5 req/s maximum. Any requests past the 10 request burst will >> receive an HTTP 429 response code per RFC 6585. > > 5/s sounds really low - if the RPC's take less than 200ms to answer > (and I sure hope they do), a single threaded mirroring client (with > low latency to PyPI's servers // pipelined requests) can easily it. > Most folk I know writing API servers aim for response times in the > single to low 10's of ms digits... What is the 95% percentile for PyPI > to answer these problematic APIs ? > If you are making lots of sequential requests, you should be putting a sleep in there. "as fast as possible" isn't a design goal, it is good service for all clients. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
