Cloud as a Story - Vunvulea Radu

In our system we are using Azure Table to store a list of commands that needs to be send our clients and persisted until the client is available. Because the number of clients is high (more than 100.000), it would be very expensive to store the list of commands in other resources like Redis Cache or SQL Azure. From the performance perspective, Azure Table are amazing, very fast even at high throughput when you store a lot of data inside them. At the first version we done a simple mapping, where we had only one Azure Table for all our clients. For each client, we had a dedicated partition in the table. This works great because Azure Table is partitioned (scale) based on the partition. There is only a small problem with this approach and is related to maintenance and support. If a support engineering needs to look at the commands of a specific user it will be hard for him to navigate and access the data. The second approach is to create a different Azure Table for ea...

One year ago I started to investigate how we could use Load Test feature that is available on Visual Studio 2013 Ultimate and Microsoft Azure on our own project. The main idea was to develop a mechanism to test complex scenarios (especially written in C#) that can simulate 10k, 20k and even 100k users. The idea was accepted by client and we end up with a great and interesting application that can block a system witch worth millions. This is great from both sides. Mission complete for the team that defined the load tests, because they were able to define the load tests. But in the same time great for the development team and especially for the support team because they know the limits of the system. Now, we stuck with another problem. Because we are using Microsoft Azure infrastructure to run Load Tests (having our own hardware would be to expensive), we cannot simulate calls from multiple IP address. This is a current limitation Visual Studio Online - IP Switching feature is not yet...

The new Load Tests features that are coming with Visual Studio 2013 are great. In combination with Windows Azure and TFS Controllers, you can run load test using cloud infrastructure without having to deploy or configure something things on the cloud. When developers start to create different web test that will be used for load tests they usually them in sub-tests and reuse them when is possible. For example very easily you can end up with something like this: Foo1WebTest Foo2WebTest Foo3WebTest BigFooWebTest Where BigFooWebTest make calls to Foo1WebTest and Foo2WebTest. If you started to extract context parameters from each web test you will observer a pretty odd behavior. By default it is not possible to bind a context parameter. This means that you will not be able to fetch data for a context parameter from a data source like a csv file or data base. Even if you will write to the value of the parameter context the binding command (“{{..#TableName.CollumnName}}”) you will...

Mai mult ca sigur cu toti am folosit fisiere cu resurse (*.resx). Folosirea lor nu implica nici o problema, totul este destul de simplu, dar uneori apare nevoie sa accesam o resursa in mod dinamic. De exemplu daca avem fisierul de resurse "CarResources.resx" si vrem sa accesam resursa 'Power' avem nevoie de urmatorul cod: string powerLabel = CarResources.Power; Dar apare urmatoarea problema, daca resursa de care avem nevoie o putem determina doar la runtime? O solutie ar fi sa folosim ResourcesManager , care ne permite sa incarcam o anumita resursa in mod dinamic. Exemplul de mai sus ar trebuii rescris in felul urmator: var carResource = new ResourceManager("CarResource",Assembly.GetExecutingAssembly()); var powerLabel = carResource.GetString("Power"); Trebuie avut grija din ce assembly incarcati resursa.