heh-heh ...
"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
news:3e631f79$0$6294$ed9e5944_at_reading.news.pipex.net...
> "Andrej Gabara" <andrej_at_kintana.com> wrote in message
> news:11a3a163.0302280636.2d9ccac4_at_posting.google.com...
> > "Telemachus" <tollg_at_tendwa.rns.net> wrote in message
> news:<Uen7a.12163$V6.16434_at_news.indigo.ie>...
> > > I have to say that post should be stapled to developers foreheads ...
> >
> > Ha :) That statement is almost as funny as
> > >>That was a relatively "I'm on your side" post from Sybrand<<.
> >
> > You're blessed by being naturally funny.
>
> It must be the gift of the Irish.
>
> <snip>
>
> > Here are some problems we are facing, and probably all that use the
> session
> > facade plus DAO pattern:
> >
> > (1) One of our customers installed our app server and noticed it's using
> > *only* 300MB in production. He asked us what he can configure in
order
> > for our app server to use the 4GB of memory that is available.
> [Nowadays,
> > a new server box ships with that much ram]
>
> I very nearly ended up with yet another unusable coffee stained keyboard
> after this one. The only possible answer is that 300mb is all it needs
(for
> his load at his site). Servers tend to come with at least 72gb of disk
space
> as well, did he complain that the software didn't come on 10 CD's.
>
> > So, obviously times have changed. Memory-conservation is not really
an
> > issue any longer. It's the opposite. The question is what can you do
> to
> > take advantage of this extra memory. Why conserve resources when
there
> > are plenty available and you can take advantage of it?
>
> Use resources when they add to the performance or reliability of your app.
> That is what they are there for.
>
> > The answer seems to be to cache more transactional data in the app
> server.
> > And if that duplicates some of the work the database is doing,
that's
> > ok! The customer doesn't mind if the app uses caching effectively to
> > improve performance and reduce load on the database, even when
> > some work is duplicated that the database is so good at.
>
> Why on earth is doing the same work twice a good idea? *Moving* the work
> *might* be a good idea - though I doubt it, duplicating should only be
done
> for very good reasons indeed - I have a big box with lots of ram isn't one
> of them.
>
> > In the end, it's not the design with the highest performance that wins.
> It's
> > the most elegant design that solves critical problems and has acceptable
> > performance. Over time, the thinking of what is acceptable performance
> > changes because cpus run faster and memory gets cheaper.
>
> Sadly its usually the design with the best marketing that wins :(.
Sometimes
> even when performance isn't acceptable.
>
> > Please no impolite replies from disgruntled Oracle DBA's, please! If you
> > have time to waste, go rebuild an index or whatever.
>
> Sorry if this seems impolite, but part of the reason for the lack of
> gruntledness tends to be that the DBA is held responsible (I think
> correctly) for the performance and scalability of the *application*. If
the
> app is poorly designed then its nearly always the database that gets the
> blame.
>
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
>
>
Received on Mon Mar 03 2003 - 06:21:02 CST
