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
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?
if the code and the server itself are are operating as
possible -prior to- mucking about with the network (this
assumes a bit of
thought and planning and maintenance have gone into the
so that there're no glaring, generic things which ought to be
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
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
Not just the public environment. The development life-cycle has
point of measured restrictions as well.