Sorry, been on vacation this week.
I'm not sure if memcached provides an easy way to see what's in the cache.
We don't have one. Sounds like memcached was the bottleneck, though, with
only 128MB of RAM allocated. I'd definitely recommend more.
Have you made changes since our last exchange, and if so, is it any better?
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Mon, May 7, 2012 at 2:53 PM, Alfred von Campe <alf...@von-campe.com>wrote:
> On May 7, 2012, at 16:56, Christian Hammond wrote:
> Memory and how much of it that memcached can use is crucial. We cache a
> *lot*, since fetching files from the repository, patching them, and
> generating diffs is all very expensive. So the more that memcached can hold
> at once, the faster things will feel all around.
> After that, you'll get some gains from database optimization and from
> increased CPU performance (for the diff generation).
> That's good to know.
> How big is your userbase, and what are your current specs? I know of
> servers with thousands of users that stand up under constant use. Usually
> it's just a configuration issue, or lack of memory for caching, that causes
> the most problems.
> A few dozen users and about 15 repos. It's on an older IBM xServer 335
> with a 3.06GHz Intel Xeon CPU and 2GB or memory with 128MB configured for
> memcached. I've only recently enabled memcached, so I'm not 100% certain
> it is configured properly. Is there a way to query it to see what it has
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at http://www.reviewboard.org/users/
> To unsubscribe from this group, send email to
> For more options, visit this group at
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at