Edit Panel plug-in performance

by: Steve Celius

I’ve been doing some performance tuning on a large site recently, and one of the problems we had was that clicking pages in edit mode was quite slow. Especially when compared to just clicking around on the site in view mode.

When you click a page in the page tree in edit mode, a few things happen:

  1. The tree communicates with the other frames using javascript, telling them to reload
  2. The edit panel loads information and the tabs for the page clicked
  3. The preview frame shows the page in view mode

The important thing to be aware of – is that all edit panel plug-in’s are loaded and the code in OnInit and OnLoad is executed even though the plug-in is not shown.

So, by clicking a page in the tree, the plug-in might be doing lots of work unnecessary.

 

In my specific performance case, the plug-in was checking if it should be shown, by implementing the ICustomPlugInLoader interface. The code was calling a web service, which had contention problems, and consequently bad response times.

Additionally, the Load event in the same plug-in made a similar call to the web service, and the page itself made a third call to the service. Add a couple of editors to the mix, and performance went downhill from there.

Of course, improving performance on the web service helps, but of the three calls, only one was really necessary (the one on the page being previewed.)

So how do you prevent your code from running inside your plug-in before it is shown to the editor? PreRender! This event is not fired unless your plug-in is shown to the editor.

You will probably have to think about event order and where to put your logic, but just make sure to avoid the heavy lifting inside the Load event (or ICustomPluginLoader.List.)

Any control events on your plug-in (like button clicked etc) are fired before PreRender, so you can prepare data at this point, or just load initial data if this is the first view of the plug-in.

Note! You cannot rely on IsPostBack. It will always be true (clicking on your tab implies a postback.) Checking this.Visible in the Load event is also futile, it is True even though your plug-in is not shown (Visible is computed later on in the event cycle.)

20 August 2009

Tags:

Comments

  1. Great that you bring this up Steve. It's also possible to listen to the TabClicked event to see if your tab is being activated (We change the Visible property of the tabs before we trigger the event). You still need to check PreRender to see if the tab is the initial tab being loaded for the first page load. With this combination you can get the same knowledge/Functionality as with the IsPostBack property.

    Attach the event handler in OnInit:
    EditPanel page = Page as EditPanel;
     page.TabClicked += new EventHandler(TabChanged);

    protected void TabChanged(object sender, EventArgs e)
    {
    if(!Visible)
       return;
    PopulateTabContent();
    }

    And in prerender add:
    if (!IsPostBack && Visible)
       PopulateTabContent();

    Permanent link

    21 August 2009 10:48 by: Linus Ekström (linuse)

  2. Great post, Steve! Thanks!
    Permanent link

    21 August 2009 19:52 by: Daniel Berg

Post a comment    
User verification Image for user verification  
Steve Celius

About me

I work for EPiServer in Norway, mostly with technical stuff. Trying to keep up with all the new stuff from the development team. I also hang out on the EPiCode project, why don't you come join us?

You can also follow me on Twitter:

 

Number of visits to this page:
796

Top five pages on the site:

 

Syndications

Archive

Tag cloud

EPiTrace logger