-
Notifications
You must be signed in to change notification settings - Fork 934
Linq performance issue with non cacheable linq query plan #2952
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@gokhanabatay unrelated, but what is the tool you are using for profiling (in screenshots)? |
Well some parametrized lambda is executed in code rather than SQL. And those constant parameters are not part of query plan - such caching is not supported (see #2375 which might fix it) If you have any methods which are not translated to SQL directly - try to move them out of query. So my suspect is |
We are using Dynatrace |
When we remove
Also what dou you think about logging suggestion? |
No idea about suspension. Again the only suggestion I have: just make problematic queries cacheable again by executing in code methods after query execution.
When it's ready and properly reviewed (not me).
No objections |
@bahusoid With 'Query 5' there is 893 micro seconds self time at Our mask method calls database function in sql and registered through session factory setup.
So I think the issue is in
Maybe the reason is
|
We changed nuget to
|
Are you saying the perf is worse than in 5.3 or what? All your images are not helpful. Compilation is not an issue. Though it can be avoided. Find what expressions are compiled and move them out of query in to parameter variables. Example: int GetValue(int p1) => p1 *1000;
query.Where(e => e.Id == GetValue(1)); <-- GetValue(1) call will be compiled With #2948 you can avoid compilation by moving GetValue method call out of query: int v = GetValue(1);
query.Where(e => e.Id == v); <-- No compilation And as I already explained in #2947 if |
This comment has been minimized.
This comment has been minimized.
Hi @bahusoid, performance is better than 5.3 thanks for that.
claims = Query<EntUserRoleOwnership>()
.Where(x => x.UserCode == key.Id)
.Select(x => x.RoleGuid)
.WithOptions(options =>
{
options.SetReadOnly(true);
})
.ToList(); We can avoid compile by changing method like at pull #2957 |
#2952 (comment) fixed #2957, throughput increased %100 from 2K tps to 4K tps |
Hi,
We have a performance issue with below linq query is not added to query plan cache. Because x.F2.Mask(6, 4, '*', MaskOption.Default) of this function call makes query uncacheable. This function is masks card number middle digits other than first 6 and last 4 digits. This api called concurrent 100 request at the same time.
First of all why this function call leads to query plan uncacheable, is this desired behaviour?
When we look at Dynatrace pure path below image added there is a suspension at QueryTranslatorImpl.Compile that I cannot understand and takes to much time to compile the query?
To report all uncacheable queries could you change QueryPlanCache.GetHqlQueryPlan log.Debug("Query plan not cacheable") to log.Warn("Query plan not cacheable {0}", queryExpression.Key) Adding elapsed time could be better for performance issues, we cannot find this issue without Dynatrace.
Environment
NHibernate 5.3.9
.net 5.0
linux container
SQL:
Suspension: total 51.5 ms is too much

Another pure path without Suspension but 1.72 ms too much for this kind of query for every request

The text was updated successfully, but these errors were encountered: