Microsoft Soru-Yanıt'ı kullanmaya başlamaya yönelik ilk adımlar veya yönergeler
this smells like the Contains(deviceIds) round-trip + tracking + big materialization, not the db itself. SSMS is fast cuz you probably ran a simplified sql with ids inlined; EF sends a fat IN (@p0,@p1,...) with lots of params, tracks every row, then sorts + serializes. that combo can easily hit 10–80s on app side even when sql is ~1s.
do it in one server-side query, no tracking, no intermediate list. something like:
var wakeUps = await _contextMivo.Wakeups
.AsNoTracking()
.Where(w => w.Customerschema == _apiUser.Customerschema
&& w.Dateandtime >= input.StartDate
&& w.Dateandtime <= input.StopDate)
.Join(
_contextMivo.Devices
.AsNoTracking()
.Where(d => d.Customerschema == _apiUser.Customerschema),
w => w.Deviceid,
d => d.Deviceid,
(w, d) => w
)
.OrderByDescending(w => w.Dateandtime)
.ToListAsync();
if you don’t need all cols, project early to a dto (less json). also make sure the action isn’t returning megabytes uncompressed. if it’s still slow, there’s likely no index on (Customerschema, Deviceid, Dateandtime) so sql has to sort/scan; add at least an index on Wakeups(Dateandtime) + Deviceid later. but i’d try the single query + AsNoTracking() first it usually drops 80s → a few secs (or less)...