System Requirements
This topic describes the system requirements for ReadyAPI VirtServer. For information on ReadyAPI requirements, see ReadyAPI System Requirements.
VirtServer now uses OpenJDK 17.0.15. The VirtServer installation package for Windows and Linux automatically installs the appropriate Java version. We recommend using the Java version bundled with VirtServer. The Platform Independent (Zip) version does not come with bundled Java; you will need to download and install this.
If you use a binary package, download the same version as supported in the product and install it manually. You can download the needed package from the following website:
We also recommend you update JAVA_HOME to reflect the correct installation folder for the Java version.
When ReadyAPI and VirtServer run, they pass several parameters to the Java virtual machine to prepare the environment. You can modify these parameters according to your needs. This may be required to extend the system memory available for SmartBear API Test products (ReadyAPI, TestEngine, and VirtServer). You can read more about this on the Modifying JVM Settings page in the ReadyAPI documentation.
The following is formally supported by SmartBear including technical support. We do not maintain support for non-listed operating systems or platforms.
Java:
Java is bundled with installers except for platform-independent downloads.
Version required when running platform independent (including MAC): latest Adoptium JDK LTS.
VirtServer 3.16 is bundled with JDK 17.0.6.
Browsers Supported:
The latest stable versions of Edge, Chrome, Safari, and Firefox.
OS Supported:
Important
On RHEL 9, the freetype library is a prerequisite for the installation of <ReadyAPI/VirtServer>. RHEL 9 and VirtServer do not include the library by default. Run sudo dnf install freetype to install the latest version. Ensure you have sudo privileges to complete the installation.
Windows versions that receive mainstream enterprise support from Microsoft.
The latest LTS of Ubuntu Linux.
Mac M1, amd64 on the latest version of macOS.
Docker, the Latest LTS release.
VirtServer maintains a default thread pool size of 200 threads, exclusively dedicated to supporting virtual service traffic. This means the product can concurrently handle 200 virtual user transactions.
In the ReadyAPI virtual services Behaviors tab, you can configure the min and max threads. It is advisable to configure these threads to align with your expected virtual user count. Typically, the minimum threads range from 5 to 20, while the maximum threads should be set to reflect your expected thread count. It is recommended to set the max threads at an absolute maximum or within the range of 180-190 to avoid potential thread-conflict errors.
We recommend setting up your VirtServer instance and configuration and running tests in a Proof of Concept. You may need to modify the settings, and this will allow you to validate your actual requirements and determine the optimal configuration based on real data.
Can I change the thread pool size?
Yes, you can adjust the size using a VM option to align it with the power of the machine in use. The VM option is soapui.threadpool.max and sample usage is -Dsoapui.threadpool.max=1000 (to achieve 1000 threads). This option is documented here.
Be cautious, as increasing the thread pool significantly can exhaust all available system resources. We advise incremental increases to align with your use case, such as increments of 50, to find the optimal configuration for your specific test scenario.
VirtServer’s license is based on the number of concurrently running virtual services. If you have a VirtServer license that allows 50 virtual services, this means your VirtServer can run up to 50 virtual services concurrently. You can easily upgrade and replace your license if you need to run more services than your license currently supports. Your Account Manager can help with the upgrade.
You can store as many virts as VirtServers hard drive capacity can manage, with no limitations. However, to ensure optimal system performance, it is advisable to maintain sufficient available storage space for system operations. See below for further guidance on storage.
When running virtual services with VirtServer, the system actively utilizes system memory, such as CPU and RAM. It becomes crucial to align system resources with your specific use case to optimize overall system performance.
Typically, your system requirements will depend on your expected usage:
Are you planning to use VirtServer for functional testing, load testing, or stress testing?
How many virtual services are you planning to run concurrently?
How many virtual services will be stored in the application that will not be running?
How many concurrent virtual users/threads are expected in your tests and over what time scale?
Do you require transaction logging in VirtServer?
Are you planning on using VirtServer as a standalone environment or for use behind a load balancer (and more than one VirtServer instance)?
How is your load balancer set up?
How many VirtServers are planned to operate behind the load balancer?
Are they all residing in the same network?
Is the load evenly distributed for each VirtServer? (You should calculate the expected load distribution and configure the min/max virts to each VirtServer, more below).
Lastly, it's crucial to assess whether virtual services utilize Groovy scripting and data sources, considering their impact on CPU, RAM, and storage. These data sources may include databases, Excel, or cached CPU data to reduce input/output operations.
Recommended System Requirements for specific use cases
The following are guidelines on system requirements for VirtServer. We have provided some similar use cases and the suitable system requirements to support:
Use Case: Functional testing, 5-20 virtual services running, low numbers of virtual users, and low loads of transactions.
Minimal System Requirements
Intel Core i3 or i5 (the 3rd generation or later) or equivalent
4 GB of RAM
500MB of free disk space for installation
1 GB for storage
Use Case: Functional testing, 20-40 virtual services running, 50-150 virtual users concurrently, or TPS expected to be <250.
Recommended System Requirements
Intel Core i5 or i7 (the 3rd generation or later) or an equivalent processor
6 GB of RAM or more
500MB of free disk space for installation
1-3 GB for storage
Using virtual services for Performance - guidelines and system recommendations
Note
When running a load test against virtual services, ReadyAPI sends requests to the service and then analyses responses from it. This can be a demanding task, especially when simulating a large number of virtual users. Large-scale load tests that simulate 1000 and more virtual users often need more powerful hardware.
Use Case: Functional testing and running a large number of load tests in parallel, <50 virtual services running concurrently, <250 concurrent virtual users, TPS expected to be <500 TPS.
Minimum recommendations are:
Intel Core i5 or i7 (the 3rd generation or later) with at least 4 threads
8 GB of RAM or more
500MB of free disk space for installation
1-5 GB of free disk space for stage
If transaction logging is required, especially, since the logs of long-running tests may exceed 1 GB, you may need to consider having more than 8 GB of RAM and 5-10 GB of storage on the machine. Running your tests in a Proof of Concept should validate your actual needs based on real data. Deploying in networks and using VMs - guidelines and system
Deploying in networks and using VMs - guidelines and system recommendations
There are additional considerations if you are planning to deploy into a wider network or on VMs in an enterprise environment or using VirtServer for higher loads in performance testing.
You can use the following guidelines to determine optimum system requirements based on how many virtual users you require to simulate if your use case is larger than those outlined above:
Depending on the complexity of your virtualized services and the expected load, a quad-core or higher processor may be suitable, e.g.
4 CPU cores and 8 GB RAM may be required to simulate up to 250 virtual users.
8 CPU cores and 16 GB RAM may be required to simulate up to 500 virtual users.
For larger and more complex virtualization scenarios, consider increasing the RAM to 32 GB or more.
For virtualized environments where CPU-intensive IO operations are in process, threads may be optimised at lower levels. It is advisable to align max threads closer to the number of threads available to the machine or the number of cores. You should modify the configuration of min and max threads to find the right setting to get the best results.
For higher VU or TPS scenarios, you may need to consider a load-balanced architecture with multiple VirtServer instances on separate hosts. Each host must have at least 16 CPU cores and 32 GB RAM to simulate more than 500 virtual users and up to 2500 TPS. Running your tests in a Proof of Concept should validate your actual needs based on real data.
When deploying virtual services to multiple VirtServer behind a load balancer you may choose to
Deploy all virtual services to all VirtServer and the load balancer routes requests in a round-robin fashion, or
Deploy specific virtual services to a particular VirtServer and configure the load balancer to route the API based on a request to the appropriate VirtServer. The latter approach needs more configuration on your load balancer, but it will provide flexibility in scaling your virtual services based on virtualization complexity.
Storage:
Use fast and reliable storage, such as SSDs, to ensure good performance.
Allocate enough storage space based on the size of the virtualized services and the amount of data you expect to generate during testing.
Network:
Ensure that the VM has adequate network bandwidth for communication with other systems and services.
Consider the network latency and throughput requirements of your virtualized services.
Ensure the virtual services and testing tools are accessible to each other and all relevant ports are opened.
We recommend the load balancer and VirtServer instances be in the same data center to reduce the response time variability of mocked API responses.
Monitoring and Logging:
You may want to consider implementing monitoring and logging tools to keep track of JVM performance, resource utilization, and any potential issues. Like tuning any other JVM application performance, the insights from performance monitoring can provide pointers to tweak settings or performance.
VirtServer can be configured to operate in different modes. These modes enable system resources to optimize the speed of requests/response execution and less on transactional logging.
Synchronization - In ReadyAPI 3.40.1, we added a synchronization update to ReadyAPI virtual services to improve accuracy when handling bulk requests. The synchronization update has improved the balance between accuracy and response rate/time. However, this may impact the speed of ReadyAPI response for some customers using virtual services as part of performance testing.
Logging - VirtServer can be configured to record transactions. This is available when Transaction Log and HAR logs are enabled.
The following outlines what those modes are and how to configure the application.
Standard Mode
By default, VirtServer runs with synchronization enabled and transaction and HAR logging enabled. This is the standard configuration used by most of our customers.
Performance Mode
You can disable synchronization and improve the speed of virtual service response when using virtual services as part of performance testing.
To enable performance mode, please add the following line to the ReadyAPI.vmoptions or Virtserver.vmoptions file (as appropriate):
-Dsoapui.virt.optimizeForPerformance=true
This flag can be controlled by modifying the VMoptions file for ReadyAPI and VirtServer in:
§ /readyapi_install_dir/bin/ReadyAPI.vmoptions
§ /virtserver_install_dir/bin/virtserver.vmoptions
§ /virtserver_install_dir/bin/virtserver-service.vmoptions
e.g.
C:\Program Files\SmartBear\ReadyAPI-3.49.0\bin\ReadyAPI.vmoptions
C:\Program Files\SmartBear\VirtServer-3.18.0\bin\VirtServer.vmoptions
C:\Program Files\SmartBear\VirtServer-3.18.0\bin\VirtServer-service.vmoptions
Please see here for ReadyAPI documentation on this topic.
Transaction Logging and HAR logging are set to 0.
Performance Mode with Error Logging
VirtServer always tracks application diagnostics while running. This feature is always on and available, The Diagnostics report gathers VirtServer’s logs, configuration info, and other information that may be useful for troubleshooting. Read about the diagnostic Logs here.
VirtServer can also operate in error logging mode with Transaction logging switched off. The configuration is managed through the VirtServer virt-server.yml YAML configuration.
Documentation: SmartBear documentation for VirtServer settings.
There are various logging settings: default logging level, individual logger classes and their logging level, and so on.
# Logging settings. logging: # The default level of all loggers. # Can be OFF, ERROR, WARN, INFO, DEBUG, TRACE, or ALL. level: INFO loggers: "com.smartbear": INFO "com.hubspot.dropwizard.guice.AutoConfig": WARN appenders: type: console timeZone: Europe/Stockholm
Breaking down the different components:
Default Logging Level:
level: INFO
This sets the default logging level for all loggers to INFO. This means that log messages with severity levels INFO, WARN, ERROR, and OFF will be recorded, while DEBUG and TRACE messages will be ignored.
Logger-Specific Levels:
loggers: "com.smartbear": INFO "com.hubspot.dropwizard.guice.AutoConfig": WARN
This section sets specific logging levels for two loggers (com.smartbear and com.hubspot.dropwizard.guice.AutoConfig). For example, log messages from the com.smartbear logger will be recorded if their severity level is INFO or higher, and messages from the com.hubspot.dropwizard.guice.AutoConfig logger will be recorded if their severity level is WARN or higher.
Appenders:
appenders: - type: console timeZone: Europe/Stockholm
This section specifies the type of log appenders. In this case, it's a console appender, which means that log messages will be displayed on the console. The timeZone parameter is set to Europe/Stockholm, which might be used to adjust the timestamps in the log messages to the specified time zone.
This configuration sets the default logging level to INFO, configures specific loggers to have different severity levels, and specifies a console appender for logging.
The actual logging library and how these settings are interpreted might depend on the technology stack and frameworks used in your server application.
Appender Configuration:
Ensure that the appender referenced in the configuration is set up to handle error-level messages. You may need to adjust the appender configuration separately.
Rolling Logs:
If the logs roll over periodically or are based on size, consider adjusting those configurations to retain only error logs.
Restart VirtServer:
Depending on the logging framework, changes may require a restart of VirtServer to take effect.
The following is a recipe for adjusting VirtServer to meet your expected performance parameters.
At each step, run some performance tests for your expected API load condition. If performance parameters (X%ile response time, transactions per second) are as per expectations, you can stop at the step. If performance parameters are not as per expectations, please proceed to the next step.
Run VirtServer on your normal server host.
If the system resources are not as per the recommended specifications, consider using a more powerful host machine.
Enable Performance Mode.
Increase Min and Max Threads for the virtual service (in ReadyAPI Behaviors panel) by increments of 20 and determine whether perf params improve.
If all the above does not help, it is time to scale out. Plan for a cluster of VirtServer installations behind a load balancer with all the above settings applied.
This recipe allows for step-by-step performance improvements based on your API load conditions. Regular performance testing at each step helps validate system adjustments.