Page History
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
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