Is there any way to time how long it takes for a r...
# cfml-general
p
Is there any way to time how long it takes for a response to return to the CF box from say a DB server/request? Not the execution time of the query, literally just the request to the DB server?
t
you could probably get something from wireshark I know you can get packet timings https://www.wireshark.org/docs/wsug_html_chunked/ChWorkTimeFormatsSection.html
c
was going to say fusion reactor but after checking it does not split out the roundtrip time
p
yea we are trying to bypass the server admins and prove to them that their is a bottleneck in our requests hitting the db box via some cf or java method directly in our code so we have a proof of concept.
So basically zero access to boxes except in the CF code
c
could you somehow get the run time from the query itself ? then compare that with the complete time
p
but that is the execution of the query included in that time
basically they are trying to blame our queries so trying to take that out of the equation
c
i would think if you had the execution time from the database itself that should be just that - then compare total time in CF
exectution - total = round trip
other way around though lol
what database are you working with?
j
try running a very simple query with 0 execution time? "SELECT 1 FROM DUAL" should do it in most dbs.
👍🏻 1
👍 1
r
get a timestamp in the cf code right before and right after the cfquery?
Copy code
<cfset ts0 = gettickcount() />
<cfquery ... >
</cfquery>
<cfset ts1 = gettickcount() />
and then compare the difference between those two timestamps and what the query execution time shows.
or
Copy code
ts0 = gettickcount();
queryExecute(...);
ts1 = qettickcount();
… for the tag-impaired.
we’ve used that approach in the past to identify places where there is other latency/lag.
that will get total time, but it doesn’t differentiate between time TO the database server and time for the results to come back FROM the database server but it can help show if the to+from is significantly larger than the actual execution time.
p
Yea all of those seem like a good approach; I am going to add them to my mock to see where latency is occurring and prove to the DBAs heh.
Thanks for all the feedback!
r
Good luck. I’ve seen this movie a couple of times. Our version of it usually devolves into finger-pointing and name-calling between the various groups of app devs, sys admins, DBAs, and network admins.
… and usually the cybersecurity group gets blamed for onerous requirements, primarily because they never participate in the conversations.
p
Oh yea, its already been a finger pointing game since the beginning haha.