For the past several years, Thorn Technologies had been hired to design and host the mobile website of a very large U.S. Tax Preparation company. This mobile site was built with the Grails Web Application Framework and used the Weceem Content Management plugin. On average, the site received over 100,000 hits per day – significantly more during tax season. There were some lessons learned deploying this high traffic site that we are happy to share.
Why We Chose Grails & Weceem
The Weceem CMS plugin for Grails was an excellent choice for this project. The site required a significant amount of custom coding to integrate with company’s enterprise backend services for features like scheduling appointments, finding an office, and creating accounts. For this reason, we were very happy to leverage the rapid development power of Grails and the Spring infrastructure upon which its built. However, the end user needed the ability to login and update their static content with a user-friendly WYSIWYG editor. This capability is provided automatically with the Weceem plugin and required no effort to setup and configure. The Weceem plugin doesn’t have all the glitz and glamour of a full blown CMS like Drupal or even WordPress. Consider it more of a “developer’s tool” instead of a full blown CMS product. If you want to make it look more professional, you can easily replace the default Weceem screens with your own and still leverage the underlying Weceem Service to handle content management. For this project however, the default Weceem pages were more than sufficient and allowed us to have the site up and running quickly and easily.
The power of Weceem Templates saved us a considerable amount of time building the site. All of the menu pages in the entire site are generated automatically using Weceem templates. As long as we organized our page layout with the appropriate hierarchy, the menus would automatically link to all child pages in the hierarchy. It literally required 5 lines of HTML with one GSP tag provided by Weceem to generate every single menu in the entire site. A sample of this template code is shown below. Line 23 shows the Weceem GSP tag that gets each child node of the current node (the current page). This node object is stored in a variable
c, which is then used on lines 25 and 26 to build the menu item.
Production Server Setup
In order to handle the heavy traffic load, we setup a total of 3 separate Linux servers (they were actually VMs) each running their own Tomcat instance. Two of the servers were used as the “Production Environment”. These servers were fronted by Apache using the mod_balancer module to load balance the traffic. This was incredibly helpful when we need to update the WAR file due to new features or integration efforts outside of Weceem. We were able to use the mod_balancer interface to stop traffic to one server so the WAR file could be redeployed. Once updated, we would repeat the process with the other server. In this manner we were able to push updates to production software without ever experiencing a loss of service.
The third server was used as the “Stage Environment”. Users were able to login to the Weceem User Interface in this environment and make changes or additions to their page content. We used Apache to proxy requests to Tomcat, which also allowed us to create a
stage.hostname.com URL so users can view their content before pushing it live. Once they were happy with their content, they could push the content to our production environment using a custom script we wrote that would synchronize database content between the stage and production databases. As a performance feature, Weceem heavily caches database content. So the content was not immediately available upon pushing to production. Most of the time is was acceptable to wait for the cached content to expire before seeing new changes. However, we did add a custom feature to wipe the Weceem cache if we needed the changes to be applied immediately. This setup provided a clean separation between work “in progress” and “live content” and reduced the risk of making unintentional changes to the production environment.
Potential Issues with Weceem
There were definitely some issues that you need to watch out for when using Weceem. Most obvious is the considerable amount of Java PermGen memory space that Weceem requires. Weceem pages generate GSP tags from strings defined in templates or entered by users in the editor. This generates a significant number of dynamic classes which can potentially lead to
java.lang.OutOfMemoryError: PermGen space exceptions. For the most part, we were able to avoid this problem by increasing the amount of PermGen space available to the JVM running Tomcat. This was done using the following JVM command line arguement:
-XX:PermSize=128m -XX:MaxPermSize=192m. Even with this change, we still experienced the OutOfMemory exception from time to time. It seemed that the Weceem Admin User Interface screens (not the final rendered page content) was the primary cause of this problem. Due to our stage and production server setup, these issues were thankfully limited to the Stage environment only.
Thorn Technologies is no longer maintaining this mobile website. Due the sharp increase in smartphone and tablet usage, the company realized the priority and significance of their mobile site. They have recently taken over control of the site and maintain and operate it in-house using their proprietary CMS. Nevertheless, the environment described above has proven to be rock solid and easily capable of handling several million hits a month. We can say with absolute certainty that web sites built with the Grails framework using the Weceem plugin can be stable and suitable for high volume production deployments.