Laila Lotfi

.NET tools Brand Manager & Simple-Talk Editor

What should you use to build a large scalable website?

Published Thursday, December 03, 2009 5:05 PM

If you were required to build a high-performance website with a great deal of traffic, what technology would you use? What is the most effective way to build a website?

One's initial thoughts are about the scripting language to use. When one looks at the highest-volume websites in the Alexa top 20, the technologies still seem to be predominately LAMP-based, and involving Python, PHP, Coldfusion and Perl. Only Microsoft sites such as MSN, www.microsoft.com and www.bing.com seem to show the flag for ASP.NET, and the Google sites go their own way with their mix of Python and C. Outside the top twenty, there are some high-volume sites using Java (Bebo, Ebay, the BBC). Ruby was, until recently, a favorite to succeed, but the enthusiasm seems to be receding. Mono is nowhere to be found amongst the giants yet, though there are large stable Mono sites out there (e.g. www.fiducial.fr).

It seems that the hosting platform you use, the configuration of load-balancers to the web farm, the performance of the message queue, the robustness of the database and the type of virtual environment, are more important for the responsiveness of a high-volume Web app than anything else. The type of web server matters a bit, but all the leading scripting environments have proved themselves in high-volume use. For the resilience of the site, diagnostics and profiling, along with good alerting in the event of problems, seem to be more important.

There is another problem that affects certain platforms: Both Ruby and Mono have displayed the problem when websites using these technologies are scaled up. In both cases the root cause has been the Garbage collector. The Ruby interpreter (Not JRuby or IronRuby) has its' own garbage collector, which is uses a primitive mark-sweep garbage collection algorithm which slowly "leaks" memory over time as the heap fragments. Mono still uses the rather conservative Boehm Garbage collector, which can lead to some memory fragmentation, and has to scan the entire allocated memory pool. This means that neither are particularly suitable for large-scale always-on applications for the time being.

The message one can take from this is that, if you are focusing on the debate of the relative merits of LAMP or .NET for a website, or the specific scripting language, then you may be looking in the wrong direction. Resilience and performance can be designed-in, using any platform as long as it supports good diagnostics, effective garbage collection, quality hosting and good message-queuing.

Cheers,

Laila

by Laila

Comments

 

wgbarnum said:

An interesting post. It's extremely high-level, however; I'd love to see the topic expanded.

For instance, how did you reach your conclusions on "what is more important than anything else?". I'm not challenging these conclusions, Ms. Lofti; I don't have enough data. I'm trying to learn.

I also had a couple of specific questions:

1. What is your definition of "hosting platform" in this context? It's an ambiguous term that to some people merely means "OS", while to others means "cloud computing".
2. I was under the impression that message queuing was best reserved for (A) broadasting paradigms, (B) asynchronous B2B transactional/workflow apps, or (C) situations that needed to handle disconnected-from-network scenarios. Are you saying that a site like Bing, where a user simply puts in a search term and expects a quick response, owes its performance to the use of message queuing? If so, where can I learn more? I mean in the high-level, strategic sense, here. I can always find out how to implement MQ.

Again, thanks for an interesting post. Tell me more!


December 6, 2009 2:11 PM
 

Laila said:

Yes, you're right, this is rather high-level. It certainly could be expandable to a book! :) My conclusions come from looking at the technology of the websites that have been most successful in scaling to a huge size. It quickly became obvious that a wide range of OS and scripting languages were being successfully used. I also looked at various sites that had difficulties in scaling.  I then just looked at the common denominators of the successful sites, and looked at whether these  were successfully implemented in the less successful sites.

1 By hosting platform, I’d exclude entirely the ‘cloud-based’ paradigm, purely because it is so ill-defined. I’d include the both the iron and the OS. It is difficult to be precise in a large distributed system that can include both Linux and Windows, and a whole range of different databases.

