When building a web-based service that will be used by people all around the world you also have to think about network latencies that are imposed by geographical distances. Your service itself may be very fast, but it won't matter if users on the other side of the globe will experience it with a delay of 1 second. With Microsoft Azure, the cloud provider that we also use for all of our own services, you can choose from datacenters at different locations to run your service, thus optimizing network distance for your target audience. That is, of course, if you only want to run your service in just one datacenter and not in multiple ones to be able to reach more geographical regions on fast lines. We'll deal with the one-datacenter case in this blog post, since running a web-based service in multiple locations is neither technically simple, neither cheap, but optimizing the user experience for the intended target audience is something even the smallest applications are ought to do. So let's see how we can decide which datacenter to choose! The methodology described here is the same we used to decide where to deploy our Orchard SaaS, DotNest. Where are my users located? First, you have to determine where your (inteded) target audience is mostly located, since foremost you want users of your target audience to have the best user experience. If your service is already running in some form, or you know that your target audience is the same as one of your other service's than you can consult your web analytics to get some exact anwers. This is of course not available if your service is totally new and you don't yet have experience of this sort; then it depends on your business plan to make a guess that's sufficiently educated. For DotNest we decided that our primary audience is in West Europe and North America. This acutally is quite lucky match: since there are a lot of high-speed network cables laid out under the Atlantic Ocean between the two continents (as you can see from e.g. this slightly out-of-date picture) it's actually possible to find a location that will be able to serve both sides of the big pond equally well. Gathering the tools OK, now we know where our users are located. But how are we going to determine which datacenter is best suited for them? We'll make some measurements! Firstly we need to set up endpoints in all of the datacenters so we can use them to measure latency. For this we'll use Azure Web Sites: we won't deploy anything to the websites, the default page that a blank website returns will be enough, since we don't want to measure server performance but only network latency as much as possible. The websites will be just free ones, as the performance of a blank website, in our experience, doesn't differ from or vary significantly more than one on a paid tier, so it doesn't affect latency measurements. At the time when our measurements were made less datacenters were available on Azure, so we've only made test websites for those DCs, namely the following: http://eastasiaspeedtest.azurewebsites.net/ http://northcentralusspeedtest.azurewebsites.net/ http://northeuropespeedtest.azurewebsites.net/ http://westusspeedtest.azurewebsites.net/ http://eastusspeedtest.azurewebsites.net/ http://westeuropespeedtest.azurewebsites.net/ You can use these endpoints for your own tests if you wish of course. Since websites can go idle, especially the ones on the free tier, it's best if you warm them up by opening them before making any measurements. Seondly we also need some tool to measure latency of the various endpoints from different locations. For this we've used Alertra's Spot Check tool (see the textbox on the top of the page) that can measure response times from a variety of locations. (Another interesting tool to check the latency from your current locations to all Azure datacenters is Azure Speed Test.) Evaluating the results So we've set up all the test sites and have the right tool to measure response times. The next step is get the numbers clear and see which location performs best. For this purpose we've created a simple spreadsheet that you can use to evaluate the results. As you cen see we've made measurements to all of the websites with Alertra's tool and put them into a table. Then we calculated the average repsonse times for our intended target audience's locations, namely London, Chicago, Los Angeles and Washington DC in the P column. By simply changing the function that calculates the values in that row you can see the numbers for your target audience too. As one can see from the spreadsheet East US came out as the winner with North Central US being a close second. East US was faster than North Central US in the majority of cases and also a bit faster on average too. While the proportion of these numbers may be accurate, take the concrete values with a grain of salt. In our experience the actual response times are much better than the ones measured by Alertra's tool. For example from Hungary, where we're located, we can get a response from DotNest within 150ms at worst for cached pages, what is much faster even than what Alertra's tool measured from London (about 500ms) For DotNest we've gone with the East US datacenter, and so far it seems like a good decision. We've got numerous feedbacks form our users that the service is very fast. So where are you going to put your application?

This year's Orchard conference, Orchard Harvest will be held in Seattle between 9-11th June. A huge crowd of Orchard enthusiasts will be there, including renowed developers from Microsoft, that also provides the venue. And Lombiq will also attend: we'll share with you what we learned during creating DotNest in the last talk of the conference! See you there!

We are happy to announce the second developer competition in Orchard's history, the Orchard Spring Harvest Challenge! Orchard 1.8 was released recently and we'd like to give the developer community some boost to support this awesome new version, that's why the 1.8-compatibility is in the center of this competition: you can apply with a completely new module that is compatible with 1.8 or update your old module for the new version. For more information please visit the event's website (hosted on DotNest, of course).

Ever wanted to send some persistent notifications to the users of your Orchard site? This is now very easy with our new User Notifications module that we developed for RealtyShares: with User Notifications you can send notifications to individual users or groups of users, regardless the number of recipients. Tracy Gonzales, the Lead Engineer of RealtyShares said this about our work: This module has been in production on www.realtyshares.com for several months, and it runs without a hitch. Not only is it easy to use, but it's also very efficient. RealtyShares is able to send batches of notifications on the order of tens of thousands without straining the web server or interrupting the user experience. Scaling isn't a concern either, as the module was designed to handle much higher volume. The notification content is also token aware, so it's possible to send personalized messages addressing the user by name. This feature is very handy. If you're looking for easy ways to engage users on your site, this simple yet powerful module is an indispensable tool. Check out User Notifications so your users always can know what's up!

