What can be done to improve virtual service high response time

book

Article ID: 38264

calendar_today

Updated On:

Products

Service Virtualization CA Application Test

Issue/Introduction

The response time for a virtual service is higher than expected. We would like to improve these response time metrics.

Environment

Release:
Component: ITKOVS

Resolution

1. Verify what is memory configuration for the VSE in the VirtualServiceEnvironmentService.vmtoptions or VirtualServiceEnvironment.vmoptions.

The ideal heap size will depend on how many virtual services are deployed to your VSE and what is the size of a virtual service image.

If you have a large VSI, the VSE will need more memory to process it.

To increase the heap size for the VSE service you will need to edit the vmoptions file and add or edit the property below:

         -Xmx2g

This option increases the heapsize to 2G.

For more information regarding memory settings: https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/administering/general-administration/memory-settings.html

 

2. Change the logging level to WARN or ERROR.

Edit the logging.properties file in the VSE server and modify the properties below:

from: log4j.rootCategory=INFO,A1 

to:      log4j.rootCategory=ERROR,A1

from: log4j.logger.VSE=INFO, VSEAPP

to:      log4j.logger.VSE=ERROR, VSEAPP

 

3. Add the following properties to the local.properties in the VSE server.

          lisa.vse.performance.enabled=true

          lisa.pathfinder.on=false

          vse.socket.reuse=true

          lisa.net.timeout.ms=60000

          lisa.net.xstream=false

          lisa.dcm.maxExpandPerLoadChange=50

          lisa.jpm.MaxInstances=5000

          lisa.jpm.unlimited=false

          lisa.overloadThreshold=30000

          lisa.eventPool.maxQueueSize=65535

          lisa.eclipselink.cache.timeout.ms=3600000

          lisa.CycleExecHistory.buffer.size=2

 

These properties are also available in the product documentation:

Sample Performance Benchmarks for Basic Service Virtualization - https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/installing/installing-and-configuring-devtest-server/post-installation/sample-performance-benchmarks-for-basic-service-virtualization.html

Sample Performance Benchmarks for IBM MQ Service Virtualization - https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/installing/installing-and-configuring-devtest-server/post-installation/sample-performance-benchmarks-for-ibm-mq-service-virtualization.html

With messaging virtual services, like MQ, JMS , RabbitMQ, verify what is the scope configuration.

More information regarding the runtime scope in the links below:

The Meaning of "Scope" in the JMS and Native MQ Steps - https://knowledge.broadcom.com/external/article?articleId=39770

Runtime Scope - https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/using/using-application-test/using-devtest-workstation-with-application-test/building-test-cases/assets/runtime-scope.html

 

4. When testing a virtual service verify the vse.log files for any errors or exceptions. 

If there are any exceptions for a particular VSM resolve them and redeploy the service. 

If you require assistance to understand or resolve an exception, please open a support case - https://casupport.broadcom.com/.

The log files are located in the $LISA_HOME\lisatmp directory, if the VSE is running as a Windows service.

If the VSE is running in a Linux server, the log files are located under the home folder of the user that is starting the VSE service.

This location can also be modified by the lisa.tmpdir property.

 

5. If needed, change the concurrent capacity for the VSM.

More information regarding concurrent capacity in the links below: 

Deploy a Virtual Service - https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/using/using-service-virtualization/using-devtest-portal-with-service-virtualization/deploy-virtual-services.html

What is the maximum concurrent capacity that we can set for a VSM? - https://knowledge.broadcom.com/external/article?articleId=118895

 

6. Verify if the think time specified for the VSI responses is correct.

The think time scale set to 100% will honor the think time specified in the VSI responses.

For more information regarding think time scale: https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/using/using-service-virtualization/using-devtest-portal-with-service-virtualization/deploy-virtual-services.html

For more information regarding think time spec - in the VSI response: https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/using/using-service-virtualization/using-devtest-workstation-with-service-virtualization/editing-service-images/service-image-tab.html

Change the think time of a VSI response: https://techdocs.broadcom.com/us/en/ca-enterprise-software/devops/devtest-solutions/10-6/using/using-service-virtualization/using-devtest-portal-with-service-virtualization/edit-virtual-services/update-a-virtual-service-manually/update-responses.html

 

7. Verify if there is any think time specific in the VSM steps - https://knowledge.broadcom.com/external/article?articleId=7125

 

8. Verify how much time it takes for a request to get from the client application to the VSE server.

You can run ping command from the client side to the VSE server and vice versa:

          # ping -t <VSEServer_IP_Address or HostName>

with the option '-t', without quotes, it will ping the target until you force it to stop by using Ctrl+C.

 

Leave this command running for some time or until you face issues with the response time.

If there is a connectivity issue, you will most likely see some packets being lost.

Save the ping statistics for future reference.

It can be that ICMP echo (used for ping) may have been disabled in the environment. If that is the case we will not be able to use the ping command for testing.