Forum Discussion
Hi Ed,
I think it's probably that the first request always takes longer as it triggers the initialisation of SoapUI, you can see this behaviour in the logs e.g.
1) deploy soapui mock war - see standard tomcat logging:
INFO: Deploying web application archive /Users/test/apache-tomcat-7.0.54/webapps/restmock.war Mar 03, 2017 2:50:02 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /Users/test/apache-tomcat-7.0.54/webapps/restmock.war has finished in 5,654 ms
2) Hit the mock - see the SoapUI core startup e.g. something like:
14:51:31,897 WARN [SoapUI] Could not find jfxrt.jar. Internal browser will be disabled. 14:51:31,898 WARN [SoapUI] Missing folder [/Users/test/apache-tomcat-7.0.54/webapps/restmock/ext] for external libraries 14:51:32,112 INFO [DefaultSoapUICore] initialized soapui-settings from [/Users/test/soapui-settings.xml] 14:51:32,518 INFO [PluginManager] 0 plugins loaded in 1 ms 14:51:32,518 INFO [DefaultSoapUICore] All plugins loaded Mar 03, 2017 2:51:32 PM com.eviware.soapui.mockaswar.MockAsWarServlet initMockServiceParameters INFO: Listeners not set! Mar 03, 2017 2:51:32 PM com.eviware.soapui.mockaswar.MockAsWarServlet initMockServiceParameters INFO: Actions not set! Mar 03, 2017 2:51:32 PM com.eviware.soapui.mockaswar.MockAsWarServlet initMockServiceParameters INFO: SoapUI core already exists, reusing existing one Mar 03, 2017 2:51:32 PM com.eviware.soapui.mockaswar.MockAsWarServlet initMockServiceParameters INFO: WebUI DISABLED Mar 03, 2017 2:51:32 PM com.eviware.soapui.mockaswar.MockAsWarServlet init INFO: Loading project 14:51:33,625 INFO [WsdlProject] Loaded project from [file:/Users/test/apache-tomcat-7.0.54/webapps/restmock/WEB-INF/soapui/Marketing-Service-Test-soapui-project.xml] Mar 03, 2017 2:51:33 PM com.eviware.soapui.mockaswar.MockAsWarServlet init INFO: Starting REST mock service [REST MockService 1]
This is the same every way you run SoapUI, whether its from the desktop, script, java etc
I'm not sure what the easiest way to work around this is, maybe make a 'warm-up' request before your first test request?
Regards,
Rupert
Rupert,
Many thanks for your response. I had already experimented with adding a pre-test to "warm up" SOAPUI. This of course works. But I was searching for a solution which didn't require adding this to all of the tests.
I think I have no real issue with SOAPUI taking some extra time on receiving the first message. I think its the amount of time taken that seems excessive. In some cases approx 5 seconds. Which to me suggests SOAPUI is waiting for something? Rather than actually processing for 3-5 seconds?
I had started to investigate Proxies as I read somewhere that if the SOAPUI proxy was set to automatic then potentially SOAPUI might do some exploration before deciding there was no proxy. So I was trying to disable proxy in the pom.xml, just to see if this has any effect with the following lines;
<soapuiProperties>
<property>
<name>ProxySettings.ENABLE_PROXY</name>
<value>false</value>
</property>
</soapuiProperties>
This seems to have no effect, but this could be due to, proxies not being the issue or the addition above not being correct. I struggled to find an example of this. But as SOAPUI allows you to put any name into the above XML there is no real way for me to know whether I am changing the right existing SOAPUI setting or creating a new one.
Do you know what the correct name would be in this case? I'd just like to eliminate this from my investigation.
If this doesn't work, potentially we will just have to elongate the timers for testing, as we can still test functionality this way as I have control of both ends (JMETER>>DUT>>>SOAPUImock). For performance we will have to "warm up" SOAPUI.
Many thanks for your help so far.
Related Content
- 2 years ago