RE: Application versimilitude (was RE: PMTU-D: remember, your load balancer is broken )

["Roeland Meyer (E-mail)" <rmeyer () mhsc com>]

> 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.