DEV Community

Discussion on: 10 Performance-Improvement Tips for ASP.NET Core 3.0 Applications

View post
Collapse
 
slavius profile image
Slavius • • Edited

Notes I feel I need to add:

  • Making a function asynchronous only makes sense if it is going to wait on some external data. Namely network requests and disk accesses (which includes downloads over network of any kind, connections to remote storage, be it a database, distributed cache or other network connections to remote services, plus naturally slow disk accesses. Making a memory/cpu focused function async will make it most probably slower as it does not have to wait significanly enough to preempt to another thread while doing so. Also calling async on single core (and most probably also on 2-core) system will yield no improvement. Additionally overprovisioned hypervisors will most probably also suffer and make your code using async slower as it requires context switching to unload your thread code from CPU caches and load another one which is really expensive task regarding the kernel and will slow down the whole hypervisor if many VMs are using it heavily at the same time while overprovisioned.
  • the .AsNoTracking() is having currently, since early EF Core versions, exactly the opposite effect and is slowing data access significantly. There's a bug filled in EF Core GitHub repo and it's not much better in EF Core 3.1.1 either which is currently the lastest version. I would highly recommend to avoid .AsNoTracking() unless you do an extensive testing and confirm it is at least not doing any worse until EF Core team fixes it.
  • Using Response caching and minification/compression of responses should probably be handled by a Web server, not the application server. This would guarantee better control, separation of concerns, and performance. Otherwise you have to provide code/configuration to set up proper configuration based on every environment and customer you have (dev, test, staging, prod). I'm not aware of any performance benchmarks of Kestrel to confirm it is acting better than Nginx, Apache or haproxy. In containerized environments there is almost always a proper web server/load balancer in front of your container so you should avoid hardcoding compression/caching into your containers as it can result in hard times during debugging and slowdown due to front-end proxy server needing to uncompress-process-recompress every one of your HTTP requests for real end clients.