Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Orion Scalability

Thanks Matthias, these are good points. Would you mind incorporating this into the wiki doc? I have a note on scaling Git in there, but it is written in terms of describing a solution rather than describing the current problem. Maybe as you say there is something we can do in process for this, even if it is just rate-limiting to avoid the server failing in this case.

I wasn't even aware that clients needed to manually gc with JGit. Is that something EGit does periodically?

John



From:        Matthias Sohn <matthias.sohn@xxxxxxxxx>
To:        Orion developer discussions <orion-dev@xxxxxxxxxxx>,
Date:        07/18/2014 04:26 AM
Subject:        Re: [orion-dev] Orion Scalability
Sent by:        orion-dev-bounces@xxxxxxxxxxx




On Wed, Jul 16, 2014 at 5:26 PM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
The current state of Orion Java server scalability is that it scales reasonably well on the large instances we know about, which have 20-30K users, up to 500 active users on a given day, and up to 600 GB of user content. We are planning out the next phase of scalability to enable clusters of Orion servers operating on a few orders of magnitude larger install bases. The following wiki page outlines the work areas we have identified so far, with links to various related work items:

https://wiki.eclipse.org/Orion/Server_scalability

If you have experience with running large scale Orion instances we would love to hear your feedback on scalability issues you are seeing, and of course welcome any participation in the work to take us to the next level...
 

We ran some Loadrunner tests using an untypical workload (starting tons of git commands without waiting for them to finish)
and found that this way we can make an Orion server stop to respond. It seems there is no limit on the number of concurrently
running background jobs. This should be fixed by introducing such a limit (number of worker threads) and queueing up jobs
which can't be started immediately. This queue should have a maximum length and reject to accept new tasks if the queue
is full until the worker threads have completed a running task and the queue has an empty slot again.

Another missing maintenance task is to run git gc on all the git repositories to ensure good performance on git commands.
We could either teach jgit to auto-gc when a certain threshold on the number of loose objects is exceeded or we could add
a scheduled background job to run gc periodically.

--
Matthias_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev

Back to the top