System Requirements

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.

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

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

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 virtualised 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 virtualisation 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.

By default, VirtServer runs with synchronization enabled and transaction and HAR logging enabled. This is the standard configuration used by most of our customers.

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):

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.

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.

Breaking down the different components:

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.

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.

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.

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.

If the logs roll over periodically or based on size, consider adjusting those configurations to retain only error logs.

Depending on the logging framework, changes may require a restart of VirtServer to take effect.