rakkimk

After writing my earlier post on creating a simple WebJob to upload the Failed Request Tracing logs automatically to Windows Azure Blob Storage account, I was discussing this with the awesome development team of the WebJob SDK, Amit Apple, and Mike Stall. And, the outcome is, getting my sample modified to use the awesome WebJobs SDK that eases a lot of tasks. And there is more to it – cool Azure Jobs Dashboard with your Windows Azure Web sites giving you a cool dashboard of your WebJobs messages getting processed. With the WebJobs SDK, there is automatic way of……….

Currently in Windows Azure Web sites, there is an option to store your website logs to Azure Blob Storage, but however, the FREB logs – failed request tracing logs, can only be stored in the file system. You will then grab them via your favorite FTP tool, and do the analysis. One of my co-worker asked this question on if we can store the Failed Request Tracing logs in the blog storage, and Richard Marr gave this interesting idea of using WebJobs to move the files to Azure Blob Storage. I tried this quickly, and have a beta version of a similar webjob ready for you if you want to try it.

Yes, you are reading it right. It is true. It’s just a matter of one click to promote your staging website to be the production site. Gone are those hassles you were facing with publishing a new deployment to the live website, and some unbaked pages/assemblies, needless to say much pain, downtime, and probability of errors.

Websites being slow is perhaps the most common problem every website administrator, and developers run into. If they are extremely unlucky, then see this problem only in their production environment. Many troubleshooting techniques, best practices are available for this scenario. I will try to cover them in a different post as a part of my ASP.NET Troubleshooting series some other time. Meanwhile, you can try looking at this post of mine, where I’ve something that might help you.

Editing a small piece of code, or change in configuration file is perhaps the most common thing for a developer to do while testing the site, or even when the site is live for production traffic. When you host in with some hosting providers, most often you end up re-deploying the whole package, or transfer that file over FTP, or any other deployment methods. In this blog, I’m going to cover a few other methods which will help you edit your files of your website hosted in Windows Azure Web Sites.

People do want to remove this header as a part of some of their security audit that claims to know the server software running their site, and that knowledge will make an attacker craft malicious attacks known for that server version. If you are on latest versions of any server side framework, you should be good. But, some think it is always a good idea to remove that.

Users moving to Windows Azure Web Sites (WAWS) is increasing day by day. Happy to see many of the PHP websites being hosted with WAWS. If you are hosting your high traffic website with WAWS, I would like you to consider increasing the queueLength property of FastCGI handler for PHP that handles your request. By default, the value for queueLength property is 1000, which means only 1000 concurrent requests can be in the queue getting processed. For a many high traffic websites, this might seem to be a low number, and you would start seeing 503 errors in your instance logs.

Yeah, this is one feature everyone wanted for a long time. An online editing option, with all (okay, almost) the goodness of Visual Studio. Here is my step by step guide to do the same. I’m assuming you have already created a Windows Azure Web Sites. If you haven’t, you can read about that here.