Modifying Telligent Widgets in a Load-Balanced Environment

Something to consider when working with Telligent Evolution is that when a site powered by Telligent Evolution is in a load-balanced environment site administrators may experience issues when configuring widgets if the environment is not set up correctly.

The reason for this is because each Telligent Evolution site on each of the boxes in the web farm has its own internal cache. Modifying a widget when in edit mode, saving the settings and then exiting edit mode may not necessarily result in the display of the updated widget settings, or even the display of the widget, because the end-user may be viewing the site from another box with application-cached page content.

I will mention here two solutions that could help to get around this problem.

The first potential solution is to enable sticky sessions on the load-balancer. A sticky session refers to the feature of most load balancing solutions for web-farms to route the requests for a particular session to the same physical box that served the first request for that session. Thus, the end-user would immiediately see the changes because the subsequent content that will be displayed for the page that he or she edited will be served from the same box in which the settings were saved. This box will by that time have relinquished the cache for the widget settings.

There is a drawback to this method if the site is protected by a content delivery network such as Akamai. This drawback is that the sticky sessions will be served to the content delivery network and there is by no means any guarantee that this will persist to the end user.

If the site is protected by a content delivery network then, if the amount of load that the box receives makes it practical to do so, you may want to consider lowering the value of cacheFactor in communityserver.config to a lower value and certainly no lower than 1.

This will have the effect of reducing the latency from the point of saving the widget settings and seeing the changes in the content served by the other boxes in the web farm.

There are two obvious drawbacks to this approach in that there is still potentially some latency in seeing the application of the new settings and increased processing power will be needed to maintain the lower cache threshold. This solution certainly should not be applied on a box receiving a very heavy load, even if it is protected by a content delivery network.


Author: Mobeen Anwar

Share This Post On

1 Comment

  1. We have a scenario – We are using KEMP for Sticky sessions(SS)- this tool write its own cookie to remember the user.if AKAMAI does not tamper this cookie, hopefully it should maintain SS. could you please put more light on – how its a drawback – “there is by no means any guarantee that this will persist to the end user” , and if any approach to solution…


    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *