Re: Oracle Web performance advert

[posted and mailed]

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in news:3c67db1c$0$8505$ed9e5944_at_reading.news.pipex.net:

>
> second per page request on average on a quad 400mhz intel machine with
> a gig of ram under a load of 600 users. That does not equate to saying
> that dynamic content takes 1/2 a second on average to render, it
> merely indicates how the benchmark application runs on specific
> hardware under a specific load. If one looks at ms for example they
> claim that the same app rewritten in .net runs a whole lot quicker.
> They are almost certainly right. None of this proves anything at all
> other than the performance you would get if your website were the sun
> benchmark and it was running on that specific hardware. This is why
> benchmark marketing is evil and insidious. It cannot possibly be
> applied to anyones actual on except in broad terms and with wild
> caveats.
>
> As to you last question I'd obviously prefer the second performance
> figure but what am I summarising on my hypothetical page 200mb of data
> or 450TB? and across how many variables? Did another user just request
> the same info or is each enquiry unique?

Good point - we all know reusing cursors ialready in the QEP cache is often a major go faster stripe. tricks like

and ( :1 is null) or (:1 = t.fieldname))

can reduce the number of combinations of possible queries in the QEP cache.  

Given that the advert was for the performance of java I expected that the performance was related to page generation and not related to the performance of backend queries etc.

IMHO things often break down something like this.

1. request parsing i.e. HTTP request into CGI etc.
2. determine what to do traverse url to detemine what to execute and how.
3. execute software required to render page evaluate components selected
4. display output perhaps with front end processor such as cocoon.

In some systems steps 1 and 2 can be very costly. I once remember doing some work with an early version of OWA where the cost of 1+2 was some 10 times more than 3. Rewriting some of the app code eliminated the confusion that OWA had and everything speeded up - without major application performance work.

My objective has been to get stepz 1+2 down to ~10ms or less and I am pretty sure we are getting there.

In step 3 I aim for around a 10ms overhead at most. Again I am pretty confident about outr getting there.

Given reusable connections, cached cursors etc the costs then become application related.

i.e.
Do you compile your components once and simply re-execute or do you have to recompile each time?
What overhead do you have for things such as compoent selection, configruation etc.
If you use reusable components what overhead do you have between component execution.

Different systems tedn to have models that differ enough such that content overheads etc directly affect the above.

In some cases I have aimed at taking what would be considered step 3 activities into step 2. An example would be a nav bar ala www.gojobsite.co.uk. In this example three logically abstracted 'buttons' are used within the nav bar. I used the same nav bar (static) component throughout a site but the buttons, links etc change as you move around the site as abstraction changes with location - with no overhead in step3 and very little cost in step 2.

Apples and oranges :-)

Jacqui Received on Mon Feb 11 2002 - 11:25:55 CST