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!
> >
> 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?
> <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'?
>
> 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...
> Just 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.
> 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.
Michiel
--
Michiel Meeuwissen mihxil'
Peperbus 107 MediaPark H'sum []()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
