System Requirements - Logi Info
This topic presents the general hardware and software requirements use of Logi Info and the products and data sources it supports.
The following general hardware and software components are supported by the latest releases of Logi Info. Note that Logi add-on modules and related products may not support all data sources and supporting software listed below; refer to their introductory documentation for details.
- Chrome, Firefox: all current public versions (Certified)
- Microsoft Edge: all current public versions (Certified)
- Microsoft Internet Explorer: 11 (Certified); see note 3 below about earlier versions
- Safari, Opera: all current public versions (Supported)
Development, QA/Test, Production, and Disaster Recovery servers:
- Modern, high-speed CPU, with 4 cores, minimum|
- 8 GB RAM, minimum
- 100GB storage device
- 2 GB free disk space minimum (with .NET or JDK already installed) See the Sizing for Performance section below for more information.
64-bit versions of the following are supported:
- Windows Server 2016 (Logi Info v12+ only) |
- Windows Server 2012 R2, 2008, 2003
- Windows 10 (Logi Info v12+ only)
- Windows 8 (all editions except RT)
- Windows 7 (all editions)
- Red Hat, Ubuntu, CentOS, SUSE, and most other flavors of Linux
- Internet Information Server (IIS) 6.x, 7.x, 8.x|
- Internet Information Server (IIS) 10 (Logi Info v12+ only)
- Apache-Tomcat 6, 7, 8 (without Tomcat FHS)
- JBoss 4, 5, 7, EAP-6.3
- GlassFish (SJSAS) 2.1, 3.0, 3.1, 4.0, 4.1
- WebLogic 10, 12c
- Websphere 7, 8.5
- WildFly 8, 9, 10
Required for all development work, using Logi Studio:
Oracle has changed its Java usage policies - see Java Usage Policy for important information.
Logi Info can connect to, use data from, and in most cases write back to the following data sources:
- DB2 database server|
- Files: JSON, XML, Excel, CSV
- Google Docs, Google Maps
- HP Vertica
- JDBC-compliant database servers
- Microsoft SQL Server database server
- Microsoft SQL Server Analysis Services (OLAP)
- MongoDB (up to and including v2.6, but not later versions)
- MySQL database server (excluding v5.5)
- ODBC-compliant database servers
- OLEDB-compliant database servers
- Oracle database server
- PostgreSQL database server
- Progress OpenEdge database server
- Sybase database server
- Web Services (REST and SOAP) With the addition of supporting products such as Logi DataHub, many other online commercial data sources can be accessed. See each product's System Requirements or introductory documents for more information.
1. IIS must be installed before installing Logi products. Logi .NET applications on Windows and Logi Studio require the .NET Framework 4.6+. If not already in place, with your consent, appropriate versions of the .NET Framework are installed when Logi products are installed. They are also available for free from the Microsoft Download Center.
2. More information for Linux developers about Logi Java applications is available in About Logi Apps and Java.
3. While Internet Explorer versions 7-10 are certified for use with Logi Info v12.x, Microsoft has ended support for them and using them is not recommended. IE 5 and 6 are not supported. We recommend that you use IE 11 or Microsoft Edge for viewing applications built with Logi Info v12.x and later.
4. Microsoft ended support for .NET Framework 4.5 in January 2016. .NET 4.6 is required for Logi .NET applications 12.6+.
5. Use of Java 11+ supported in Info v12.6 SP2 and later, requires special configuration - see Java Server Configurations for more information.
There following are general sizing considerations for a Logi Info web application, followed by high level recommendations for server components based on these considerations. Specific recommendations will vary depending on your implementation.
Considerations To accurately determine the appropriate deployment model for your Logi Info applications, take the following into consideration:
Maximum Number of Concurrent Users - As with any system, the application needs to respond to end users in a timely fashion, even during peak load times.
Number of Concurrent Data Visualizations - The number of visualizations that are loaded concurrently into a page or dashboard will affect performance.
Data Visualization Complexity - Some data visualizations present a single metric and dimension, while others present multiple metrics and/or dimensions. More resources are required to render complex data visualizations.
Data Volume Needed to Generate Visualizations - Logi Info data visualizations range from simple, summary charts to interactive, self-service analysis tools. The volume of data required to be delivered from the data tier to the application tier to generate these visualizations can range from a few dozen records to tens of thousands of records.
Application-based Data Manipulation - Whenever possible, data manipulations, such as calcuations and aggregations, should be performed at the data server or system because they're optimized to perform these operations. In addition, the amount of data transferred over the network from the data system to the Logi application should be limited to the actual needs of the data visualization. When it is necessary to perform data manipulations in the Logi application, the type of manipulation
and the volume of required data will have an impact on the resources available.
Based on load-testing of benchmark data from our Large Enterprise customers, we have established the following recommendations:
A baseline, minimum number of required CPU cores is determined by the expected number of end users, as follows:
Baseline # Cores
1 - 100
251 - 500
501 - 1000
Using the minimum configuration as a starting point, the following factors will determine the processor requirements for your production environment:
- High Concurrency - If you anticipate end-user concurrency of greater than 10%, increase the number of cores by 25% to 50% of the minimum.
- Application Complexity - If you judge that your application is complex, based on the considerations presented earlier (e.g. high number of visualizations in a single page, complex workflows, and complex data processing at the app tier), we recommend that you assess the impact of that complexity on overall performance and sizing. It is not unusual to add an additional 25% to 100% of the baseline number of cores to ensure good performance.
- High Availability - Load-balanced, high-availability systems will required an increased core count. It's typical for large enterprises to deploy an additional 50% to 100% of the baseline number of cores based on the target service level.
In addition to the primary production environment, other environments should be appropriately sized as well:
- Development Environments - We recommend a four core minimum for any development environment. For environments with sophisticated development needs, such as a high number of developers, continuous integration development style, and test driven development, it's typical to size a development environment at 25% to 50% of the baseline number of cores, with a minimum of four cores.
- Quality Assurance and Load Testing Environments - Requirements for load testing or automated QA practices typically require a mirror images of the production environment, with the same number of cores in the same machine configuration, in order to accurately replicate production performance characteristics. If load testing is not required, then 25% to 50% of the production core sizing is ideal for more complex environments or automated QA, with a minimum of four cores.
- Disaster Recovery Environment - Some large enterprises require a stand-by system for disaster recovery. In this scenario, the Disaster Recovery system is typically a mirror image of the full production environment.
To manually determine how many physical cores your Windows server has, use the Windows Management Instrumentation Command-line tool (WMIC):
- On the server, open a Command Prompt window.
- Enter and run this command: WMIC CPU GET DeviceID,NumberOfCores,NumberOfLogicalProcessors
In the output example shown above, the server has two CPUs and four cores.
We recommend a 2-to-1 ratio of gigabytes of memory to CPU core (i.e. two GB of RAM per core).
Storage Logi Info applications are not memory-constrained because they leverage a hybrid caching (see The Logi Server Engine) mechanism that utilizes both disk- and memory-based storage when performing data acquisition, data aggregation, visualization generation, and other data-intensive operations.
Using the mechanism, a Logi application dynamically allocates storage resources depending on the processing stage in order to optimize their use. Therefore, we recommend that the server utilize dedicated, "fast" storage devices, such as SSDs or high RPM disk drives. Total storage usage is highly variable and is dependent on the size of the data volumes being processed and cached by the application. At a minimum, drives with a capacity of 100GB are commonly used.
Your production web server hosts your Logi applications, which run as extensions to the web server. Ideally, this computer should be dedicated to this task alone.
However, other configurations are possible, including those in which the web server also serves other functions (i.e. is not dedicated to Logi applications alone) and/or is also the database server. Some Logi large enterprise customers use multiple "clustered" servers for top performance and high reliability.
We do not have guidelines based on specific numbers of end users or applications, however, whether you choose to combine functions (web server, Logi application server, and database server) on one computer is, ultimately, your decision. Numerous factors external to your Logi application can affect this decision, including the amount of general web server traffic, the number of concurrent database users, the size of the databases, the complexity of the database queries, the frequency of access, and, not least, cost.
You may care to begin with a combined configuration and, as your report usage grows, change to a dedicated configuration. The nature of Logi products allows you to do this easily and often without additional cost (if CPU core count remains constant).
Recent studies concerning server virtualization suggest that database servers are frequently under-utilized. On the other hand, many database vendors recommend that their products be run on a dedicated server. You may wish to check with your database vendor for their recommendations concerning database servers.
Many organizations are using server virtualization to maximize hardware usage and reduce costs.
Server virtualization products allow the assignment of CPU resources to processes. This may take the form of a maximum percentage of combined CPU utilization, or as specific allocation of logical CPUs, to a virtual machine (VM). The server administrator is responsible for making these configuration decisions. Logi Analytics' product licenses treat a VM just like a regular, non-virtualized server.
In order to ensure good performance in any virtualized server environment, administrators must be careful to allocate appropriate resources to VMs.
It's not uncommon to relocate a VM from one hardware platform to another, for example, for hardware maintenance. The Logi license will "move" with the VM, as long as the machine name remains unchanged.
The Logi Analytics Platform and Logi applications can be bundled into and executed from container environments, such as Docker. Some of our customers have had success deploying their Logi applications in this manner.
Logi Professional Services staff may be able to assist you with such a deployment, for a fee. However, we don't recommend any particular container over another and we don't certify that Logi applications will work using a container.
Cloud-based hosting services, such as Amazon Web Services (AWS), can host Logi Platform components and Logi applications, though there can be some limitations depending on service features. Some of our customers have had success deploying their Logi applications to cloud-based services.
For example, if you'd like to try deploying your Logi Info application to AWS by yourself, this blog post from dbSeer may be useful. It includes a link at the bottom to step-by-step instructions. Note that we do not provide support related to this third-party blog post.
Otherwise, Logi Professional Services staff may be able to assist you with such a deployment, for a fee. However, we don't recommend any particular service over another and we don't certify that Logi applications will work on these services.