Em 06/02/2013 13:26, Jeffrey Janner escreveu:
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, February 05, 2013 4:59 PM
To: Tomcat Users List
Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness
-----BEGIN PGP SIGNED MESSAGE-----
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.
Regards,
Edson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