2 In any large-scale distributed system, I’d have thought that a good asynchronous messaging system was essential. This applies to any site that handles relatively long-lived transactions.  I’d include Java Messaging Service (J2EE with MOM) or Service Broker (Windows).  If it is properly implemented, a system that uses a reliable messaging service also cuts out a great deal of complexity from the business tier, even where transaction-integrity isn’t an issue.  There seems to be very little on the internet on the high-level  strategic use of Service Broker (please prove me wrong, someone!), but the use of Service Activators, JMS  and message-driven Beans in Java  is well-covered. I’d recommend Klaus Aschenbrenner’s  ‘Pro SQL Server Service Broker’, as it has a good general introduction to this type of architecture.

December 7, 2009 12:45 PM
 

venkateshsrini3 said:

I think when designing a large commercial application with a stiff SLA like being acessible 24*7*365, then we obviously need to see how we are going to 'segregate' your application. Intersetingly I had an oppurtunity to work with a world class health care provider. There was a demand from client that they needed the best of the breed performance and top class flexibility in configuring fall back startegy and lots of dynamizm. Our senior architect was bold enough to say that there will be some compramises that needs to be done if an optimum mix of all these needs to be present and we were able to explain them with few prototypes that our view is correct. Those were the days when only ASMX king of web service were available and IIS was a necessary evil if we have to use Application distribution

But today I see MS has come a longway by providing lots of hosting problem. So when we go in for large scale application development we can go in 'Distribution' at optimum levels. By this I mean that we can have a common business layer that is exposed and configured for various kinds of client. That is a client that sits outside the firewall to a client that sits on the same machine as that of the service host.

Again with respect to Garbage collection we can control the same through various instancing model and performance, durability and reliability through various concurrency models, throtelling settings.

With advent of .Net 4.0, Router services are in place and hence if you have a custom load balancing component that serves all your needs we can wrap the same Router service

With respect to message queue, I agreee that it might not scale up well. But in such a high demanding environment I would always look at the option of batching things together and use database to act as a queue store rather than MSMQ or any other MQ series. By that scalaing would also not be problem. When this is combined with Caching engines and Caching stores ( with synchronization frameworks like MS Synch framework) then scaling and performance should improve drastically.

Only thing that we should be watchful here is the cost of boundry crossing. Some time an oversight in this can eat the pulp that is delivered through these optimization.

If we happen to develop a fresh application of this magnitude then it is always a good practise to use components from sigle vendor rather than hetrogenous vendors. At least that has been my experience with Microsoft. They optimize their product to perform well with their platform.
December 7, 2009 10:51 PM
 

Seeriuss said:

I found an interesting view on scalability from someone at Yahoo. They would probably be in the top 20 of size and scalability. A previous employee Steven Souders feels as though the client side of a web UI contributes more to the download time of a web application than the server side.

You can see his posts here: http://developer.yahoo.com/performance/rules.html
December 9, 2009 11:21 AM
You need to sign in to comment on this blog

About Laila

I’m currently working as a Brand Manager in the .NET tools division of Red Gate Software. I also write the .NET Reflector newsletter, so if you have any feedback on the content you want us to cover, please do get in touch.


















<December 2009>
SuMoTuWeThFrSa
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
.NET Performance Testing and Optimization - The Complete Guide
 In the Complete Guide .NET Performance and Optimization, Paul Glavich and Chris Farrell offer a... Read more...

Mission Critical: SQL Server 2008 Engine Post-Installation
 Even an experienced DBA finds it safer to double-check that all the tasks have been done, and in the... Read more...

Raw Materials: The Trojan Horse
 Excuse me, was that geek or Greek? Read more...

Adding a KPI to an SQL Server Analysis Services Cube
 Key Performance Indicators, which vary according to the application, are widely used as a measure of... Read more...

Exploring your database schema with SQL
 In the second part of Phil's series of articles on finding stuff (such as objects, scripts, entities,... Read more...