Home page logo
/

nanog logo nanog mailing list archives

RE: Application versimilitude (was RE: PMTU-D: remember, your load balancer is broken )
From: "Roeland Meyer (E-mail)" <rmeyer () mhsc com>
Date: Fri, 16 Jun 2000 00:28:26 -0700


From: rdobbins () netmore net: Friday, June 16, 2000 12:00 AM

snip<

Without doing performance analysis on the actual running code,
there really isn't a lot else to look at.

Shouldn't that be the first step in the optimization process?
 Finding out
if the code and the server itself are are operating as
efficiently as
possible -prior to- mucking about with the network (this
assumes a bit of
thought and planning and maintenance have gone into the
network beforehand,
so that there're no glaring, generic things which ought to be
fixed)?

Actually, this is simplistic. There are many cases where you have
either binary-only (as in the case of Oracle) or the code has
been thorugh the QA cycle and one is not allowed to touch it
(even if one is allowed, hopefully one would know better). The
same goes for a lot of the platform environment. We're talking at
pre-production staging here. All that is allowed is config
tweeks. MTU is a config tweek. The code should have been profiled
and optimized, to cost-effective limts, long before this stage,
in final integration test.

Knowing what your application(s) - or your customers'
application(s) - look like on the wire can be an invaluable aid
in the
code-optimization process, in my experience.

Yes, and you'd be amazed at the amount of "select * from *"
equivalents we've found.<g>

Of course, in a public environment, one's options are
restricted by the limits of currently-deployed-and-accepted
technology.

Not just the public environment. The development life-cycle has
point of measured restrictions as well.





  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]