North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Application versimilitude (was RE: PMTU-D: remember, your load balancer is broken )
> From: [email protected]: 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.
|