It's very easy to put an UpdatePanel and have AJAX working.
I am looking for resources on how to best use ASP.NET AJAX for maximum performance and security. Resources for best practices, guidance, design patterns, gotachas, pitfalls when using ASP.NET AJAX.
I am not looking for books on ASP.NET AJAX. Amazon lists those.
I really like Dave Ward's stuff on using jQuery and Asp.Net Ajax in unison. Especially his article on Why Asp.Net Ajax Update Panels are dangerous.
From the maximum performance angle, check out ASP.NET Ajax Under-the-hood Secrets, on Codeproject.com.
Subtitled "Performance tips and hard-core tricks that change core runtimes, not for the faint-hearted" it's about "the advantages and disadvantages of Batch calls, Ajax call timeouts, browser call jam problems, ASP.NET 2.0's bug in web service response caching, and so on."
It's a little over my head, but it might be relevant to what you're looking for. Since it's written by Omar Al Zabir, the guy who did Pageflakes, I think we can assume that it's solid advice.
Dino Esposito's two part article on MSDN Magazine is worth a read, AJAX Application Architecture Part 1 and Part 2. Covers some interesting topics including:
Optimization Techniques for Partial Rendering
Weighing Partial Rendering
Flavors of Services
JSON Versus XML
Security Concerns
Related
I have seen that ASP .Net Code Behind files are really slow. I have used local web services which I call from jquery ajax function and they are fast. But I am still confused? Should i display dynamic data from code behind or web services?
I let my web service return a JSON Object and I assign relevant elements from that JSON object to different html elements like (image, div etc.)
You need to weigh several things..
If you are dealing with a low-traffic, internal web application, perhaps server-side postbacks are the way to go. Often you'll find that there's less code you'll have to write in this case.
If you are working on an external, public, high-traffic web application, perhaps AJAX is the way to go. That way you avoid posting back entire ViewState and running through the full page lifecycle. This may result in more front-end code, but is less load on the web server.
Keep in mind that client-side data binding is a very viable solution these days, with the help of such things as jQuery Templates. So that helps bind data returned from AJAX calls to tables and other elements.
As far as web services go, they are great for when you're sharing data/functionality between different systems. If you don't foresee doing that for this particular application, then perhaps there's no need to over-engineer it - keep it simple with either MVC and Action methods that support AJAX calls out of the box, or get familiar with PageMethods.
I'm sure there are other pros/cons I haven't mentioned, but this is the first thing that came to mind.
ASP.NET classic life cycle and postback is the base of Microsoft Click&Go philosophy. It is not designed to be fast even if it suits in most cases.
AJAX plus Web Services architecture is good way to improve server performances and dynamicity. It may not improve client performances, may increase the network load if bad designed and complicate a website architecture.
Another possible orientation is ASP.NET MVC, where old life cycle and postback is ancient history.
Like Kon said, mixity is probably the best way at the moment : MVC+AJAX or ASP.NET+AJAX where classic client<->server requests are used for common functionnalities and AJAX requests brings dynamicity with small requests for friendly functionnalities.
Note that most users on the planet are using Internet Explorer who have the worst javascript engine on the planet ;)
I am considering rebuilding my ASP.NET portal using ASP.NET MVC. I use the same portal solution at two different web sites, and I would like to have a single place og editing and writing articles for my sites - a management site. I have considered making an "Article Web Service" that would provide me with the functionality of creating and listing articles - but how about performance?
On my portal i need to fetch all my articles to make a list of articles (full list - ~100 articles) then show a single article with comments. The same applies to forums, blogs, media gallery, and so on.
I think im blinded of the opportunity of providing me - the administrator - with an easy to use interface in one place where i control all the portals.
Would the extensive use of webservices slow my portals down so much that they become useless? Is there an alternative solution to doing this single point of administration, an alternative to WebServices?
cheers,
Sounds like a good idea for your architecture.
If you expose your database via a service, it creates a really great separation between your UI and back-end, so you can write WPF, Silverlight, ASP.NET, WinForms UI that all consume the same service(s) if you so desire.
You might want to look into WCF which gives you great flexibility as to where the services live and who consumes them and how.
Also, with a reasonable amount of effort you can implement things like caching and compression, which will alleviate any performance penalties you incur by the additional layer you'd be introducing.
For a straight MVC-based portal, you shouldn't need web services, unless you're making heavy use of Ajax or Silverlight -- but in those cases, the web services are called by the client, not from the server-side. Server-side WS are generally reasonably expensive from a performance perspective, and make sense only in certain limited high-scale, multi-server applications.
For your admin tasks, just build a set of protected pages with a UI that controls the admin functions you need. If you're feeling adventurous, Silverlight can be good, too.
If you're looking for some ASP.NET perf tips (though not wrt MVC), you might enjoy my new book: Ultra-Fast ASP.NET.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S
It's my understanding that StackOverflow (SO) was built using ASP.NET. What surprised me is it's so well designed and well implemented. Without knowing much about the internals of SO, here are my observations and educated guesses:
SO appears to be highly scalable.
URLs in SO are friendly.
It appears that SO does not contain a bunch of controls as most ASP.NET apps I've seen.
Judiciously and effectively use of Ajax requests, opacity animation, etc. Viewing source tells me SO is using jQuery.
SO runs on all major browsers (that I've used and this list includes IE, FF, Chrome, Opera).
Edit: 6. Comet-like feature: As you type your answer, if there is any other answer posted, you get the notification. If you choose to load it, of course only a partial page refresh is done and your answer remain intact. Have yet to see this in any other ASP.NET app.
So my questions:
What are other ASP.NET web
applications that are as well done
as StackOverflow and what are their
features that you like?
Can you share
about some more details about SO,
for example is SO built using
ASP.NET MVC or something else?
SO is built using ASP.NET MVC as explained by Jeff Atwood and his team in this podcast organised by Scott Hanselman
Listening to the podcast would be worthwhile.
One surprising element about SO which was revealed in the podcast is that SO runs on a single server (IIS & SQL Server). I was surprised by this.
ASP.NET Forms allows developers to build UIs in much the same way as .NET Windows Forms.
The whole idea was that a developer that knew how to build a 'Fat Client' Windows form could transfer those skills to ASP.NET forms. ASP.NET forms even allowed developers to pretty much put code on the same set of control events. The developer was sheilded from having to have any knowledge of HTML, HTTP, Javascript etc.
Unfortunately this resulted in large POSTs containing monster viewstate being generated frequently and hence a poor user experience. This is what has given ASP.NET a bad rep. In reality its the original ASP.NET Forms that should have the bad rep.
ASP.NET MVC, amoungst other things, embraces the nature of HTTP rather than trying to hide it. AJAX and JQuery are also features of MVC which add to the overall result being better.
That said having a great tool is useless without great vision, design and skill, the SO team clearly have those in abundance.
Orkut.com - A social networking site by google uses ASP.NET
SO was build with ASP.NET MVC. Jeff hired good developers, had a good vision, and ran his screens through a real designer.
Myspace.com uses ASP.net, which proves the scalability of the platform in general. You can also learn a lot about stackoverflow itself from reading the stackoverflow blog and listening to the stackoverflow podcasts.
Many of the things you point out about are actually due to the use of ASP.NET MVC. Pretty URLs come out of the box, non-standard controls, well nothing comes out of the box with MVC so you have to reinvent everything :), and finally the AJAX is pretty much a requirement for ASP.NET MVC if you want to do anything intelligent with it.
ASP.NET MVC alone does not account for the things which makes StackOverflow truly successful that's all down to the idea, execution, and the fact that Jeff and Joel combined garners a huge following on the net.
You can also learn quite a lot about the development, planning(!), etc in the two HanselMinutes podcasts on SO:
StackOverflow uses ASP.NET MVC - Jeff Atwood and his technical team
Behind the Scenes - StackOverflow and Jeff Atwood - Part 2
Available in numerous audio formats, as well as transcribed.
ASP.NET creates websites limited only by the talent of the developers.
The same can be said for virtually any framework.
That said, Windows Server/IIS/.NET is a hugely scalable concept, as we serve far far more traffic than SO on a ASP.NET site (Then again, we have 32 servers).
As mentioned in one of the answers here, myspace.com uses ASP.NET (as far as I know it was written in ColdFusion and used BlueDragon for .NET).
One other site is plentyoffish.com (60M hits per day).
If you want to read more about scalability see http://highscalability.com
I found some wild remarks that ASP.NET MVC is 30x faster than ASP.NET WebForms. What real performance difference is there, has this been measured and what are the performance benefits.
This is to help me consider moving from ASP.NET WebForms to ASP.NET MVC.
We haven't performed the type of scalability and perf tests necessary to come up with any conclusions. I think ScottGu may have been discussing potential perf targets. As we move towards Beta and RTM, we will internally be doing more perf testing. However, I'm not sure what our policy is on publishing results of perf tests.
In any case, any such tests really need to consider real world applications...
I think this will be a hard question to definitively answer as so much will depend on A) how you implement the WebForms application, and B) how you implement the MVC application. In their "raw" forms, MVC is likely faster than WebForms, but years and years of tools and experience have produced a number of techniques for building fast WebForms applications. I'd be willing to bet that a senior ASP.NET developer could produce a WebForms application that rivals the speed of any MVC application- or at least achieve a negligible difference.
The real difference- as #tvanfosson suggested- is in testability and clean SoC. If improving performance is your chief concern, I don't think it's a great reason to jump ship on WebForms and start re-building in MVC. Not at least until you've tried the available techniques for optimizing WebForms.
It decreased one of my pages from 2MB payload, to 200k, just by eliminating the viewstate and making it bearable programatically to work with the submitted output.
The size alone, even though the processing was the same will create vast improvements in connections per second and speed of the requests.
I think that many of the people who think that WebForms are inherently slow or resource intensive are placing the blame in the wrong place. 9 times out of 10 when I am brought in to optimize a webforms app there are way too many places where the apps authors misunderstand the purpose of the viewstate. I'm not saying that the viewstate is perfect or anything, but it is WAY too easy to abuse it, and it is this abuse that is causing the bloated viewstate field.
This article was invalueable in helping me understand many of these abuses. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate
In order to make a valid comparison between MVC and WebForms we need to be sure that both apps are using the architectures correctly.
My testing shows something between 2x and 7x more req/sec on MVC, but it depends how you build your webforms app. With just "hello world" text on it, without any server side control, mvc is around 30-50% faster.
For me the real "performance" improvement in MVC is the increase the testable surface of the application. With WebForms there was a lot of the application that was hard to test. With MVC the amount of code that becomes testable basically doubles. Basically all that isn't easily testable is the code that generates the layout. All of your business logic and data access logic -- including the logic that populates the actual data used in the view -- is now amenable to testing. While I expect it to be more performant as well -- the page life cycle is greatly simplified and more more amenable to web programming -- even if it were the same or a little slower it would be worth switching to from a quality perspective.
I think the problem here is that no matter how much faster ASP.Net MVC is than the old webforms, it won't make a difference, because most of the time taken is in the database. Most of the time, you web servers will be sitting at 0-10% CPU usage just waiting on your database server. Unless you get an extremely large number of hits on your website, and your database is extremely fast, you probably won't notice a big difference.
The only concrete numbers I can find which are from early ASP.NET MVC-development is on this forum-thread:
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery himself somewhat confirms statement that ScottGu has claimed that ASP.NET MVC can serve 8000 requests per second.
Maybe Jeff and his crew can give some kind of hint from their development of this site.
Contrary to the accepted opinion, optimized webforms usage completely kills MVC in terms of raw performance. Webforms has been hyper-optimized for the task of serving html far longer than MVC has.
Metrics are available on http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Every single comparison mvc is on the lower-middle/lower-upper rankings of the list, while optimized webforms usage places in the upper-middle/upper-lower rankings.
Anecdotal but very serious validation to these metrics, www.microsoft.com is served by webforms not MVC. Does anyone here believe that they wouldn't have chosen MVC if it was empirically faster?
There's really no way to answer this. MVC uses the Web Forms view engine by default itself, and can be configured to use any number of custom view engines, so if you want a performance comparison you'll have to be more specific.
I started out work in MVC about a year ago, I was inspired but not impressed.
I loath the view state and see it as the root of all evil in terms of ASP.NET. This is why I just don't use it and to be perfectly honest why would you?
I took basically the ASP.NET MVC Framework concept and built that in my own way. I changed a couple of things though. I built my controller wrapping code, or URL routing code around dynamic recompilation.
Now, I would go as far as to say that ASP.NET MVC applications will be faster based on how you use it. If you completely abandon WebForms you'll be faster becuase the ASP.NET life-cycle and object model is humongous.
When you're writing you're instantiating an army... no wait, a legion of objects that will participate in the rendering of your view. This is gonna be slower than if you where to express the minimal amount of behavior in the ASPX page itself. (I don't care about view engine abstraction because the support for ASPX pages in Visual Studio is decent, but I've completely dropped WebForms as a concept and basically any ASP.NET framework due to code bloat or not being able to change the things that wire my application).
I've found ways of relying on dynamic recompilation (System.Reflection.Emit) for emitting special purpose objects and code whenever needed. The executing of this code is faster than reflection but initially built through the reflection service. This has given my MVC flavored framework great performance but also very statically typed. I don't use strings and name/value pair collections. Instead my custom compiler services goes in a rewrites a form post to a controller action being passed an reference type. Behind the scene there is a lot of things going on but this code is fast, a lot faster than WebForms or the MVC Framework.
Also, I don't write URLs, I write lambda expressions that get translated into URLs that later tell which controller action to invoke. This isn't particularly fast but it beats having broken URLs. It's like if you had statically typed resources as well as statically typed objects. A statically typed web application? That is what I want!
I would encourage more people to try this out.
The projects created with visual studio. One is mvc4 template, another is WebForm (tranditional).
And when make load test with WCAT, this is the result,
MVC4 is quite slow than WebForms, any ideas?
MVC4
could get about 11 rps
rps is quite low both 2-cpu or 4-cpu server
WebForms (aspx)
could get above 2500 rps
the performance killer has been found that it's a bug of MVC Bata or RC.
And The performance would be improved once i remove Bundles things. Now the latest version fixed this.
Performance depends on what you are doing... Usually MVC is faster than asp.net mostly because Viewstate is absent and because MVC works more with Callback than Postback by default.
If you optimize your webform page you can have the same performance as MVC but it will be a lot of work.
Also, their is a lot of nugets for MVC (and also for Webform) to help you to improve website performance like combine and minify your css and javascripts, group your images and use them as a sprite, and so on.
Website's performance depend greatly of your architecture. A clean one with good separation of concern will bring you a more clean code and a better idea of how improve performance.
You can take a look at this template "Neos-SDI MVC Template" which will create for you a clean architecture with lots of performance improvements by default (check MvcTemplate website).
I did a small VSTS load test experiment with some basic code and found ASP.NET MVC response time to be twice faster as compared to ASP.NET Webforms. Above is the attached graph with the plot.
You can read this load test experiment in details from this CP article https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
Test was conducted with the below specifications using VSTS and telerik load test software:-
User load 25 users.
Run duration of test was 10 minutes.
Machine config DELL 8 GB Ram, Core i3
Project was hosted in IIS 8.
Project was created using MVC 5.
Network LAN connection was assumed. So this test does not account for network lag for now.
Browser in the test selected Chrome and Internet explorer.
Multiple reading where taken during the test to average unknown events. 7 readings where taken and all readings are published in this article as reading 1 , 2 and so on.