Contributions
response getTimeTaken different than soapUI reported times
Hi, I use soapUI 3.5.1 to execute web service load tests, the last step in the test script accesses the com.eviware.soapui.impl.wsdl.WsdlRequest object from the WS request test step, and calls the getResponse().getTimeTaken() method to retrieve the duration of the request, and writes that to a log file with other data about the request. When comparing the avg request time reported from soapUI, to the calculated average of request times from my log file, the soapUI avg time is significantly higher (slower) than the value calculated from my log file (an example from one load test with 100,000 requests, soapUI calculated value was 304ms, calculated time from log file was 260ms). Could this be due to the load test options "include request write in calculated time" and "include request read in calculated time", both of which were enabled for the test? In other words, does the duration time retrieved by the getResponse().getTimeTaken() method not include the request write and read time? If this does not explain the difference, can anyone offer any other suggestions why these would be so different? Thanks, Scott Tindal858Views0likes0CommentsRe: transfer-encoding:chunked for WS request
I'm not familiar with WS-Security or other features that may require access to the entire request. My understanding was that when MTOM was used, the file(s) included in the request were sent as MIME attachments outside of the soap envelope, I'm not sure if that helps in allowing the entire soap envelope to be accessed in memory while still streaming the attachment. If that is possible, then perhaps support for streaming could be available in combination with the use of MTOM. I tried the June 6 soapUI 3.0 beta 1 build, with the chunking feature enabled. While soapUI did use chunking to send the request, it sent the entire request as one chunk (even with a document size of 10MB), and it appears to buffer the entire request in memory, which leads to java heap problems for the soapUI JVM (similar to what I have been seeing for download tests with large documents). I'm not sure if this is happening because the request is sent as one chunk and so is not broken up into smaller pieces to load into memory, or if it just a case where the entire request is always loaded into memory by soapUI. In either case (chunking or not), a key requirement for me is to have soapUI not buffer the entire request in memory. I need to test uploading documents up to a size of 1GB, currently java heap usage is roughly 10x the document size so the largest document I can upload is about 100MB (with just one client thread). Thanks, Scott3.4KViews1like0CommentsRe: Re: Avoiding high memory use when downloading large documents
Hi, I downloaded the June 6 soapUI Pro 3.0 beta 1, and was able to run it and did not get the GRE error. Using ${ThreadIndex} as the variable in the file name is working to generate a unique file name per client thread. However, running my download testcase in this 3.0 build, with the dump-file parameter set in this way, I am still seeing the high java heap memory usage in soapUI JVM. Scott938Views0likes0CommentsRe: Re: Avoiding high memory use when downloading large documents
Hi, I downloaded the June 3 2.5.2 build, and set the dump file parameter as you described, but I'm still seeing the high memory usage. With a single thread, downloading a 100MB file, java tenured generation memory usage jumps up over 500MB. I can send a .hprof memory dump taken with the Sun jvisualvm tool if that would help. Also, the dump file parameter didn't properly parse that variable, I set it to: c:/public/DLTempFiles/data-${context.ThreadIndex}.dat But the file created was: C:\public\DLTempFiles\data-.dat I also downloaded the June 3 3.0 beta 1 build (the win32 standalone bin zip: http://www.eviware.com/nightly-builds/2 ... ne-bin.zip), but when I try to execute soapui-pro.bat it I get this error: Exception in thread "XpcEventThread" javax.management.RuntimeErrorException at com.teamdev.xpcom.Xpcom.a(SourceFile:40) at com.teamdev.xpcom.a.run(SourceFile:119) at com.teamdev.xpcom.d.run(SourceFile:436) at com.teamdev.xpcom.impl.awt.d$a.run(SourceFile:68) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.Error: java.io.FileNotFoundException: GRE not found ... 5 more Caused by: java.io.FileNotFoundException: GRE not found at org.mozilla.xpcom.Mozilla.getGREPathWithProperties(Mozilla.java:177) ... 5 more Googling this error suggests I need a Software\\mozilla.org\\GRE registry key, can I create this, or do I need to run the full installer for soapUI 3.0? Thanks, Scott937Views0likes0CommentsRe: transfer-encoding:chunked for WS request
Hi Dain, Sorry for the delay in responding, I've been sidetracked for a few weeks. I think this would be a useful addition to soapUI, it would address my original requirement to execute the test with chunking enabled. Perhaps an incremental improvement would be to make this a property of the TestRequest, rather than a global preference, so that chunking could be enabled/disabled, and the size specified, on a per request basis. I have an additional related question. As an alternative to enabling chunking, it should also be possible to avoid the memory issues I was experiencing by streaming the upload. I'm told that for a java client, that is sending requests directly using the HttpUrlConnection class, calling setFixedLengthStreamingMode (ContentLength) will enable streaming. For a java client using the jaxws library, it's not possible to call the above method directly on the underlying HttpUrlConnection, but a jaxws chunksize property can be set to cause it to call setChunkedStreamingMode(chunkLength) on the underlying HttpUrlConnection. I was wondering if you could describe how soapUI is sending the WS requests internally, and whether it would be possible to also expose a configuration property that would enable streaming for the request? Thanks, Scott3.4KViews0likes0CommentsRe: Avoiding high memory use when downloading large documents
I'm using soapUI Pro 2.5.1, executing command line loadtestrunner.bat to run a load test that will repeatedly download large (100MB) documents using a web service call. - I've modified loadtestrunner.bat to have -Xms1024m -Xmx1024m so that the java heap is increased to 1GB - The web service supports MTOM, and I have configured the request properties to have Enable MTOM and Force MTOM to true. - In the testcase options, I have also set 'discards successful testresults to preserve memory'. It appears that soapUI retrieves the entire document into memory during a download, with the above setting previous downloads can be garbage collected so I don't get OutOfMemory errors, but when running a number of threads, soapUI still uses up java heap memory quite quickly resulting in a lot of time spent in garbage collection (during a 5 thread test downloading 10MB documents, JVM throughput was about 66% (i.e. 34% of time spent in GC)). Is there a way to have soapUI stream this type of download to a temp file rather than storing it all in memory, so that this type of test could be executed with less GC overhead? This has a big effect on the download time. I tried setting the "Dump File" TestRequest property to a file, but this didn't affect the memory usage, and only one file can be specified so I'm not sure how this property would help with multi threaded test. Thanks, Scott Tindal2.5KViews0likes6CommentsRe: Request-response Logging when running the load test
Is there an explanation for what causes the repeating "waiting for x samples" message? I am using soapUI Pro 2.5.1, I'm not trying to do full request/response logging as in this original post, but I am using the loadtestrunner.bat to execute load tests. Once in a while, a test gets stuck with the repeating error: INFO [LoadTestStatistics] Waiting for 2 samples.. I do have some informative log messages that are output by the test, could they be causing this issue? Thanks, Scott Tindal4.6KViews0likes0CommentsRe: transfer-encoding:chunked for WS request
Is it possible to use a groovy script to make this type of call on the HttpURLConnection object that will be used by a subsequent request step? The alternative workaround that I will try is to implement the WS call entirely within a groovy script step, but I'd rather avoid this if possible as it eliminates the main benefit of using soapUI to simplify WS testing.3.4KViews0likes0Comments