Friday 2 August 2013

.Net Hosting and Memory Usage


As is often the case, when you build a .Net web application performance all seems absolutely fine on your local machine. 

Of course, you have unlimited resources and your probably not running a hundred websites. Even so you’ve probably written efficient code and done some general performance testing. Generally you’re pretty happy that you’ve written a reasonably performant application. 

Then you deploy it to a Hosting company. You start seeing some strange results e.g. you intermittently have to re-login into your admin section; there are reports that the shopping cart is resetting itself etc. 

What’s going on? 

When looking through the Hosting companies packages one thing they fail to mention is that they will limit the amount of memory that your application can use. 

Don’t get me wrong, you can’t allow one application to use all the server resources but some of the allowances are just a joke – 128mb in this day age won’t run anything! 

Below is a non-scientific survey of a few suppliers picked at random – apart from ASPNetHosting who I was having the problem with. DiscountASP are a company that I use for other applications and never had a problem with. Even in this small sample it is amazing to see the wide variety in allowances.





Tips: 


  • Try and go with the latest technology on offer as memory can be much cheaper. 
  • Make sure you upgrade where your host allows you to do so. 
    • For example the following is a quote from DiscountASP: “100 MB of memory on IIS 6, 200 MB of memory on IIS 7, and 300 MB of memory on IIS 8”. The have an option in their control panel where you can automatically upgrade for free!

Tuesday 22 November 2011

HTML5 v's FLASH v's SILVERLIGHT


Introduction


HTML5 kills off flash; HTML5 kills off Silverlight; HTML5 makes the dinner and does the ironing too. HTML5 is going to save the (tech) world. I’ve heard it all in the last year or two. Very rarely have I seen a balanced article or a writer that understands the concepts involved. Even worse are the (non technical) tech journalists who write an article on this subject purely to boost their own exposure.

This article attempts to provide a bit of history on the subject. It also attempts to pacify the situation and explain why it doesn’t really matter.

This article focuses more on Silverlight than other technologies but the principles are the same for these too.


Background


FLASH and FLEX


Flash arrived on the scene many, many moons ago to add some pizzazz to the web, largely because HTML was limited and hence the experience was pretty mundane and boring.

Flash is a plug-in that needs to be installed on the CLIENT machine running the browser. Notice the word CLIENT here as this will become important as we go along.

As the years went on, people tried to push Flash to act more like business applications that you would normally build in .Net or similar. ADOBE (Macromedia) realised this and also realised Flash wasn’t up to the job. FLASH was useful for animations and small scale web stuff but not Enterprise level applications.

Most people don’t know ADOBE brought out FLEX for this purpose. FLEX was used as the front end for business applications and charting type stuff. This would be as an alternative to java server pages (jsp) or asp.net.

SILVERLIGHT (SL)


Around about the same time as FLEX was gaining momentum and maturing (around 2006) MICROSOFT was building SL.

SL was released in 2007 but the first mature version arrived in 2008 with SL 2. SL was a direct competitor to not only FLASH but ALSO FLEX. This is an important point that most people don’t get and hence don’t understand why the current chatter about HTML5 vs. FLASH vs. SL is not as important as they think.

HTLM and Javascript (JS)


HTML and JS have been around for ever and have always been popular web tools because they are free and cross-browser compatible. It is only in the last couple of years with the hype around HTML5\JS that the HTML5 vs. FLASH vs. SL chatter began.

There was a slight precursor to this which was the browser video playback chatter that everyone and their donkey had an opinion on too.

It is worth noting that HTML5 can only run in a supported browser that is installed on the user’s CLIENT (PC, laptop, tablet, mobile etc). Effectively this is the same thing as a plug-in. If it isn’t on the client then HTML5 won’t work. FACT!

To date around 40% of web browsers are nowhere near HTML5 compliant. This seems to be a fact ignored by the current band of HTML5 evangelists.

APPLE


Apple effectively banned plug-ins from its products. This is when this discussion really kicked off. While annoying all of their users by doing this i.e. they couldn’t run a flash websites or video, users still bought their products. There aren’t many companies that can do that.


Back to the Present


This brings us up-to-date and back to the HTML5 vs. FLASH vs. SL argument.

