mattrolf at me
May 20, 2010, 6:08 AM
Post #5 of 13
(1375 views)
Permalink
|
On May 19, 2010, at 11:57 PM, David E. Wheeler wrote:
> The problem is that elements and fields are fetched separately for each container element. Say you have 25 stories you retrieve in a template via Story->list. If all you grab is the URI and title of the stories it's no big deal: That data is loaded when each story is fetched. But as soon as you get into elements it gets expensive.
Thank you, this is kind what I was expecting.
> Ideally, there'd be some way to tell Story->list to load all container and field subelements in the same query. So if I needed to sort on that event date, while Story->list() might lead to 75 queries, Story->list({ WithElements => 1 }) would lead to just one query.
How hard might something like that be to implement and test?
> So, if you just use the main attributes of a story (title, URI, description), it'll be pretty fast. If you need to get at any contained objects (source, categories, elements, keywords, etc.), you're going to incur the cost of a lot more database queries.
And presumably the more you've nested your elements, the more overhead you're going to incur as the number of queries rises.
Keywords is any interesting one to me. On the one hand, you've got Phillip who was able to do a moderate publish_another work without much issue using keywords:
http://www.gossamer-threads.com/lists/bricolage/users/34190?search_string=keyword;#34190
And John who saw Bricolage publishing thrash horribly under load doing the same sort of thing.
http://www.gossamer-threads.com/lists/bricolage/users/11070?search_string=caching;#11070
I wonder if it would make sense to optimize API calls to keywords, categories and sources separately or in a different way from the Element calls since those are "standard" asset objects and somewhat predictable in their construction.
In regards to this:
On May 20, 2010, at 3:19 AM, Zdravko Balorda wrote:
> I have worked with a very simple dynamic CMS so I cann't answer this, but I'd say
> Bricolage publishing shoudn't be much slower than any other dynamic CMS which does all this on the fly.
I think the key difference is that when you're publishing stuff in Bric, you can easily hit way more objects than a "conventional" dynamic site might. If you're asking for an element two levels deep in a thousand stories in a particular category three times in a single publish, and then doing something with the keywords, and then doing a complex calculation before you hand the data off to the autohandler, that's a lot different than a PHP site handing back a request for a single page.
Of course, Wordpress sites fall over and die every single day when they get hit by moderate internet traffic and someone isn't effectively caching. It's not like Bric has a monopoly on inefficiency, nor is it even inherently inefficient. The nature of Bric enables you to flat out *do more* than your garden variety CMS. Like anything else, this freedom can get you into trouble.
With any dynamically generated content, you're going to have to do the work somewhere at sometime, and no matter where you do it there's no single easy answer to streamline performance. One of Bric's great advantages is being able to output everything to static files, thus moving dynamic content generation to the backend where it's going to be hit by less users, and improving the scalability of the front end web site. But when things have gotten too slow on the Bric end the answer has always been to publish some sort of dynamic includes, be it flat file SSI or something more involved with PHP or Mason. For some instances, I think that is the right answer, but in other instances maybe it shouldn't be.
-Matt
|
