I think ASP.NET sites use a little more memory than PHP sites -- there's more overhead in general. But they should still not keep growing in memory like you're seeing.
I personally don't have any experience debugging the cause or source of where memory usage is coming from with ASP.NET. But in that post, towards the end of the comments, Mister Goodcat says:
For analyses like that I use WinDbg and the built-in profiler of Visual Studio. Please note that you need Visual Studio Premium or better for that, it's not included in the Professional or Express versions.
... so maybe WinDbg if you don't have a higher end of VS. There could be other tools too.
How the application is designed can make a difference in the memory you see. For example, when BE first starts, it loads ALL the posts and other data into memory/cache and keeps them there. By doing this, it doesn't need to keep going back to
the data store (XML or DB) to retrieve posts. This is a little extreme in my opinion since once you get up to having thousands of posts, you'll start to see high memory. Under "normal" blogging conditions, it would take an individual
BE user several years of regular blog posting to reach the level of posts that would cause consistent high memory. So it still works well.
Output caching I think would help most with CPU. With that, the page doesn't need to be regenerated on each request and can be served from memory. So if anything, output caching might lead to higher memory (but not a lot) since the pages are
cached in memory.
If things go well, and these memory leak fixes work for you, then your BE installation might use around 50 MB to 75 MB of memory at all times. I don't think output caching is necessary. Plus with output caching, it needs to be designed so authenticated
user information that might appear on the page doesn't get cached and served to unauthenticated users (or users who are logged in under their own account). As an example, if you are logged into the site and looking at some unpublished posts (logged in
users can see unpublished posts), you wouldn't want that page rendering to be cached and displayed to subsequent users who are not logged in -- since they shouldn't be able to see unpublished posts.