Azure VMs with SSD are now available - Benchmark using MongoDB over SSD

Today, Azure team announced that we will have VMs with Solid State Drives. Wow, this is so cool.
Why this is so great? Well, first of all, if you work with application that have a high demand of I/O on disk than this could be the perfect solution for you. Of course, the new machines has a new configuration, with additional processing power, but I don’t want to talk about this.
For more information related to this VMs you can go to:

In this blog post we will focus on the new SSD that are coming on this machines. Based on the configuration, the new D-Series machines are coming with local SSD that start from 50GB and goes to 800GB.
It is pretty interesting to put a MongoDB server on this partitions or other intensive I/O application. Also, if you have SQL Server on a VMs, you can put BPE (Buffer Pool Extension) on that partition. Don’t forget that BPE can be activated very easy and can increase the performances of SQL Queries. I expect a performance improvement of this kind of applications.
An important thing that you need to keep in mind. This SSD drives are only available for the TEMP drive. The operating system will still run on a classic drive. In future we may see other parts of VMs running on SSD, but is only a dream.
Additional to this, because we are in the TEMP driver (and we are using a SSD), you should add only data that you can afford to loss.
Benchmarks
I found an interesting benchmark related to Microsoft Azure VMs that I think that could be interesting for us:

A1 VM (1 core, 1.75GB RAM) Score: 2703
D1 VM (1 core, 3.5GB RAM) Score: 3947
A4 VM (8 cores, 14GB RAM) Score: 8705
A8 VM (8 cores, 56GB RAM) Score: 17186
D4 VM (8 cores, 28GB RAM) Score: 12645
A9 VM (16 cores, 112GB RAM) Score: 29873
D14 VM (8 cores, 112GB RAM) Score: 22017

MongoDB Load Test
Because in the last period of time I had the opportunity to play a lot with MongoDB, I had the setup of a load test for MongoDB. Nothing special, around 30M objects in one table. I only execute read operations over MongoDB, without any writes over it.
I run this load test 20 times on this machine, each time making a full restart of the machine. 10 times I had the database in the temp folder (SSD support) and 10 times in a normal folder (standard hard disk).
The results were pretty interesting, from my perspective. SSD disk improved with around 2.5X the performance of MongoDB queries. The result time is not very relevant, but the average execution time reduced from ~30ms per query to around ~13ms per query.
Take into account that SSD are not so fast when we need to make an insert or update. Because of this I didn’t even wanted to do a test like that. I don’t like the ideas to store content in a directory where I can loss all the information (like TEMP), but using a replica you can resolve this issues (but the performance will be lower).
Conclusion
There are scenarios when a SSD can help you a lot when you need to improve your performance, especially when you need to make a lot of I/O operations (especially read). I like the idea to have VMs with this kind of configuration and I expect to use them in the near future.

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…

Vunvulea Radu Tech Wall

Search This Blog