Hi, Andr� van Toly wrote:
> I've had the same problem with the 10.000+ articles in NU.nl. Every news > article in NU.nl has an overview at the bottom with the latest � 50 > articles which are related to the section to which the article belongs. > So a listing would be something like: > <mm:list node="art_node_number" path="section,article" > orderby="article.created" max="50"> > We solved this problem by using constraints. MMBase seems to execute the > SQL constraints prior to selecting the articles. For example a list like > the following did the trick: > <mm:list node="art_node_number" path="section,article" > orderby="article.created" max="50" constraints="article.created > today > - 10 days"> > I don't think upgrading to 1.5.1. will solve your problem (cause you > know very well yourself we'll be using 1.5.1 for NU.nl ;-), but maybe > the above solution will. Ah, thanks for the suggestion... a quick look at some of the article->reply pages revealed that the "max" isn't used as it shows all the related replies without restriction... some pages have quite a lot of replies, and they are slow at the first load, but not as slow as sometimes happens with other pages... just for fun I debugged one of those pages and I clocked more than 1500 SQL queries for a single page *yikes* :) So maybe in my case the max-problem is in another part of the site... I guess I'll need to dig deeper into it... Or maybe there are any other known (performance) surprises with certain mmbase tags? > If only i had a similar solution for the editors... Finding an article > in the JSP editors is a pain in the ass. Every time i click on > 'article' in the JSP editors MMBase i can go out for lunch, cause it > first gets *all* the articles only to present me the 20 with the highest > object number. For some reason the SCAN editors are a lot faster but i > haven't found yet why. > > ---Cheers, Andr� > > > > At 21:45 +0200 09-08-2002, Ricardo Kustner wrote: > >> Hi, >> >> Gerard van Enk wrote: >> >>>>>> article. Could it be that this has a negative effect on the >>>>>> performance of mmbase? I've noticed this mmbase installation is >>>>>> extremely slow for an X amount of time after startup... >>>>>> Since all these records are related to something, the >>>>>> install_insrel table is quite huge too... >>>>> >>>>> If you don't have indexes on these tables things can be very slow. >>>> >> >> Ah I see, I'll check if everything is properly indexed. >> >> I checked and it looks like all tables are indexed... >> Even after running a postgresql 'vacuum' on all the tables, it is >> still quite slow at times... up to the point where it doesn't respond >> anymore and mmbase needs te be restarted. I'd probably be better off >> to upgrade this site to 1.5.1, but that's going to be a quite lot of >> work for sure... >> >>>> so in a few years time you'll get a huge amount of objects... it's >>>> nice to keep an archive of all old objects but the question is how >>>> long can it keep growing before you run into trouble? :) >>> >>> I don't think you'll run into trouble very soon (the vpro and eo both >>> are having an MMBase-Cloud with a couple of million objects in it). >> >> >> ah that's quite a relief... :) >> >> thanks for your insights... >> >> Ricardo. > > >
