[Distutils] PyPI Rate Limiting

[Donald Stufft]

On Feb 9, 2014, at 4:13 AM, Robert Collins <robertc at robertcollins.net> wrote:

> On 9 February 2014 19:28, Noah Kantrowitz <noah at coderanger.net> wrote:
>> 
>> On Feb 8, 2014, at 6:25 PM, Robert Collins <robertc at robertcollins.net> wrote:
>> 
> 
>>> 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.
> 
> As fast as possible (on the server side) and good service for all
> clients are very tightly correlated (and some would say there is a
> causative relationship in fact).
> 
> On the client side, I totally support limiting concurrency, but I've
> yet to see a convincing explanation for rate limiting already
> serialised requests that doesn't boil down to 'assume the server is
> badly written'. Note - I'm not assuming - or implying - that about
> PyPI.
> 
> -Rob
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

PyPI is a terrible code base that *is* pretty bad. There is an effort underway to make this better, but right now assuming that is a pretty safe bet :) It’s a really old code case (12 years or so) and has never had anyone on it full time so over the years it has accumulated lots of cruft and it comes from a time when web development practices were not very good.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140209/6840d599/attachment.sig>