tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject RE: [Seriously OT] Help in diagnosing server unresponsiveness
Date Sun, 10 Feb 2013 01:01:20 GMT
On 2/6/2013 9:26 AM, Jeffrey Janner wrote:
>> IMO, developer performance trumps runtime performance most of the time.
>> >So, if you can create a more maintainable system in less time by using
>> >EJB (or whatever), then you go ahead and do it: servers are cheap,
>> >while developer time is expensive.
>> >
>> >- -chris
> Chris, I'd like to differ with you on this last point.
> As someone who's been a developer, support person, and admin, I've got a pretty good
perspective on this subject.
> While servers may be cheap, they will never be cheap enough to overcome poor programming
practices. I've worked with systems so poorly designed that we couldn't purchase a system
big enough to run the software adequately, once you got above a handful of users. Yes, it's
gotten to the point where systems are much cheaper than they used to be, while developer salaries
are only increasing (supposedly), so wasting time on some minor performance improvement may
not be cost-effective. However, when you aggregate the time that hundreds of users spend waiting
on a response from a poorly designed, unresponsive system, I think you'll find that it trumps
the cost of having the developer spending a few extra minutes to "get it right the first time".

Generalized solutions, I think, include a substantial amount of code 
that isn't required for a given application.  The additional code 
affects performance but with the speed, availability and low cost of 
hardware, people seem to be opting for packaged solutions that don't 
require their programmers to understand the details of the 
implementation.  That seems short-sighted to me.

As an aside, I wonder if, at some point, the energy costs of inefficient 
code will come into play.  Don't wasted CPU cycles == wasted energy?

-Terence Bandoian

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message