skip to content
Relatively General .NET

Hello, MongoDB - Getting Started with Mongo and dotnet 8

by Ardalis

posted on: February 15, 2024

Integrating .NET Core with MongoDB in a Dockerized Environment Hello, fellow developers! Whether you're building a new project or…Keep Reading →

Introducing ASP.NET Core metrics and Grafana dashboards in .NET 8

by James Newton-King

posted on: February 14, 2024

.NET 8 introduces metrics to ASP.NET Core. Check out what is new and discover how easy it is to use metrics and ASP.NET Core to monitor the health and activity of apps.

.NET Framework February 2024 Security and Quality Rollup Updates

by Salini Agarwal

posted on: February 14, 2024

February 2024 Security and Quality Rollup Updates for .NET Framework

Our Vision for .NET 9

by .NET Team

posted on: February 13, 2024

Welcome to .NET 9! Learn about how we're improving .NET for all kinds of apps, with a special focus on cloud native, AI, and performance.

.NET February 2024 Updates – .NET 8.0.2, 7.0.16, .NET 6.0.27

by Rahul Bhandari (MSFT)

posted on: February 13, 2024

Check out latest February 2024 updates for .NET 8.0, .NET 7.0, and .NET 6.0.

8 ways to set the URLs for an ASP.NET Core app

by Andrew Lock

posted on: February 13, 2024

In this post I describe 8 different ways to set which URLs your ASP.NET Core application listens on.…

RavenDB Cloud now offering NVMe based clusters

by Oren Eini

posted on: February 12, 2024

I’m really happy to announce that RavenDB Cloud is now offering NVMe based instances on the Performance tier. In short, that means that you can deploy RavenDB Cloud clusters to handle some truly high workloads. You can learn more about what is actually going on in our documentation. For performance numbers and costs, feel free to skip to the bottom of this post.I’m assuming that you may not be familiar with everything that a database needs to run fast, and this feature deserves a full explanation of what is on offer. So here are the full details of what you can now do.RavenDB is a transactional database that often processes far more data than the memory available on the machine. Consequently, it needs to read from and write to  the disk. In fact, as a database, you can say that it is its primary role. This means that one of the most important factors for database performance is the speed of your disk. I have written about the topic before in more depth, if you are interested in exploring the topic. When running on-premises, it’s easy to get the best disks you can. We recommend at least good SSDs and prefer NVMe drives for best results. When running on the cloud, the situation is quite different. Machines in the cloud are assumed to be transient, they come and go. Disks, on the other hand, are required to be persistent. So a typical disk on the cloud is actually a remote storage device (typically replicated). That means that disk I/O on the cloud is… slow. To the point where you could get better performance from off-the-shelf hardware from 20 years ago.There are higher tiers of high-performance disks available in the cloud, of course. If you need them, you are paying quite a lot for that additional performance. There is another option, however. You can use NVMe disks on the cloud as well. Well, you could, but do you want to?The reason you’d want to use an NVMe disk in the cloud is performance, of course. But the problem with achieving this performance on the cloud is that you lose the safety of “this disk is persistent beyond the machine”. In other words, this is literally a disk that is attached to the physical server hosting your VM. If something goes wrong with that machine, you lose the disk. Traditionally, that means that you can only use that for transient data, not as the backend store for a database. However, RavenDB has some interesting options to deal with this. RavenDB Cloud runs RavenDB clusters with 3 copies of the data by default, operating in a full multi-master configuration. Given that we already have multiple copies of the data, what would happen if we lost a machine?The underlying watchdog would realize that something happened and initiate recovery, which will effectively spawn the instance on another node. That works, but what about the data? All of that data is now lost. The design of RavenDB treats that as an acceptable scenario, the cluster would detect such an issue, move the affected node to rehabilitation mode, and start pumping all the data from the other nodes in the cluster to it.In short, now we’ve shifted from a node failure being catastrophic to having a small bump in the data traffic bill at the end of the month. Thanks to its multi-master setup, RavenDB can recover even if two nodes go down at the same time, as we’ll recover from the third one. RavenDB Cloud runs the nodes in the cluster in separate availability zones specifically to handle such failure scenarios. We have run into this scenario multiple times, both as part of our testing and as actual production events. I am happy to say that everything works as expected, the failed node comes up empty, is filled by the rest of the cluster, and then seamlessly resumes its work. The users were not even aware that something happened.Of course, there is always the possibility that the entire region could go down, or that three separate instances in three separate availability zones would fail at the same time. What happens then? That is expected to be a rare scenario, but we are all about covering our edge cases.In such a scenario, you would need to recover from backup. Clusters using NVMe disks are configured to run using Snapshot backups, which consume slightly more disk space than normal but can be restored more quickly. RavenDB Cloud also blocks the user's ability to scale up or down such clusters from the portal and requires a support ticket to perform them. This is because special care is needed when performing such operations on NVMe machines. Even with those limitations, we are able to perform such actions with zero downtime for the users.And after all this story, let’s talk numbers. Take a look at the following table illustrating the costs vs. performance on AWS (us-east-1):Type# of coresMemoryDiskCost ($ / hour)P40 (Premium disk)1664 GB2 TB, 10,000 IOPS, 360 MB/s8.790PN30 (NVMe)864 GB2 TB, 110,000 IOPS, 440 MB/s6.395PN40 (NVMe)16128 GB4 TB, 220,000 IOPS, 880 MB/s12.782The situation is even more blatant when looking at the numbers on Azure (eastus):Type# of coresMemoryDiskCost ($ / hour)P40 (Premium disk)1664 GB2 TB, 7,500 IOPS, 250 MB/s7.089PN30 (NVMe)864 GB2 TB, 400,000 IOPS, 2 GB/s6.485PN40 (NVMe)16128 GB4 TB, 800,000 IOPS, 4 GB/s12.956In other words, you can upgrade to the NVMe cluster and actually reduce the spend if you are stalled on I/O. We expect most workloads to see both higher performance and lower cost from a move from P40 with premium disk to PN30 (same amount of memory, fewer cores). For most workloads, we have found that IO rate matters even more than core count or CPU horsepower. I’m really excited about this new feature, not only because it can give you a big performance boost but also because it leverages the same behavior that RavenDB already exhibits for handling issues in the cluster and recovering from unexpected failures. In short, you now have some new capabilities at your fingertips, being able to use RavenDB Cloud for even more demanding workloads. Give it a try, I hear it goes vrooom 🙂.

Creating an HttpClient that uses DNS over Https

by Gérald Barré

posted on: February 12, 2024

DNS is a key component of the Internet. It's used to translate a domain name to an IP address. For instance, when you type https://www.meziantou.net in your browser, the browser will query the DNS server to get the IP address of the server hosting the website. Then, the browser will connect to the

Hello, Redis - Getting Started with Redis and dotnet 8

by Ardalis

posted on: February 11, 2024

Integrating Redis Caching in .NET 8 Applications Redis is an open-source, in-memory data structure store, used as a database, cache, and…Keep Reading →

Resilience and chaos engineering

by Martin Tomka

posted on: February 09, 2024

Chaos engineering with HTTP clients and Polly library