Re: Scalability
We already have the ability to do diffs between revisions of the diff (just click the boxes in "Changes between rX and: ...") We store only the diffs to keep the size of the database smaller, and rely on heavy caching to prevent fetching from the SCM too often. -David On Thu, May 21, 2009 at 5:23 PM, Alexey Morozov wrote: > > Hi! > > On Thursday 21 May 2009 16:17:12 David Trowbridge wrote: >> At VMware, we have a couple thousand engineers working on a single >> server. Granted, I think it's a VM >> with 4GB of RAM and multiple vcpus, but it's still a single server. >> >> We've been addressing performance recently, and while it's pretty >> good, there's still more to do. MySQL >> isn't a big bottleneck--most of it is computing the diffs to display. >> I don't think you'll have any trouble >> getting 200 people up and running. > > Regarding the method to handle diffs. > > How do you think wouldn't it be faster if ReviewBoard internal data model was > slightly different? Instead of keeping patches it might keep entire source > and target files. In this case diffviewer job looks less demanding (now it > anyway deals with both files, and target file is produced by patch, which > isn't that fast, I guess). Also such data-model allows to see difference > between any versions of a changed file, not only between its "source" > and "target" states. This might be usefull to quickly see if a developer > actually put requested changes to a review being discussed. > > Best regards, > Alexey Morozov > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: Scalability
Hi! On Thursday 21 May 2009 16:17:12 David Trowbridge wrote: > At VMware, we have a couple thousand engineers working on a single > server. Granted, I think it's a VM > with 4GB of RAM and multiple vcpus, but it's still a single server. > > We've been addressing performance recently, and while it's pretty > good, there's still more to do. MySQL > isn't a big bottleneck--most of it is computing the diffs to display. > I don't think you'll have any trouble > getting 200 people up and running. Regarding the method to handle diffs. How do you think wouldn't it be faster if ReviewBoard internal data model was slightly different? Instead of keeping patches it might keep entire source and target files. In this case diffviewer job looks less demanding (now it anyway deals with both files, and target file is produced by patch, which isn't that fast, I guess). Also such data-model allows to see difference between any versions of a changed file, not only between its "source" and "target" states. This might be usefull to quickly see if a developer actually put requested changes to a review being discussed. Best regards, Alexey Morozov --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Re: Scalability
At VMware, we have a single server (with 4 processors I believe, but that's
not important) with about 4GB of RAM running a Review Board instance using
Apache and MySQL. It services over 2000 developers and connects to somewhere
around 15 repositories. We have almost 80,000 review requests on file. I
can't even guess as to how many reviews and diffs we have. Review Board has
been able to easily handle this load.
One of the important things is to make sure you have sufficient RAM and are
using memcached. We heavily cache rendered pages, diffs, and files coming
from your repositories in order to achieve maximum performance. The more RAM
you have, the better. At least to a point. 2GB worked pretty well for us for
a long time. We're using 4GB now, which is also working well and we haven't
come close to hitting it, I don't think.
The major bottlenecks are usually I/O-related. Database access and remote
repository access being the big ones.
If you do reach a point where the server can't handle the capacity, there
are things you can do.
A good start would be to move the database server to another system (or VM,
depending on how you're hosting this). Just transfer the database to another
server that Review Board can access and point to it in your
{sitedir}/conf/settings_local.py file.
Review Board can access multiple memcached servers, so you could always
spread that out to multiple systems to increase the amount of data that can
be cached.
Though I've never tried it, in theory you could have the Review Board
software on multiple servers with a round-robin set up for the DNS, and have
each access the same memcached and database servers.
There's a number of other things that could be done. Our entire software
stack is designed to scale. We get that largely for free by using Django.
The common database and web servers are designed to scale as well.
Assuming you have a decently configured server with enough RAM, I wouldn't
be too concerned about scalability right now.
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com
On Thu, May 21, 2009 at 2:04 AM, KunalG wrote:
>
> Hi,
>
> I am interested to know if RB has been tested for its scalability.
> Will a single server be able to handle around 200 or more developers
> working on different repositories ?
>
> Are there any other scalibility issues either by MySQL or any other
> thing for this.
>
> Thanks,
> Kunal
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
To unsubscribe from this group, send email to
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/reviewboard?hl=en
-~--~~~~--~~--~--~---
Re: Scalability
At VMware, we have a couple thousand engineers working on a single server. Granted, I think it's a VM with 4GB of RAM and multiple vcpus, but it's still a single server. We've been addressing performance recently, and while it's pretty good, there's still more to do. MySQL isn't a big bottleneck--most of it is computing the diffs to display. I don't think you'll have any trouble getting 200 people up and running. -David On Thu, May 21, 2009 at 2:04 AM, KunalG wrote: > > Hi, > > I am interested to know if RB has been tested for its scalability. > Will a single server be able to handle around 200 or more developers > working on different repositories ? > > Are there any other scalibility issues either by MySQL or any other > thing for this. > > Thanks, > Kunal > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
Scalability
Hi, I am interested to know if RB has been tested for its scalability. Will a single server be able to handle around 200 or more developers working on different repositories ? Are there any other scalibility issues either by MySQL or any other thing for this. Thanks, Kunal --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