Orchard CMS lacked a software as a service provider until now: precisely a week ago we opened our first software service, DotNest. DotNest gives users the ability to set up any number of Orchard websites after registration, without having to worry about development, hosting, deployment and maintenance. Hosted sites can customized in a variety of ways, including the usage of recipes and complete control over styling. DotNest is currently in preview and thus completely free, including the premium features. Why don't you give it a try? Sign up and create your Orchard website!

Following the first Orchard university subject and the first open Orchard online course, Dojo Course, this year we continue with the first online university subject about Orchard. Óbuda University rolled out many online subjects this semester (to add to the list of "first"-s, this was also the first time the university started courses that were strictly just online courses, without any classroom attendance), one of them being ours: "ASP.NET MVC web application development using the Orchard content management framework" (which wins the award for the subject with the longest name too!). This is an exciting opportunity to test how well students can learn by just watching the tutorials, reading the supplied supporting materials and practising themselves. The project ideas we got submitted this far look very promising!

Our second Orchard university course finished - but this time it was also a massive online course. With the free and open Dojo Course we reached more people than we ever could with an on-site course. You can read the full case study for the Orchard Dojo Course and the Orchard university course on our Orchard training website Orchard Dojo.

Orchard, the beloved content management framework we built Lombiq on admittedly has a steep learning curve. Well, with great investment into learning Orchard comes great power or something, but still, how can we make some simple, everyday development tasks in Orchard easier? Can we also give beginner developers a tool to quickly flush out some simpler modules with only understanding the basics, leaving some more time to learn the whole system? We created the Orchard Abstractions module as a proof of concept. The module enables you to write content parts extremely easily. You remember (or if you're beginning with Orchard: you'll soon learn) that to write a custom content part you have to think about not just the part itself, but also about data storage (either with records or through the InfosetPart), migrations, drivers, handlers, you have to understand shapes (with intricate but awesome details like shape factories) and placement. With Abstractions we made this easier: as the bare minimum you only have to write a content part class (basically a simple POCO with virtual properties) and a display and/or editor template for it. That's it. If you want to be more advanced and display something through the part that should be calculated somehow you can attach such logic by implementing a simple interface. All this is what we called Quick Parts. On top of that Abstractions also contains Quick Widgets: by deriving your content part from a specific class you'll get your part set up as a widget for free. How about that? :-) Also everything you write using Quick Parts or Quick Widgets uses standard mechanisms in the background. So if you decide to go hardcore and customize everything you can do that by gradually enhancing what you've written to the point where you have the whole module done in the standard way. Your parts' data won't get lost, there is no data migration needed. Most of your code will remain intact and the remainder should just be copy-pasted elsewhere. If you feel adventurous take a look at the separate samples project and begin to write your parts - quickly.

Last weekend we've taken part on the Greenspiration startup competition in Budapest, Hungary. And we've won! You won't believe, but the green (i.e. sustainability, environment-friendliness) idea what we developed and then pitched is some hardware. So what was the big idea? Stay tuned, we'll tell you but beware that it's ridiculously simple. Meanwhile here's a picture of half of the team (Márk and Zoltán) looking concerned: The competition took place during the whole weekend, starting from Friday and ending with every team's pitches on Sunday. There was a jury of six renowned Hungarian venture capitalists, startuppers and even a counsellor from Hungary's National Innovation Office. They told that there was an agreement on our pitch being the best one. The three days were really awesome, we learned a lot as a team and got to know some great like-minded people. A big thank you for the organizers and congratulations to the other teams!

Recently the maintainers of the big Greek news site Parapolitika, the guys from the Greek subsidiary of Tatchit contacted us asking for our help: the site was going down routinely for some reason after going live (it was rewritten on Orchard from the legacy engine). The Orchard application was sometimes using up all of the server's CPU (despite it being a 24-core beast) and crashing the IIS worker process in the end. This needed some urgent fix because websites tend to be only worthy if they're alive... We immediately jumped into the task of getting the site stable! Neither the Orchard logs, neither the Windows Event Log revealed anything interesting. However soon we could experience the phenomena live: the worker process was eating up memory until at around 3,8GB while the CPU started spinning like mad and finally the process died. The Event Log told that ImageResizer.NET was running out of memory. Seriously? There are 32GBs of it, damn it! The culprit was the worker process running on 32b, thus not able to use the whole huge memory. While such big memory usage is not something Orchard does everyday (a vanilla Orchard instance in a 32b worker process uses about 80MB) this solved the immediate issue quickly. Together with some other tweaks to the server config the site was now running stable, quickly reaching new uptime records (although the previous uptimes weren't too hard to beat). In the newly gained peace we finally upgraded the site to Orchard 1.7.1 from 1.6 (the new version doesn't only give many features but also performs a way better). Meanwhile we also fixed an issue that could cause OutputCache to serve expired content. To quote Sotirios Roussos, CEO of urbanIT whom we worked with closely on this emergency: "After making some not demanding sites using Orchard, we decided to use it as CMS for creating the new parapolitika.gr, a really huge news site with more than 100.000 visitors daily and over 20 editors and a lot of content. It was a challenge for us and Orchard as well. Unfortunately, the first days were tough. Sudden breakdowns of site were appeared and the pressure was high. Orchard seemed to have limits, or maybe not? That's why we asked help for Lombiq, due to their experience into Orchard infrastructure. Fortunately, they did respond quick and spent hours and nights with us. Until we reach our goal. A stable and quick site. And, we did it. Thanx Lombiq! Keep up the good work!" It was a rush but we're really glad that we see a happy ending to this story!