The fact is that you cannot control the web if you need a plug-in to run your product. This has always been case and anyone who thought otherwise is naïve at best.

‘Oh but flash was on 95% of clients so that’s not true’, I hear you shout. Yes FLASH was on 95% of clients but which version did you have installed?

In a previous life I was a FLASH developer and you would always have to wait around 1-2 years before you could develop a flash website in the latest FLASH version. Why? This is how long it would take for a large enough percentage of web users to install that version of the FLASH runtime on their clients. We always developed in a version behind the latest version, unless we could control what was on the user’s CLIENTS. There was no point developing something, no matter how cool, if only 20% of your target audience are able to view it.

The writing was in the sand, some might say?

Where are we now?

  • FLASH and SL are dead for the web.
  • HTML\JS have won the battle for the web.

That’s it then? No. This is only (less than) half the story. While the next few paragraphs focus on Silverlight, you could quite easily make similar arguments for other technologies that are 'dead'.

The Enterprise


One big factor in this is the Enterprise. An Enterprise is a company or business, usually, but not necessarily, of a large size. An Enterprise will have thousands of employees, working at different locations, sometimes around the world.

Enterprises like Intranets – internal browser based communication systems. Enterprises like browser based applications that run on these Intranets because they are easy to distribute and maintain.

Employees of Enterprises work on clients (PCs, laptops etc). These clients are owned and maintained by the Enterprise i.e. Enterprises can install whatever they want on their client machines – see I told you we’d come back to the client thing – and have the processes in place to do this regularly and en-masse.

The take of up SL, and FLEX to a much lesser degree, within these types of organisation is massive, especially in the banking sector who rely on rich, interactive applications (my version of RIA). Other technologies just do not cut the mustard. This is a FACT!

SL has a great advantage in these types of organisation who are mainly .Net based organisations – there are a lot of JAVA based ones too, who would probably have used FLEX rather than SL: SL sits nicely in their application stack.

These Enterprises build applications in an N-Tier fashion. This would involve a Presentation (UI) layer, service layer, business layer and data layer for example. This means their skill-sets are lean and advanced, having great cost benefits for development, testing, deployment and maintenance.

JS just can’t touch JAVA or .Net in terms of being a mature, deep, high quality programming language. JS has a small set of base classes and can’t stand alone needing to be interpreted by a browser, for example.

SL uses its own subset of the .Net framework so works within a managed environment. People who are used to .Net are already (partly) used to SL.

Enterprises have big sacks of cash, and, usually, money talks.

Windows Phone


Windows phones are gaining great momentum as we speak and SL can be used to build apps for these phones.

This adds weight to SL as a product.

Of course you may, and should, question whether it is appropriate to use HTML5\JS if you are developing the same app for Android and the iPhone.

Who knows, if apps become more complex (likely) then SL might be back in there. The more complexity the more likely JS is to be problematic as a solution.

XBOX


It is also worth noting that Microsoft may give SL a new lease of life within the Xbox and Kinect environment: http://tinyurl.com/3v3lsyw. One to look out for and again adds more weight to SL as a product.

Summary


What’s the common thread between all this?

  • you can control the client you can control what you develop in. It doesn’t matter what Apple or anyone else say.

As with any development you should always ask ‘What is the best tool(s) for the job?’

In the Enterprise this is regularly Silverlight. SL 5 will pack a whole lot of weight compared to SL4. All the gaps and missing functionality will now be there. SL 5 is a mature product and will be good for a couple of years on this release alone. If the answer to the question above is Silverlight then use Silverlight. If it is something else use something else. Simple!

Will MS produce a SL6 or SL7? It would be nice, but it doesn’t really matter at this point in time. Things change. Being a good developer means keeping on top of your skills and moving with the times. None of us were Silverlight developers five years ago.

XAML and c# will definitely be skills that will be usable in the Windows 8 environment and your SL apps will run fine there too ( http://tinyurl.com/7n8pp62 ) so stop worrying.

As 37signals say ‘Planning is guessing’. This is so true. Concentrate on the next few months as this is hard enough to do well. What you think will happen in 2 years time probably won’t and something completely different will.

This is the paradox of the world we work in: we love the fact that technology changes so fast, we hate the fact that technology changes so fast.