|
|
> Wow, I see nothing in your code that jumps out at me as a problem.
God. I at least expected you to run - screaming - from the room at the
sight of my code!
More on this.
Standard queries are doing this too, sometimes. For example we had a query
that was basically:
select obt_id, obt_left, obt_right
from tbl_objtree
where obt_left <= <cfqueryparam value="#iLeft#"
cf_sql_type="cf_sql_integer">
and obt_right >= <cfqueryparam value="#iRight#"
cf_sql_type="cf_sql_integer">
(ie: get ancestors and self from a nested-set tree)
Which was taking 0ms on the DB to fetch zero records, yet took CF 16sec
(sic) to catch up and do something about it.
One idea I had was whether perhaps CF has a "fire and forget" approach to
connections to the JDBC driver, like this:
- make a connection
- pass SQL statement
- close connection
- (time passes whilst DB does its stuff, in the mean time another SQL call
can use the connection)
- DB driver says "oi, CF, have this..."
And CF in the mean time hasn't got a connection available to use to
reconnect to the driver (this site has some DB usage problems, which is why
I'm looking at this sort of thing).
So perhaps the 16sec is the length of time the JDBC driver has to wait
until CF gets around to listening to the answer. This is all supposition
on my part. I've not been able to find out anything in the FusionReactor
docs to describe what that value might actually represent.
This seems more likely given these big time blowouts are more likely to
happen when the server is struggling under load (although, equally, they
could be the CAUSE of the load, not a symptom of it).
It's all a bit curious.
--
Adam
|
|