| Issue 320: | queue and throttle incoming ssh commands from users | |
| Back to list |
git-upload-pack is a relatively expensive command, especially if the user is requesting us to create a pack for an initial project clone. Rather than creating a new thread to handle the request right away we should enqueue the request onto a work queue and process it only when there are sufficient resources to handle the request. For example, if our host server has 4 CPUs available to us, we might only want to service 8 git-upload-pack requests at a time, as each request uses almost 100% CPU until the object enumeration is complete, and then is bound by network and disk bandwidth limitations, as well as the SSH encryption overhead for each packet. Given how slow MINA SSHD is with the encryption, we actually are usually bottlenecked by the SSH encryption (and thus CPU) and not by network bandwidth to the client or local disk throughput.
Nov 10, 2009
#1
sop+code@google.com
Owner:
---
Nov 11, 2009
(No comment was entered for this change.)
Status:
Accepted
Nov 17, 2009
(No comment was entered for this change.)
Labels:
Milestone-Next
Nov 21, 2009
Change I4060182d0662594c0caea28b6915df1d3740aa19 Though right now the scheduler is strictly FIFO, which can be unfair when multiple users want access and one user has dominated the queue by injecting many tasks.
Status:
Started
Dec 16, 2009
I'm unlikely to come up with a more fair scheduler anytime soon. I don't want to put a lot of effort into this particular part of the system given how many other bugs we have open. So marking this as fixed for now since the basic original problem (queuing the incoming commands) has been implemented.
Status:
Fixed
Labels: -Milestone-Next FixedIn-2.1
Oct 21, 2012
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |