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 Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers