常见问题
为什么我收到503错误，或者为什么我的请求很慢？
不过，有时候某个客户会不经意地设置一个非常短的轮询时间间隔，而这会向我们服务器发出的成千上万条请求，这时其它客户会发现系统变慢。为了对其它客户保持公平，我们不得不采用以下的QoS(质量服务)策略。我们这样做的目的只是防范客户在自动化软件上设置太短的轮询间隔时间，而不是想对正常用户进行限制。
下列限制仅适用于Trac、存储库以及共享驱动器请求。对帐户仪表盘的访问是没有限制的。
对于Subversion和Webdav HTTP(S)连接，所有的账户都限制在每分钟15个请求，但允许"爆发"到30000个请求。也就是说，当您的每分钟请求数超过15时，请求是从您的容量为30000个请求的容器里慢慢"借"出来的。当您的每分钟请求小于15时，多余的请求就会还给容器。当您的请求容器变为空，任何进一步的请求将被"降速"到每分钟15个请求。如果您在在容器变空以后继续试图从多个连接发送超过每分钟15个速率的请求，您将看到HTTP 503的错误代码被返回。解决此问题的办法是停止发送请求一小会儿，让您的请求容器有时间补充请求数。
上述的策略只有当您用自动化工具以高于每分钟15个请求的速度巡检我们的服务器时才会起作用。我们建议您将请求速率控制在每分钟10个或更少。另外您要注意Subversion常常用多个请求完成一个动作，所以您应假设您的软件每次巡检存储库时就会发出10-20个请求。一个简单的法则是如果您正在巡检x个存储库，那么就将巡检时间间隔设为x分钟。
Git和Mercurial在HTTP(S)上的连接具更高的效率，其结果是有少很多但成本更高的请求。因此，Mercurial的请求限制在7 rpm并允许爆发到15000个请求，而Git的请求限制在3 rpm并允许爆发到4000个请求。
在使用SSH链接上，每个账户每天(24小时)提供2000个请求数。如果超过这个限制，连接数将被限制在每2分钟3个请求，直到24小时结束时会自动恢复到2000个请求数。
We have created an API endpoint that lets you check your request count for the last 24 hours, so that you can monitor your usage. You may access it by going to
我们将密切观察这项策略的效果，如有必要我们会进行修改。如果您对该策略有何疑问和意见，尽管跟我们联系。
