Forum Discussion
billneff
14 years agoNew Contributor
Re: nanoseconds and milliseconds timing results different?
Postby billneff » 05 Jan 2012 17:13
I'm having a similar issue. I have other external tools measuring the response time (Introscope as well as some database inserts) of an http soap request, and the response time reported by soapUI isn't even close, relatively speaking, to the response time reported by Introscope and the database records, which are consistently similar to each other.
For example, we have the following setup: soapUI makes the http request to the server. When the request hits the server Introscope starts its timer. The application picks up the message and a timestamped database record is written after the objects are deserialized. The message is processed by the application, another timestamped record is written to the database, the response is serialized, Introscope stops its timer, soapUI receives the message. So the timing should look something like this: (soapUI start (Introscope start (database start, database stop) Introscope stop) soapUI stop). If each measurement was accurate you would expect the database time delta to be a little less than Introscope, which should be a little less than soapUI. In reality, I got the following, in one real world example:
database: 1523 ms
Introscope: 1794 ms
soapUI: 666 ms
The soapUI duration, which should be the longest, was half as short as the others.
Given this, I can't effectively use soapUI to test the SLA of my services for even one request, let alone under a load. I've tried this in both soapUI 3.6.1 and soapUI 4.0.1.
FYI - I cross posted this on the soapUI Bugs forum.
Postby billneff » 05 Jan 2012 17:13
I'm having a similar issue. I have other external tools measuring the response time (Introscope as well as some database inserts) of an http soap request, and the response time reported by soapUI isn't even close, relatively speaking, to the response time reported by Introscope and the database records, which are consistently similar to each other.
For example, we have the following setup: soapUI makes the http request to the server. When the request hits the server Introscope starts its timer. The application picks up the message and a timestamped database record is written after the objects are deserialized. The message is processed by the application, another timestamped record is written to the database, the response is serialized, Introscope stops its timer, soapUI receives the message. So the timing should look something like this: (soapUI start (Introscope start (database start, database stop) Introscope stop) soapUI stop). If each measurement was accurate you would expect the database time delta to be a little less than Introscope, which should be a little less than soapUI. In reality, I got the following, in one real world example:
database: 1523 ms
Introscope: 1794 ms
soapUI: 666 ms
The soapUI duration, which should be the longest, was half as short as the others.
Given this, I can't effectively use soapUI to test the SLA of my services for even one request, let alone under a load. I've tried this in both soapUI 3.6.1 and soapUI 4.0.1.
FYI - I cross posted this on the soapUI Bugs forum.