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.