Forums / Developer / Nearly Impossible: Caching of admin interface

Nearly Impossible: Caching of admin interface

Author Message

Georg Franz

Thursday 22 December 2005 5:16:45 am

Hi folks,

I've noticed that there are no active cache-blocks in the current admin pagelayout.tpl.

Problem: 500+ sql queries at 1 page request, over and over again, cause not much is cached.

I tried to add some cache-blocks and noticed that I can't use them because they prevent that the site works properly. (Example: All urls are changing if you go to the "browse mode" ...)

I've learned: To cache the admin site properly you need a lot of time to rewrite some templates ... (And I don't like the idea rewriting / overwriting admin templates ...)

So, my questions:

a) Has somebody done this work already?
b) Is it really a good idea to add cache blocks? (Over-use of cache?)
c) Is there a simpler/other way doing this job?

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Gabriel Ambuehl

Thursday 22 December 2005 6:32:18 am

Caching seems to be pretty efficient to me already. I see page load times of less than half a second when view cache is on?

There are some issues with BIG sites though but thats because of the complete tree loading each time and can (partly at least) be resolved by using one of the AJAX menus.

Visit http://triligon.org

Georg Franz

Thursday 22 December 2005 6:52:31 am

Hi Gabriel,

I am already using the Ajax menu at some sites ... it helps a lot, but there are also 300-500 queries / page request though ...

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Paul Forsyth

Thursday 22 December 2005 7:34:26 am

I've cut down the admin a little which actually gives some screen space back to the user. The admin runs will almost everything on but you rarely need this.

Paul

Xavier Dutoit

Thursday 22 December 2005 7:34:38 am

Hi,

How do you get 500 queries per page ? Is that the number on the debug output ?

On all the pages once they are compiled ?

I'm quite surprised by this number. Could you detail so I can compare with one of my install ?

X+

http://www.sydesy.com

Georg Franz

Thursday 22 December 2005 10:28:59 am

Hi Paul,
hi Xavier,

@ Paul: Good idea, i will do something similar.

@ Xavier:
All caches are turned on, template compiling too. 500 queries happens at 3 of my sites which have more then 2000 pages content, one site has over 10.000 pages. Most of the queries comes from the menu. You can't cache the menu easily because of the role system and the changing links ("normal"/"browse mode" ...) And there are the individual settings for each user (list amount, bookmarks etc.) ... I think ez removed the cache blocks at the admin site because of a possible "caching overkill" (too much cache files ...)

If I use a simple cache-block around the menu, there are around 100-200 queries left - uncached. (Depends on the page of course.) In my eyes it should be possible to cut down the query amount to 20-50 on a cached page.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Gabriel Ambuehl

Thursday 22 December 2005 10:32:35 am

But if you were to use some AJAX menu, it shouldn't fetch very much unless you've got a big part of the tree open, no?

I would think that wrapping the menu in a cache-block that depends on the UID would work quite well.

Visit http://triligon.org

Georg Franz

Thursday 22 December 2005 10:46:26 am

Hi Gabriel,

500 queries even with the Ajax menu. (I wouldn't believe this first either, but i checked the debug output ...)

The problem at the menu caching:
-) You need a unique menu for each user
-) You need to check the settings of the user
-) You need a menu for "normal links" and for "browsing mode" (probably even more)

All in all: The user has too much "individual possibilities". I think the best way is to reduce the features as Paul suggested.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Paul Forsyth

Thursday 22 December 2005 3:49:49 pm

I wonder if its then wise to simply cache per user and hope that the extra filespace required is ok. But then you hit regeneration issues which simply wont scale with multiple users.... grrr.

I recently added role support to the ezodcsm extension for menu popups, which i committed to pubsvn. This will increase the sql requests per node because of the permission checks in the templates but perhaps after caching it may help. With such checks i can restrict what the popup menu contains.

I use the popup menu in other areas to help restrict functionality. For example on the big class icon i have a setting to hide or show the window controls (Relations, Locations, Translations...). By default they are off. If the user doesnt have permissions they dont see the option.

To be frank the admin needs to be customisable per user per role. If im editor i dont want to see webshops, etc.

If i may diverge, another thread discusses this type of optimisation:

http://ez.no/community/forum/general/ez_speed_optimisation_faq

Is there a way to combine the findings from this thread to that one? Everyone of us hits these problems time and time again.

Paul

Georg Franz

Friday 23 December 2005 3:46:01 am

Hi Paul,

yep, my fear is that too much caching will bring down the server at the cache regeneration process. (We've discussed similar topics already some time ago.)

In my experience, there are mostly 3 types of admin users:
-) The editor - He only need a quick tree menu to navigate. He is creating / editing / deleting content.
-) The chief editor: Sometimes he moves content. He could need e.g. the popup menu functions.
-) The admin: He needs the complete functionality of ez. Probably he is the only one who uses them too.

So in many cases it's not necerssary to give a normal editor admin access. I made "edit" templates for the normal editor on the user site and provide "new/edit/delete" buttons. The biggest advantage: You dont have to teach the editors a lot, cause it's very simple.

---------------

Optimation Forum:

Paul, you are right, the "speed up" topic is coming over and over again. Maybe its a good idea to made a own forum for this topic and move the belonging postings there?

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004