Question: Why would a MSSQL query that typically t...
# lucee
t
Question: Why would a MSSQL query that typically takes about 17s, returns 14 rows, 9 columns - nothing special... takes 743s when using queryExecute? Lucee 5.3.7, 5.3.8, 5.3.9 affected
Any tips appreciated
SQL Server isn't the culprit. Verified.
Minimal CPU usage on Lucee host while it's running. Like Lucee is stuck in an Elon Musk quandry.
s
how did you verify it wasn't sqlserver? curious
r
Are you using query parameters? If so, try running the query in CF with the actual values to see if it's some kind of parameter sniffing.
s
was thinking the same thing, ssms also sets some options by default which could cause queries to perform differently if using that to verify
z
string vs number? if the types don't match, the index will be ignored
d
As mentioned above, there are several reasons this can happen, and the most likely culprit is the database. If you're using something like SSMS to "confirm" the issue isn't the database and doing something like:
Copy code
select col1, col2 from Table where col3 = 1234
But your CFML code is like this:
Copy code
select col1, col2 from Table where col3 = <cfqueryparam value="1234" />
Then those are not equivlient things. SQL Server will cache the parameterized query and it can be affected by Parameter Sniffing: https://www.brentozar.com/archive/2013/06/the-elephant-and-the-mouse-or-parameter-sniffing-in-sql-server/ This is generally the culprit in these situations. However, as @zackster allued to, you can also be bit by type mistmatches. I recently discovered a bug in third party framework we use in some places of our code called qb, which is a fluent query builder for CFML. Since it obscures the actual SQL statements being executed, I didn't realize it was casting all integers as floats in the actual SQL statement being executed, which was leading to coercion happening in the query, which was causing terriblly inefficient query plans. It took us a while to notice the issue because even with the coercion, things were usually really fast. However, sometimes we'd be bitten by slowness, but flushing the query's cache plan would resolve the issue. We just thought were getting hit by some cache poisioning issues that was the root cause. It wasn't until I actually took a deep dive and really started analysing things that I realized what was going on.
👍 1