tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edson Richter <>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Wed, 06 Feb 2013 15:36:57 GMT
Em 06/02/2013 13:26, Jeffrey Janner escreveu:
>> -----Original Message-----
>> From: Christopher Schultz []
>> Sent: Tuesday, February 05, 2013 4:59 PM
>> To: Tomcat Users List
>> Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness
>> 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".

I've partially agree. The systems architect should be able to create a 
balance between maintainable code and performance. We can't crucify 
JPA/EJB, indeed bad use of JPA/EJB (as any other development library) 
would induce to problems. Developers, in general, create tests for their 
own, to check if the logic if fulfilled. But then, it is mandatory to 
have another phase with load test - and then, in this situation, you 
will find the problems of memory, CPU, disk, network overload.

In our case, any window that takes more than 0,250s (250ms) to popup is 
considered an issue, and must be reworked. That doesn't mean we need to 
write SQL on our own, means that the communication flow is wrong, or 
there is more information in the window than the user need at that point.

No matter what some could argue, nobody reads more than 50 lines of 
anything (customers, sales, products) per page. So why execute a query 
that returns 35000 objects? So, the architect must have in my these 
constraints and requirements and then give the vision to the 
programmers, so they could write efficient code.

As said, I partially agree. I do prefer to spend few bucks more than 
have an application that will take hundreds of thousands of 
(what-ever-your-money-is) to recover user confidence.



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

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

View raw message