- Patrice Lamarque
- May 23, 2017
How to Properly Size Your eXo Enterprise Plus Subscription
We regularly upgrade our offerings to make them more readable and adapt to the needs of our customers. Despite this, our flagship offering, eXo Enterprise Plus, continues to raise questions from customers who have selected us, and want to ensure that the software and services they are about to purchase will meet both their service constraints and budgetary needs.
Those who are accustomed to SaaS solutions may assume that the cost of the service can be calculated simply by multiplying the total number of users by the unit price. It works differently for eXo Enterprise Plus subscription.
Content
As commonly seen for on-premise enterprise software solutions, it is priced per the number of CPU cores used in the infrastructure rather than per the number of users. This notion is not always obvious to non-computer literates, so it deserves some discussion.
1. About CPU Cores
A CPU core is a technical feature of the server that hosts your eXo Platform instance. Each server is equipped with one or more microprocessors (CPUs), themselves divided into cores.
The number of CPU cores implemented in a server system largely determines the number of requests (called the load) that it is capable of processing simultaneously.
For example, every time you reload a page on your intranet from your browser, multiple requests are sent to the eXo Platform server, which must process them before returning the requested content to your browser for display.
The more users that are connected to the system at the same time, the more requests it has to process. If the system does not have enough CPU cores to process all the requests it receives, the pages load more slowly, because the requests are queued until a CPU core is available.
Therefore, to have a good display speed for everyone, it is necessary (but not enough!) for the system infrastructure to have a number of CPU cores sized to support the user load.
Since each server usually has a limited number of CPU cores, your infrastructure team will have to allocate enough servers so that your users can enjoy an optimal quality of service.
2. Estimate User Load
In a nutshell, the more users you have to serve and the higher your quality of service requirements are, the more servers you will need.
Therefore, right sizing your servers and their CPU cores will not only help you get good performance, it will also determine your recurring budget for operating the service.
When debuting a product that you don’t know yet, and that will define new uses, how do you evaluate how much server capacity you will need?
The actual load that servers can support depends on many technical factors, such as network bandwidth or allocated server memory. These factors can generally be tuned by your infrastructure teams.
But in reality, the most important determining factor for the load is also the hardest to anticipate: the users. What will they do? Will they all adopt the tool immediately? Or gradually? Will they use all the collaborative applications available?
Let’s be clear: it is impossible to predict user load accurately. But you can fairly easily make a reasonable estimate of the load, and then use that to derive the number of CPU cores required. Below is a simple estimation method based on the number of concurrent users.
3. Analyze the Statistics of an Existing System
If you are replacing an existing system, such as an old intranet, you probably already have an asset that you can use to estimate your load: usage statistics.
By looking at the data history generated by a tool such as Google Analytics or AWStats, you should be able to find the number of average visits per day that the old system was receiving.
Calculate the average number of visits per hour and this will give you the normal load that the system will have to support at all times.
You will probably notice periodic peaks that are much higher than average. They usually occur regularly at specific time periods that correspond to an increase in activity in the company.
Often these are the first hours of the morning or just after the lunch break. But there can also be seasonal peaks or increased activity due to offers such as promotional campaigns.
In addition to the average load and peaks, look for trends. Is the number of visits increasing or decreasing? By following the trend curves, can you predict the average load or peaks in six months or one year?
In general, we recommend taking the highest value and increasing it by 15% to estimate the expected load for your new system.
This will give you a sufficient margin to absorb the peak of intense interest that is inevitably generated by the launch of a new service.
For example, if your previous system had to handle a normal load of 800 users with daily peaks of 3,000, plan a normal load of 920 concurrent users (800 + 15%) and peaks at 3,450 concurrent users (3,000 + 15%).
4. Estimate Load from the Number of Users
When you don’t have a past reference, you can start from the total number of users who will have access to the service.
If it is your intranet, start with the number of employees and take into account the turnover rates.
If this is a client extranet, ask the sales department for the size of the client database and its growth rate.
If this is a public site, reach out to your digital marketing team to evaluate the traffic targets for this new site.
Project that out for a year: this figure will be your theoretical user base.
From there you will have to extrapolate how many users will connect at any given time.
If you have no idea, we recommend the following approach. Based on our own observations of collaborative enterprise use, at any given point in time, approximately 10% of the total active users is connected simultaneously.
During peak loads, this connection rate can increase to 60%.
So if you have a theoretical user base of 10,000, it’s reasonable to expect a load of 1,000 concurrent users as your normal load and 6,000 as the maximum.
5. Calculate CPU Core Requirements for Production
Equipped with your user load estimate, you can now calculate the number of CPU cores required for your eXo Platform instance.
To make things simple, we have built a virtual abacus that estimates the number of CPU cores you will need for a particular user load on an eXo Platform system.
This calculating tool is based on a theoretical benchmark that we perform in our labs with each new version of eXo Platform.
Specifically, we simulate a typical collaborative activity of many fictional users. Different conventional usage scenarios are executed simultaneously by these virtual users.
These scenarios take advantage of all the eXo Platform collaborative features and are 90% read-only operations (e.g., viewing an article) and 10% write operations (e.g., posting a message).
In our performance benchmark, we measure the response times for each request. Thus, we have been able to establish that a system equipped with 8 CPU cores can achieve reasonable average response times (less than one second) for up to 1,000 users. Beyond that, response times increase.
Be careful, though: keep in mind that this benchmark is a theoretical gross value that represents linear use of the main functionalities of the eXo Platform.
In practice, your users will exhibit much more erratic use. But by applying a few reasonable safety margins, you can ensure that you do not under-or overestimate your needs.
For this reason, we recommend that you plan for at least one core per 1,000 users in the database.
Using the example above, 10 CPU cores would be enough to support the normal load generated by your 10,000 users. But for peak load response times for 6,000 competing users, 60 CPU cores should be available.
Using this abacus and considering your own performance requirements, you can easily start with your number of users and deduce the number of CPU cores you will need for your system in production.
6. Counting Additional Environments
You now know the number of cores needed to support the load that will be generated by your users on the production system.
But this will probably not be enough to do all your budget planning, because other environments will add to this number.
First, you will need to consider your service requirements. For example, do you need to ensure 24/7 availability? In general, this requires redundancy (doubling) of the production environment.
Similarly, disaster recovery plans usually require a mirror infrastructure that is identical to the production environment, and is maintained in a separate geographical location. In these cases, you will need to double your CPU core count.
Additionally, most IT operations teams require a pre-production environment to validate the proper functioning of any new deployment, such as updating or changing system parameters.
If, like most of our Enterprise Plus customers, you have a development team to perform customizations on your eXo Platform instance or integrations to your information system, you will also need other environments for activities such as user acceptance or development testing.
Finally, some integrations of your business applications within the platform will themselves impose an additional load that will also have to be considered.
As we’ve described above, pricing for Enterprise Plus subscriptions is based on the total number of CPU cores implemented.
We do not make any distinction as to their use. Whether it is a production server or not, whether it is active or standby, you are free to spend the authorized number of cores of your subscription license as you wish.
The only exception is that of developer stations, which still only count one core per station, regardless of the actual CPU power of the machine.
7. Confirm the Assumptions
The method described in this article should allow you to make a thoughtful estimate of the number of CPU cores you will need before placing your order for eXo Enterprise Plus. Do not hesitate to contact us for assistance refining your estimate.
We have been using this approach for many years and we know it works well. It makes it possible to quickly to get an idea of the budget for planning purposes.
However, don’t assume that this estimate will guarantee that the performance of your future system will be optimal.
Although the “abacus” is based on actual measures, it is just a tool for estimating a budget in advance, that takes into account only one of many parameters that affect the overall performance of a system.
Thus, once your system is installed, it will be critical to carry out your own load tests to check that it functions properly and to remove any bottlenecks that could interfere with smooth operations.
If you require assistance, our consultants have long experience in launching load tests, analyzing results, and helping clients optimize performance to achieve their goals.
After the launch, also plan to take performance measurements on the actual activity of your users to verify your assumptions.
If at any time it appears that the number of CPU cores in your subscription is no longer in line with your needs, contact us to adjust it to reflect your actual experience.
8. Wrapping Up
In summary, to properly size your Enterprise Plus subscription you will need to know the number of users on your system and your service constraints. As a reminder, here is a checklist of the steps you need to take:
1. Estimate the required user load, using
- Total number of users
- Normal load of simultaneous users
- Peak load
2. Calculate the number of CPU cores:
- Number of CPU production cores min = Number of concurrent users / 1,000
- Secondary production environments?
- Pre-production environments?
- Acceptance environments?
- Development environments?
- Business application integrations?
- Development posts?
3. Check your assumptions
- Load tests before launch
- Measuring real activity over time
- Periodic adjustments
eXo Platform 6 Free Datasheet
Download the eXo Platform 6 Datasheet and
discover all the features and benefits
discover all the features and benefits
- Tags: Collaboration
I am the product officer at eXo. I oversee product management and product marketing. My teams design, create and promote the features of and improvements to eXo Platform. As a former enterprise software developer turned product manager, I have a passion for how IT can improve people’s lives.
In this blog, I write about some of my personal interests, such as productivity, alternative forms of management and corporate organisations, collaboration, open-source and emerging technologies.
Related posts
- All
- eXo
- Digital workplace
- Open source
- Internal communication
- Collaboration
- News
- intranet
- Future of work
- workplace
- Knowledge management
- Employee engagement
- Employee experience
- Employee productivity
- onboarding
- Employee recognition
- Change management
- Cartoon
- Digital transformation
- Infographic
- Remote work
- Tips & Tricks
- Tutorial
- Uncategorized
Leave a Reply
( Your e-mail address will not be published)
The above shared article is really very good, it helped me a lot. Thanks for sharing.