Dr. Blip's PC-Doctor Blog - Comments

fred.bertsch: A Theory of Scheduling Low Priority Work

nospam@example.com (fred.bertsch) — Wed, 28 May 2008 14:33:14 -0400

Isn't that great? But, you see, I've got a ton of work to do on this H project here. I can't do anything!

colin: A Theory of Scheduling Low Priority Work

nospam@example.com (colin) — Wed, 28 May 2008 13:49:40 -0400

I find it rather amusing that your referenced "L" project actually refers anxious customers that cannot wait for it, to another "L" project.

fred.bertsch: A Theory of Scheduling Low Priority Work

nospam@example.com (fred.bertsch) — Tue, 27 May 2008 14:36:13 -0400

That's very true. In fact, the trade off between time to market, quality, and features is a fallacy, anyway.

This is a great summary:

http://www.stevemcconnell.com/articles/art04.htm

However, it's fun to talk about it as though you can sacrifice one for the other without any repercussions.

Andy Koch: A Theory of Scheduling Low Priority Work

nospam@example.com (Andy Koch) — Tue, 27 May 2008 14:16:33 -0400

I would go further with that conclusion. Not only do you sacrifice quality, you also sacrifice time to market.

The inevitable result is that the workers of L must make decisions in order to keep working. Often these decisions are made with incomplete information, and these "best guesses" lead to delays as some percentage of them are incorrect.

Which creates a cycle since L is still low and still suffers lack of resources.

fred.bertsch: A Theory of Scheduling Low Priority Work

nospam@example.com (fred.bertsch) — Tue, 27 May 2008 13:46:09 -0400

Oooo. That's an interesting addition to the theory. You're saying that you were working on L and could have used resources from H, but, because they were such a pain to get, you made due without those resources. It seems obvious that the quality of the product at the end will suffer from this.

This is an aspect that I hadn't thought about when writing the article. Essentially, we've got the classic tradeoff between time to market, features, and quality. (E.g.: http://www.stanford.edu/group/scip/sirp/pilotsurvey.html) You're gaining time to market by sacrificing some resources that you can't easily get. In the end, you'll sacrifice some quality.

That's an interesting point. Thanks!

Andy Koch: A Theory of Scheduling Low Priority Work

nospam@example.com (Andy Koch) — Tue, 27 May 2008 13:33:21 -0400

well I feel better knowing there's a theory

Not sure if this was included in the theory, but I would add that if a project is perceived by others to be of a low priority then they will be reluctant to spend attention on L.

Thus, the few working on the L will find getting others attention difficult.

But, this is a problem of perception, because it may turn out that L has a critical impact on H. Not until H comes to a grinding halt due to L does L get the attention it should have had all along. Which is generally not good for L, since spikes in attention are usually a bad thing.

fred.bertsch: Nginx vs. Apache2 - in Rails Running Death Match

nospam@example.com (fred.bertsch) — Thu, 15 May 2008 17:26:10 -0400

Are you just speculating, or are you going to release the page fault numbers?

Benchmarks and speculation don't mix very well...

Andy Koch: Nginx vs. Apache2 - in Rails Running Death Match

nospam@example.com (Andy Koch) — Thu, 15 May 2008 17:21:10 -0400

no, you're wrong

Apache did run fine in the VM, but it's memory usage exploded when put under the stress of heavy load. I would expect similar results on any server, except that a more powerful server may be able to avoid a blowout.

My main point of mentioning the RAM size was that running 4 mongrels on such a system is a bad idea. Maybe 2 mongrels, 3 at most. But then the idea isn't to find optimal performance on this machine bu to get a perspective on which web server performs better as a front-end for my Rails app.

To that end, one could claim they're near equal - but when the Rails requests are simply or it's static content, Nginx is clearly superior.

fred.bertsch: Nginx vs. Apache2 - in Rails Running Death Match

nospam@example.com (fred.bertsch) — Thu, 15 May 2008 17:14:22 -0400

You give some clues about what might have been limiting the Apache server. You mention that either the server or the VM running on the server has only 512MB of RAM. You also mention that Apache was using a lot of memory and was swapping extensively.

If Apache isn't able to fit in RAM but Nginx is, I would have expected an even larger ratio in their speeds. Did you measure the number of page faults in the two systems?

The production machine your app is going to run on is going to get some reasonable hardware. I think you've only proven that Nginx uses less memory than Apache. While this might be interesting information for someone running a lot of VMs on the same box, I don't think it's interesting for your application.

fred.bertsch: Developing a New Framework

nospam@example.com (fred.bertsch) — Mon, 05 May 2008 14:29:48 -0400

Isn't that cool? I managed to write for waaaay too long without ever saying what the framework does or even what it's called?

Believe it or not, I actually cut stuff out of my posts before publishing them!