3 replies to this topic

[Marcher Technologies]

SELECT c.*, c.category_id as catid,r.*,p.*,itemmarking.* FROM ccs_database_categories c LEFT JOIN ccs_custom_database_1 r ON ( r.primary_id_field=c.category_last_record_id AND r.record_approved=1 ) LEFT JOIN permission_index p ON ( p.perm_type='categories' AND p.app='ccs' AND p.perm_type_id=c.category_id ) LEFT JOIN core_item_markers itemmarking ON ( itemmarking.item_member_id=1 AND itemmarking.item_app='ccs' AND itemmarking.item_app_key_1=c.category_id ) WHERE c.category_database_id=1
SELECT c.*, c.category_id as catid,r.*,p.*,itemmarking.* FROM ccs_database_categories c LEFT JOIN ccs_custom_database_2 r ON ( r.primary_id_field=c.category_last_record_id AND r.record_approved=1 ) LEFT JOIN permission_index p ON ( p.perm_type='categories' AND p.app='ccs' AND p.perm_type_id=c.category_id ) LEFT JOIN core_item_markers itemmarking ON ( itemmarking.item_member_id=1 AND itemmarking.item_app='ccs' AND itemmarking.item_app_key_1=c.category_id ) WHERE c.category_database_id=2

Seriously? this is additional load on every app multiplying by database..... can this be handled more efficiently? like... yknow, only where used?
This is with all hooks disabled in my debug footer..... why is this loaded in every app when Content is installed?

[bfarber]

Has nothing to do with item marking best I can tell. It's the call to getCategories(), which can occur from a number of places, and validly (generating the quick navigation, session callback, building the RSS output links).

Do you have IN_DEV enabled? If so, the rss_output_cache is rebuild on every single page load, which would explain this. With IN_DEV enabled, I have the same queries on every page (due to RSS as I said), and with IN_DEV off I do not, since the cache is not rebuilt on every page.

[Marcher Technologies]

Has nothing to do with item marking best I can tell. It's the call to getCategories(), which can occur from a number of places, and validly (generating the quick navigation, session callback, building the RSS output links).

Do you have IN_DEV enabled? If so, the rss_output_cache is rebuild on every single page load, which would explain this. With IN_DEV enabled, I have the same queries on every page (due to RSS as I said), and with IN_DEV off I do not, since the cache is not rebuilt on every page.

ok, then this is more of IPB feedback. when building an application(IN_DEV is obviously going to be on at that point) and weighing ones footprint, it is not helpful to have any cache being built on every page load, and is misleading, is it truly so hard to pop it from the ACP if needed?

[bfarber]

If you are trying to determine your footprint you MUST disable IN_DEV. Beyond certain caches rebuilding on every page (the app_menu_cache does as well), skin files are generated on-the-fly from the master versions. This is tremendously resource intensive. In local profiling, some pages can go from 1200ms down to 200ms easily simply by disabling developer mode.