• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

Alfresco Performance – High Availability versus Performance Options

You are here: Home / Alfresco / Alfresco Performance – High Availability versus Performance Options

November 28, 2018

TSG is currently working with one Alfresco insurance client with up to 17,000 users in a mission critical system where reliability and performance are paramount.  As part of our performance tuning, the client is considering turning off the Hazelcast component to improve performance while reducing fault tolerance.  This post will present the options for other Alfresco clients’ consideration.

Alfresco Clustering – What is high availability?

Alfresco, like any other highly available system, provides for clustering for redundancy as well as high availability.  As documented in the Alfresco documentation:

This scenario shows a single repository database and content store, and two Tomcat nodes/web servers on two separate machines accessing the content simultaneously. The configuration does not guard against the content store or database failure, but allows multiple servers to share the web load, and provides redundancy in case of a server failure. Each server has local indexes (in the local content store).

This is the simplest cluster to set up and is ideal for small-scale installations. A cluster consisting of two or more machines working together provides a higher level of availability, reliability, and scalability than can be obtained from a single node.

A hardware load balancer balances the web requests among multiple servers. The load balancer must support ‘sticky’ sessions so that each client always connects to the same server during the session. The content store and database will reside on separate servers, which allows us to use alternative means for content store and database replication.

Alfresco Clustering – Load Balancer and High Availability

The key to understanding high availability for Alfresco is to understand what happens when an Alfresco node goes down for any reason (hardware, network, connections….).  Alfresco leverages Hazelcast to replicate session information and various node/property caches from one node to the others in the cluster. In a true high availability environment, since a user’s session information is contained on all servers, any request from the user could be processed by any node in the cluster.

That being said, Alfresco recommends “sticky” sessions for a variety of reasons so that a user’s load is processed by a consistent node.  In a scenario when a node fails, the load balancer will point the user to the alternative node where all the information about the session exists.  Without the session information on the new node, the user would have to re-login and would lose any context that was stored in the session.

Alfresco Clustering – Performance versus High Availability

With clustering turned on, it isn’t difficult to imagine how the Alfresco node would process a request.

  1. Receive Request from User
  2. Read Session information
  3. Process request
  4. Write Session information
  5. Hazelcast caches information to other nodes for high availability
  6. Return control to user

During our performance review, we found that Hazelcast writes were fairly chatty between nodes and accounted for a 1-2 second performance delay in some cases when running with 2000+ simultaneous users.

Alfresco Clustering – Sticky Sessions and removing Hazelcast

For our client, the decision chosen was for the improved day to day performance by removing the dependency on Hazelcast clustering for some of Alfresco’s caches.  The performance gains that we have seen by using “invalidating” caches, rather than fully distributed caches resulted in 1-2 second improvements in response times, as well as a lower overall CPU utilization during peak usage. In the event that a node goes down:

  1. The user would be bounced from wherever they were in the application and have to re-login. In this case, our client had SSO and Kerbros, so there was no actual login screen in the case of an outage. The user would just see a full page refresh while they are re-logged in to the other Alfresco server and taken back to where they were since they are leveraging TSG’s OpenContent Management System that persists the user’s current context on the browser.
  2. Any updates that hadn’t been saved fully before the server went down (Property updates, Annotations…..) would have to be redone.

For the client, the above steps are exactly consistent with a network disruption or PC issue.  Given the low probability of a node failing and the simple user step to re-do session information for the client scenario, the client chose to go without Hazelcast.

Summary

High Availability with Alfresco can come with some performance degradation.  Clients need to analyze their risk of a fault and recovery versus the performance improvements. There are a variety of caches and combinations of caches that can be configured to help balance the decisions between performance and being highly available.

Filed Under: Alfresco, OpenContent Management Suite

Reader Interactions

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Alfresco – Viewing Annotations on Versions
  • Content Accelerator Labs – Document View Timeline for Efficient Content Navigation
  • Alfresco – Do More with Capture 2.0
  • Alfresco No Code – Do More with OpenContent
  • Alfresco – Do More with OpenContent Management Suite and OpenAnnotate
  • Alfresco Interface Options – Comparing OpenContent, ADF and Share – Summary
  • Print to Repository – OpenContent Print Driver Support
  • ECM 2.0 – Can you build it yourself?
  • Alfresco & TSG Webinar September 26th – Managing Claims Content Chaos
  • Claim Document Efficiency – How to improve customer experience and satisfaction.

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT