My Response to "Avoid Lazy Loading in ASP.NET"

Shawn Wildermuth wrote a post Avoid Lazy Loading in ASP.NET where he argues that web applications should not make use of the lazy loading features in ORMs. His argument for not using lazy loading is because of potential problems, including increased web page latency, and extra load on the database server. He would rather avoid these pitfalls by avoiding using lazy loading.

For reference, here's the documentation on lazy loading in EF Core. 

I agree with his position that lazy loading can lead to performance issues, but I disagree with the assertion that lazy loading should be avoided.

My main issue is the advice to not use the lazy loading feature out right in web applications. I am not a fan of black listing a technology because of the potential issues.

Instead, I'd rather see an explanation of the potential pitfalls, under what conditions, and how those problems would manifest themselves in web applications.

I wrote up my comments on his post, but my comments got marked as spam. Below is the comment I left on Shawn's post. I'm also working on a little mini project using EF Core 2.1 lazy loading, to do a performance analysis.

---

I agree that there's a potential for a performance impact by using lazy loading, but that shouldn't prevent someone from using it.

If we follow this argument, I could turn this around and advise folks to avoid ORM's because it limits scalability. Or I could also argue that at high loads, the use of garbage collected languages will limit scalability. But those kinds of statements can't be made generally. You can't possibly know the requirements for every project, or what the bottlenecks might be.

You also didn't include any empirical evidence that illustrates the performance issues.

I've built and scaled web applications that use lazy loading, and lazying loading was rarely an issue. Use of connection pools helps ensure that the web application doesn't make too many simultaneous queries to the DB server, if tuned properly. And when lazy loading is causing performance issues, load on the database server could be an issue, but you're more likely to see a spike in network traffic, CPU, and memory first, due to the number of queries being executed and the conversion of the result set into objects. Latency can also increase due to overhead of the additional queries, but if there are only a small number of queries, this shouldn't add much overhead. All these things are differ from project to project, so it's hard to say if the performance overhead would be an issue or not. It also depends on how much traffic the website is getting, and if you're at sufficient scale, your monthly hosting bill.

Another thing not mentioned in this post is monitoring of web applications. APMs such as New Relic make spotting these kinds of issues fairly easy. If you are having performance issues, you can slice and dice the web requests, looking for the offenders, and optimize the code as necessary. Any design decision can impact performance, not just lazy loading.

I'm also curious who the intended audience of this blog post is. I assume that you're trying to help future developers from falling into traps with lazy loading in web applications. But think about the person on the other end reading this. Should they rewrite their application that uses lazy loading in light of this article, with no performance indicators that lazy loading is causing issues? I don't think applications should be rewritten because there's a potential in the future that lazy loading could be an issue. Or think about a senior dev that's considering using lazy loading in their design. Should they rework the design because of the potential for issues down the road?

I appreciate that you have a distain for use of lazy loading in web applications, and the awareness this post brings to the potential pitfalls. But I don't think that we should outright ban the use of lazy loading for every web app ever.

My advice on any technology choice is to monitor performance regularly, and optimize as necessary. If the technology choice makes sense in the design and performs well enough, use it.