skwpspace yan pritzker’s home on the web

Thoughtworks Mingle: awesome idea, embarassing performance

I think that Mingle is one of the few bug and issue tracking products that understands how humans work - the key word here is context. While other bugtrackers (ahem, bugzilla) are satisfied with giving you little more than a list of rows from a database, Mingle allows you to create very powerful views using grouping and color coding so that you can drag and visualize your stories and bugs across releases, iterations, statuses, people, etc.

Sweet, but the performance sucks.

This is all great, except that its performance is downright embarassing. Now I might let this go if it were anyone else - but this is Thoughtworks. I know the guys over there are smart so why are they releasing such a hog into the wild? Hey I’m not the only one who thinks so - check out this comment thread on Mingle’s slowness.

There are more comments on Mingle’s own board about this and very little in response other than get more than 2 gigs of ram.

Are you kidding me? 2 gigs of ram for one user running a simple webapp? And then it tries to eat 2 of my CPUs when I change the status of a card.

To add insult to injury, they’ve obfuscated the source and made the whole thing run on jruby so now we can’t even take it apart and figure out what is causing all the suckage. And now some people are under the mistaken notion that RoR is at fault here.

Repeat after me: Ruby is not at fault. It’s Mingle/Jruby that sucks.

So what sucks about mingle? Well a 2 gig ram requirement. The fact that it takes an ungodly long time to start up (heavyweight java app container?). The fact that it leaks memory and after a day becomes unusable, causing even the slightest queries like changing a status on a single row to hang forever. These are not RoR problems. You’d have to try to get a simple webapp like that to run that slowly in any language, even BASIC.

Come on guys, you can do better! You have some great ideas in there, just step up to the plate and fix the damn thing. Or open source it and let others have a look.

Thank you.

as far as I can tell is a JRuby issue, not a Ruby or a Mingle itself problem. This is what happen when you explore new solutions (Ruby on JVM via JRuby). It takes courage and I support this kind of idea.

If it wasn’t for this kind of effort things would never improve (JRuby in this case)!

Yan, it’s good that you’re defending Rails and I agree that Rails isn’t entirely at fault here. Mingle runs on JRuby primarily because IS departments are more familiar with running Java applications than Rails applications and it’s important to make Mingle as widely deployable as possible. JRuby performance is being worked on — recent benchmarks place it 30% faster than MRI 1.8.6 and there are a bunch of full time developers at both ThoughtWorks and Sun Microsystems (and probably elsewhere) working on making it faster.

Some of your comments are a bit contradictory — you praise Mingle for being a great product that understands how humans work because it has “context”, but when you’re unhappy with its performance you say it’s a “simple web app” and should be easy to fix! Mingle provides amazing visibility and management for your stories but it does have to do a fair amount of bookkeeping under the covers.

Mingle performance gets better with every release and I’m sure is being actively worked on, and I’m glad you enjoy using it.

Hi Mike- I can see the reason behind using JRuby and I respect that. And I only write this rant because I love the product. If I didn’t care I’d move on to the next crappy bugtracker. The truth is Mingle has come closer than anything before in delivering value in this field, and that’s why I’d like to see it improve.

And come let’s not play games with semantics here. I do realize it’s not a _simple_ webapp but when I change the status on a bug and a couple queries have to happen that shouldn’t hang the machine or eat most of both cores of a cpu. Is that fair enough?

Hi Yan -

The current release of Mingle does not contain a memory leak. All users who had been reporting a need to restart Mingle on a daily/weekly basis have confirmed that the problem is fixed.

If you are using Mingle on a small team, you can configure Mingle to use a smaller JVM max heap size than the default 1024m. Change the value of maxObjects in config/web.xml to the number of JRuby runtimes you want. The default is 8 — the number represents the number of requests that can be handled in parallel. As you decrease this number you can in parallel lower the max heap size specified in the MingleServer script (assuming you’re using the *nix version).

Thanks for the tip David, I will give this a try. However, I am on Mingle 1.1 and still experiencing slowness. Whether it’s a memory leak or something else, I don’t know. All I know is after a day or so even the most basic request to change something on a story causes a huge cpu spike on the java process that just hangs there.

Will try these settings changes. I don’t know if the rules for jruby are different than for standard mongrel/ruby but running 8 processors seems like overkill (I assume this is equivalent to running 8 mongrels).

Assuming in the super worst case that your requests are all 1 second each that means 8 requests per second or 28k requests per hour. Show me an organization that does that many requests on their bugtracker that is a target for Mingle…

It should ship with 2-3 out of the box. That is more than plenty for most organizations. And my calculations were for _really terrible performance like 1 req/sec). I assume most actions will be cached intelligently and achieve performance 10-30x times that easily.

Please verify that you are using revision 5516 of Mingle via the About page (link in lower right corner.)