System Requirements

Hardware and Software Requirements

• CardioLog Analytics Enterprise Edition - it is required to install (a) CardioLog application on a dedicated server and (b) CardioLog database on a dedicated SQL Server instance***
• CardioLog Analytics Standard & Professional Editions - to ensure optimal operation, it is recommend to install (a) CardioLog application on a dedicated server and (b) CardioLog database on a dedicated SQL Server instance***
• The installer prerequisites can be found here

Inspect the following table to assure that your system meets the minimum hardware and software requirements. These system requirements apply to daily operations of CardioLog Analytics and do not include any custom actions, such as product upgrades, migration tasks, importing IIS logs, executing scripts provided by Intlock etc. These type of actions may require additional resources. Please note that executing custom scripts against the CardioLog Analytics database is not supported.

*   This refers to hardware allocated for the CardioLog application pool and services, not for the CardioLog SQL server

**  Up to 1,000,000 SharePoint content items and/or 2,000,000 events per month.

*** The CardioLog application and database can be installed on-premise on physical servers or virtual machines, or hosted on Microsoft Azure virtual machines (which meet the above hardware and software requirements). When hosting CardioLog Analytics on Microsoft Azure virtual machines (IaaS) and tracking a SharePoint on-premise farm, a site-to-site VPN is required.

Note: Intlock supports merely products and/or solutions within third party vendor’s Mainstream Support policy, including but not limited to Windows (OS), Windows Server, SQL Server databases, browsers, etc. Intlock support for products and/or solutions under third party vendor’s Extended Support policy, might requires further efforts based on professional services, which will be priced separately by Intlock upon Client’s request. Intlock at its sole discretion might not provide any support services whatsoever to any third party vendor products and/or solutions that are not being included under third party vendors' Mainstream or Extended Support policies.

The amount of resources needed and the time it takes for the CardioLog Scheduling Service jobs to complete depend on -

• Number of content items (websites, lists, list items, documents etc.)
• Content size
• Number of events (traffic) 
• Number of scheduled reports
• The timeframe for the reports (yearly reports demand more resources then reports for 30 days)
• The number of widgets per report

Importing large websites that consist of millions of items, user information for hundreds of thousands users, and generating hundreds of daily reports will consume most of the CardioLog application server resources. The import process for large environments may take a few hours up to a few weeks, depending on the import method (direct database access vs. API calls), import mode (full vs. changes only) and the environment size.

The more resources allocated, the better. 

 

Database Sizing

Hard disk allocation depends on the size of the monitored environment and the level of activity taking place in the portal. Additional factors that should be considered are backup and clean-up policies, and the amount of data accumulating over time. For example, an installation with 10 million usage events per month requires a total disk space of about 600 GB for a single year of data.

In practice, the estimated database size depends on the size of the CardioLog event tables. The following formula depicts the sizing calculation for the database:

Sd = Srd × Nu × (Ns + Nsr + (Ne × 2)) × P

Where:

Sd = estimated size of the database

Srd = average size of data per event (5 KB)

Nu = number of users in the monitored environment

Ns = average number of search operations per day per user (each search operation generates 1 event)

Nsr = average number of search results clicks per day per user (each search results click generates 1 event)

Ne = average number of non-search operations (views, duration) per day per user (each non-search operation generates 2 events by default)

P = length of the monitoring period - in days