Improving Virtual Service high response time
Article ID: 38264
Updated On:
Products
Issue/Introduction
The response time for a virtual service is higher than expected. We would like to improve these response time metrics.
Environment
All supported DevTest releases and platforms
Cause
N/A
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 heap size to 2G.
For more information regarding memory settings: Refer to section "Memory Settings" in the documentation of the DevTest release you are running.
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
For DevTest 10.7.2 and later:
rom: rootLogger.level = INFO
to: rootLogger.level = ERROR
from: logger.VSE.level = INFO
to: logger.VSE.level = ERROR
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 - Refer to section "Sample Performance Benchmarks for Basic Service Virtualization" in the documentation of the DevTest release you are running.
Sample Performance Benchmarks for IBM MQ Service Virtualization - Refer to section "Sample Performance Benchmarks for IBM MQ Service Virtualization" in the documentation of the DevTest release you are running.
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 - Refer to section "Runtime Scope" in the documentation of the DevTest release you are running.
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://support.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 - Refer to section "Deploy Virtual Services" in the documentation of the DevTest release you are running.
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: Refer to section "Deploy Virtual Services" in the documentation of the DevTest release you are running.
For more information regarding think time spec - in the VSI response: Refer to section "Service Image Tab" in the documentation of the DevTest release you are running.
Change the think time of a VSI response: Refer to section "Update Responses" in the documentation of the DevTest release you are running.
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.
Additional Information
Filtering out INFO messages avoids messages similar to the following that might be observed during load tests:
INFO - Error doing destroy() on Step HTTP/S Listen: null java.lang.NullPointerException: null
Feedback
