I'm wondering if anybody has measured server loads when using CCK with i don't know, say 5-10 unique fields and the Views query with a common number of queries, like taxonomy, node type, date for example.

I'm not an expert on these things, and i know my question isn't very precise, but just in general - does using CCK instead of regular drupal nodes for example, and doing most rendering with Views, have any negligible effect on server performance ?

Thanks!

Comments

Nick Lewis’s picture

Generally speaking, yes: When cache is disabled, or overriden, using CCK and Views will have a negligible effect on server performance when compared with a *well written* custom module (and I emphasize "well written"). The reason for this is similiar to the reason why hand coded HTML/CSS (that's well written) is better than styles and markup generated by Dreamweaver's wysiwyg editor: when you hand code your database schemas and queries, you can optimize them to minimize the number of functions, you have to call for every page load. CCK and Views is database JOIN city -- which can spell trouble in MYSQL.

In one project, removing dependencies on CCK and Views reduced pageload times for listings of 10 CCK nodes with about 10 fields each from 4000-7000 ms per page load to 700-1500 ms per page load. That was with no cache, using drupal 4.7 sometime last July. [warning, I "benched marked"* these on my development machine with two sites setup on the local host]. Blue Marine displaying 10 page nodes of the same taxonomy term consistantly returned 400ms when I did this unscientific test.

Personally, I don't use CCK and Views is because its so hard to version control the pages and nodes they generate. And, their blackbox can be a real blocker when things go wrong. All in all though, most people should use CCK and Views because of shortages of developers, and the money it costs to pay them. The result will be better than attempting to code your own most of the time.

Not to mention, I'm guessing the performance issue can be almost completely solved by using cache (especially in 5.0).

Note
*this is an "unscientific" method.
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.onnetworks.com

--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.zivtech.com

deepak@dipak.org’s picture

I have recently started using CCK and views. I love it so far. I also had concern about the performance. My other concern is rather from a maintenance perspective - the increased number of tables in the drupal schema.

Judging by the "unscientific" results that were posted by Nick, the conclusion I'm drawing is that CCK and Views will definately have a noticeable effect on a large website. Using the above bechmarked results as a guide, most small website will not notice any performance loss.

Through Drupal catching into the picture and I think you pretty much get a page that loads like a regular node.

Deepak

luyendao’s picture

Thanks for the detailed reply, that's very good data - and i hope other people get to read this. I did have some concerns about CCK and the database structure, particularly for complex queries and so forth, it can be a real problem.

I'm surprised they would do it that way, since not only it seems to affect performance as you mentioned, but it does lead to some complexity down the road if you want to do anything with it in terms of coding or manipulation.

I'm at the cross-roads, where as a non-programmer CCK and Views seems really appealing to me, but it's always good to be wary when things are just 'point and click', the HTML/CSS example being a case in point.

Thanks for the input.

p.s. what did you use for your query timing, the devel module?