Michiel Meeuwissen wrote:
Nico Klasens wrote:
What my processors actually did was simply having a small static storage in
memory for those fields, and simply translate every change in 'don't change
it', and checks it on every get. One can find that an odd location, but it
is rather pragmatic, because it is shallow, and easy to implement.
iow, a quick fix :)
I know that in Java 'quick' is a bad thing, but I dare to be skeptical
about that!
It is not java related. WIth quick I mean: not well thought about
long-term robustness. It works for now, but can bite you in the future
An application with many quick fixes will get a bad reputation on the
long run.
MMObject.setValue(String fieldName, Object fieldValue) altready has such
a check. I don't know if this still works correctly.
Hmm, yes, I seem to recall that too. Could be that something simply doesn't
work well. I'll look into that.
We cache db-connections, don't we?
Yes we have a connection pool, but have you every looked how it is used?
A StorageManager is a wrapper around a connection. For every select we
request a new StorageManager from the factory which means get a new
connection from the pool.
But how bad is that? A wrapper costs only an object-instantiation, which
is better be avoided, but all-in-all we do very may anyway. Acquiring from
the pool itself is expensive too?
AFAIK acquiring a complete new connection from the database is expensive
any way, but that does not happen, does it?
Acquiring and releasing the connection to the pool requires synchronized
access. When many threads fight over a few connections then a starvation
will occur. An acqure and release for evey select will let a
http-request-thread fight for a connection each time. When the app does
500+ queries then it has to fight 500+ times for a connection.
<logger name="org.mmbase.storage.implementation.database"
additivity="false">
<level class="&mmlevel;" value ="debug" />
<appender-ref ref="logfile" />
</logger>
Just a side-note, but, assuming that 'logfile' is 'the' log file, is this
not a useless use of 'appender-ref'?
Of course, I put it in to show that it is handy to log it in a different
file
It is probably more then you would like I have seen many mmbase
applications in production doing 500+ queries to get one page.
Quite absurd indeed. It can get even worse, i've seen pages which did
something like that, and at the same time had the multilevel-cache-size at
300. Meaning that any page could produce hunderds of queries to the
database...
Yes pushing out its own queries :)
ust an example I came across this week in an article template
--------------------------------------------
<mm:node number="${elementId}" notfound="skip">
<mm:field name="title" />
<mm:field name="body" escape="none"/>
<mm:countrelations role="posrel" searchdir="destination"
id="secondaryContentCount" write="false" />
<c:if test="${secondaryContentCount gt 0}">
<mm:relatednodes type="article" role="posrel"
orderby="posrel.pos" searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="gallery" role="posrel"
orderby="posrel.pos" searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="faqitem" role="posrel"
orderby="posrel.pos" searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="newsitem" role="posrel"
orderby="posrel.pos" searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="page" role="posrel" orderby="posrel.pos"
searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="attachments" role="posrel"
orderby="posrel.pos" searchdir="destination">
</mm:relatednodes>
<mm:relatednodes type="urls" role="posrel" orderby="posrel.pos"
searchdir="destination">
</mm:relatednodes>
</c:if>
</mm:node>
--------------------------------------------
In many cases the article did not have secondary content. Without the
"if" the template executes 7 queries which results in many cases with
an empty list. All 7 queries are stored in the cache and push other
queries out of the cache which might have been more relevant. Of course
the "if" is a quick fix, but it will result in better usage of the cache.
I like the example. I think I would have tried one relatednodes on type
='object' with a constraint on type. Which would reduce the whole thing to
one query.
And you loose the order of the types. I left some code out which
required these relatednodes tags
I am convinced that you don't need a delayed update fix when you
optimize your application correctly.
You're certainly right that it is a foolish thing to do if you still have
pages which send 500 queries to mmbase any way :-) And otherwise it may
hardly ever by really needed indeed.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
