Prepare virtual service before deploying

VirtServer environments differ from ReadyAPI. Here are some recommendations for preparing your virtual service before you deploy it to VirtServer:

Use virtual service properties

A virtual service deployed to VirtServer exists separately from the ReadyAPI project. It means that the project, test suite, test case, and global properties will not be available for the virtual service. Use properties of the virtual services so your service can function independently.

Modify virtual service scripts

If you use scripts in your virtual service, you may need to do the following:

Upload the used third-party libraries to the <VirtServer directory>/bin/ext directory.
Copy the files used in scripts to a place available from the computer where VirtServer is installed. Update paths to these files in the scripts.

Use virtual services with data sources on VirtServer

It is a good practice to use data sources to form a virtual service response. If your virtual service should include some test data, you can take this data from a data source. This topic covers the specifics of running virtual services with data sources on VirtServer.

Use data sources in virtual services

You use data sources in a usual way:

Specify the data source connections settings and define data source properties on the DataSource page of the virtual service editor in ReadyAPI.
Specify the data source in virtual service settings and refer to the data source properties in responses.
Start the virtual service and run some tests against it to check if it retrieves data from the data source.

If your service works successfully, you can deploy it to VirtServer.

You may need to prepare VirtServer in order for it to be able to use your data source. See below.

Specifics

File-based data sources (for example, Excel sheets or .csv files) automatically get to VirtServer when you deploy your virtual service there. VirtServer then automatically adjusts the service properties so that they refer to the uploaded data file.

If you use server-based data sources like an SQL Server or an Oracle database, ReadyAPI uploads the connection settings only.

In order for your service to be able to connect to the database server from VirtServer:

The connection settings should be valid for the VirtServer computer.
You need to place a JDBC driver for your database in the <VirtServer directory>/bin/ext directory.

VirtServer ships with drivers for PostreSQL and Microsoft SQL Server databases. You can install them during VirtServer installation. If you have not installed them, you can re-install VirtServer and choose to install the drivers.

If you use other database servers, you need to find the appropriate driver and copy it to the bin/ext directory.

After you put a custom driver to the bin/ext directory, restart VirtServer.

Handle virtual service performance

You may want to run a load test against a virtual service (virtual API) working on ReadyAPI or VirtServer. We recommend that you do this only when you are creating or debugging your load tests to ensure that the test works as expected (for example, that it simulates the required traffic, runs the appropriate assertions, handles property expansions properly, and so on). At that, we recommend that you run your load test with minimum configuration (for instance, with a minimum number of VUs possible) because virtual services are normally not used for load testing.

Please keep in mind that any application or computer working under a load experiences a performance decrease. Depending on the load and on your hardware parameters, the decrease can be significant – the virtual service can even stop working at the peak load.

Below are some factors that affect the virtual service performance:

Insufficient amount of memory and other hardware resources. Please make sure your computer meets the recommended system requirements. The more powerful hardware your have, the better.
Hundreds of virtual users simulated simultaneously. Try to reduce the number of virtual users for better performance.
A great number of dynamic property expansions along with code evaluation generates a heavy load on virtual services. Instead of reading data from an external data source, try using data generators.
Huge values calculated in a dispatch script slow down the virtual service performance. Try simplifying them.
Parsing requests with numerous XPath or JSONPath assertions can also cause a performance slowdown. Try limiting the number of these assertions for better performance.

Best Practices