tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Mon, 11 Feb 2013 01:13:42 GMT
Hash: SHA256


On 2/9/13 8:01 PM, Terence M. Bandoian wrote:
> 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?

There is always a balance between a number of criteria:

1. Cost to run (CPU time)
2. Cost to build (programmer time)
3. Performance
4. Maintainability

IMO, issues #2-#4 trump #1 every time: maintainability is the most
important aspect of software design. If using JPA means that you can
maintain your software more effectively, then it is totally worth the
extra cost of CPU time.

Anyone who has ever worked at an outfit where there is some legacy
code that you can't touch because nobody understands how it works
knows that this is the truth: there is unmaintainable code that
someone wrote in the past and then left/got fired/died/etc. and not
the only options are a) leave the code alone forever in fear that it
will break if you touch it or b) completely re-write the code. If you
have some cowboy who writes thousands of lines of impenetrable JDBC
code, you have a recipe for code rot. Use of Hibernate, JPA, etc. can
significantly alleviate that because - at least for non-abandoned
projects - there are many people always looking at the code, and they
are experts in that code.

The 3000€ per annum is nothing compared to the cost of re-writing all
that legacy code, even if you switch from (e.g.) straight JDBC to
(e.g.) Hibernate or JPA. If you have to pay a consultant to do that,
it's going to cost you an order or two of magnitude more than the cost
of hardware: you can run more hardware for the lifetime of the
software rather than make a big change like that across all your code.

That said, when (or if) you run into performance problems, then you
have to decide whether you need to ditch the framework (perhaps just
for a portion of your code). We ditched O-R mappers for different core
reasons, but maintainability was the primary one: they all required
too many hacks at the time to make it worth it.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message