Last post Jun 01, 2020 02:42 PM by since3point0
May 29, 2020 04:48 PM|since3point0|LINK
I have seen this issue all over the web and I have tried many of the suggested scenarios without a lot of success. Sure, I can shave a little bit off the DB query, but not a significant amount of time.
Here is my setup
1) .Net Core 3.1.3 web API
2) SQL 2019
4) Two huge tables (appx 25 million records)
5) I am using migrations (code first)
The first request will take about 20 second to execute and sometime will timeout. But all subsequent requests will take about 2-3 seconds to return results. I am doing a search with "contain" as part of the condition. So I realize that will add some inefficiency
to the query.
I have tried the warming suggestion (https://andrewlock.net/running-async-tasks-on-app-startup-in-asp-net-core-part-1/) and that did little or nothing to solve
I have also seen the suggestion of running a task on startup, which I do not think is a solution to this issue.
So I am looking for a suggestion on the best way to shave time off the query without recreating the wheel.
Here is a sample of a query.
.Where(s => s.Zip == postalCode && s.CompanyName.Contains(companyName))
Any suggestions would be very helpful.
May 29, 2020 05:52 PM|DA924|LINK
You're going to have a latency hit on first request.
As for the ORM, you could look into Dapper
You could just use ADO.NET with SQL Command objects, parmterized in-line T-SQL, parmterized stored procedure, a datareader and a custom type like a DTO returning the results in a List<t>, becuase after all, that's all any ORM is really doing under the
hood it's just slower. Using ADO.NET in the manner I am talking about is faster than using an ORM if you're concerned about speed. :)
Jun 01, 2020 02:42 PM|since3point0|LINK
Thank you for the response. I switched to Dapper and created a stored procedure