Why is ASP so SLOW?! [modified]
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
nalorin wrote:
I've found that, in general, PHP-driven sites generally take less time to load than ASP sites.
tough call.... what kind of traffic did they each manage? what level of interactivity/programming, skill of the programmer? what volume of data did they parse and spit out? what is the underlying access layer for data? XML? SQL? I have seen many sites, ASP and PHP and in general I don't like to compare them. ASP sites tend to be much larger in scope than their competition on the PHP so there is absolutely no foundation of comparison. I have seen PHP sites that use XML in the background and ASP that uses SQL and vice versa, I have seen really seriously screwed up code under both, and I have seen some neet hacks under both. But in the end, it is difficult to compare them without a common foundation of comparison.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
asp and aspx are two totally different things.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
nalorin wrote:
I've found that, in general, PHP-driven sites generally take less time to load than ASP sites.
tough call.... what kind of traffic did they each manage? what level of interactivity/programming, skill of the programmer? what volume of data did they parse and spit out? what is the underlying access layer for data? XML? SQL? I have seen many sites, ASP and PHP and in general I don't like to compare them. ASP sites tend to be much larger in scope than their competition on the PHP so there is absolutely no foundation of comparison. I have seen PHP sites that use XML in the background and ASP that uses SQL and vice versa, I have seen really seriously screwed up code under both, and I have seen some neet hacks under both. But in the end, it is difficult to compare them without a common foundation of comparison.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
what level of interactivity/programming, skill of the programmer?
That's something that I should have been more quick to consider. My wife has a website running on a LAMP server in our home that she made between 14 and 16 years old. This particular website has really slow forums (this is because every time the forum, or a board within the forum is loaded, it counts all the posts in each thread). Recently, as part of a University project, she has revamped that system, and the pages load instantaneously. I suppose the experience of the coder plays a huge part ^_^
-
asp and aspx are two totally different things.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Christian Graus wrote:
asp and aspx are two totally different things.
sure because remember, not matter where you go, there you are.
led mike
???
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
Because ASP.NET sites tend to push the technology harder and have more back-end processing? Let the flame war begin! :D Site speed (for large data driven sites) is usually a function of the database backend. PHP and ASP.NET will be around the same speed (slow) if the data access is terrible.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
???
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Because ASP.NET sites tend to push the technology harder and have more back-end processing? Let the flame war begin! :D Site speed (for large data driven sites) is usually a function of the database backend. PHP and ASP.NET will be around the same speed (slow) if the data access is terrible.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Let the flame war begin!
Okay, just put on my fire suit :rolleyes:
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Because ASP.NET sites tend to push the technology harder and have more back-end processing? Let the flame war begin! :D Site speed (for large data driven sites) is usually a function of the database backend. PHP and ASP.NET will be around the same speed (slow) if the data access is terrible.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Sites implemented in .NET (and Java EE, for that matter) tend to be higher-traffic sites than the ones written in scripting languages such as PHP or Perl. The high-traffic sites that are implemented in PHP are slow during peak times, too.
-
Because ASP.NET sites tend to push the technology harder and have more back-end processing? Let the flame war begin! :D Site speed (for large data driven sites) is usually a function of the database backend. PHP and ASP.NET will be around the same speed (slow) if the data access is terrible.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
and have more back-end processing?
some people like front end processing, others back end processing.... to each their own. ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
El Corazon wrote:
what level of interactivity/programming, skill of the programmer?
That's something that I should have been more quick to consider. My wife has a website running on a LAMP server in our home that she made between 14 and 16 years old. This particular website has really slow forums (this is because every time the forum, or a board within the forum is loaded, it counts all the posts in each thread). Recently, as part of a University project, she has revamped that system, and the pages load instantaneously. I suppose the experience of the coder plays a huge part ^_^
nalorin wrote:
I suppose the experience of the coder plays a huge part ^_^
it plays a HUGE part! anyone not experienced can totally screw up any and every language known to man. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
It's because IIS is driven by hamsters, while Apache is driven by gerbils. The gerbils run slightly faster than the hamsters but they wear out more quickly. That's why Apache has so many plug-in modules - it saves the server administrator from having to replace so many gerbils all the time.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
-
Chris Maunder wrote:
and have more back-end processing?
some people like front end processing, others back end processing.... to each their own. ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
> Let the flame war begin! Very simple and obvious on any CLR/JVM app you can think of.. They have huge frameworks behind, too many classes (re: instances will follow), complex dependancies, too many events (even TPs or even event pools don't help there), too many abstractions that keep 'wrapping' inefficiency under inefficiency (aka reflection, object casts, etc). Bring in the GC into all and you got what you've asked for. Dataset (a hack), Generics (a hack, look at the collections IL yourself:), WPF (ex mega-slow IE tech + giving a string to every field on the planet, flaky framework but hey it has coolness all over it), ASP.NET page model ( ugh ).. it is all over the place, collections, compiler starting to go against you, linq to streaming data deficiency. Need more? VMs have given object-based systems an attribute of: the slowest one (in the history of computing). There is nothing out there that can beat its slowness apart from BEA based and similar stacks (again VM). Gotta love it though.. otherwise you'll be looked at in a strange way anywhere you go (by not buying the crp that it scales better than slightly sophisticated interpreted based systems do ). For proof, just look at how lightingly fast Google is and all its infrastructure is accessed mostly via interpreted or script pieces on server-side. And it is all data-driven. Just because VMs do name to metadata tokens translation well, abstract you from binary contract, or because it does clever JIT optims, it doesn't mean hardware is not running away from that flawed abstraction above. Hence the software getting slower and slower. But yes, it does help to start simple and with a clean, simple, productive model such as .NET (than feed/scrap it to a proper framework-less *environment* ) So, over-simplifying with their mass-market recommendations while over-engineering aka Java-like productions.And it is still not polished to a level it could be, and I doubt it ever will be before it is replaced by something much, much simpler and more efficient.. Don't buy msdn blogs propaganda either, especially from PMs, it never delivered that spectacular work as hyped. Never will do.. it is becoming clearer than clean 100% Pure Orange Expensive Juice.
modified on Tuesday, February 26, 2008 6:55 PM
-
This thread is generating more anonymous 1-votes than I thought it would. Thank you for posting a question instead (even it it is vague). I am not downplaying the importance of good design, which can occur (or be absent) using any programming language, scripting or compiled. Which point did you want clarification on?
-
This thread is generating more anonymous 1-votes than I thought it would. Thank you for posting a question instead (even it it is vague). I am not downplaying the importance of good design, which can occur (or be absent) using any programming language, scripting or compiled. Which point did you want clarification on?
jesarg wrote:
Sites implemented in .NET (and Java EE, for that matter) tend to be higher-traffic sites than the ones written in scripting languages such as PHP or Perl.
That point. My question, better worded, is: Is this a conclusion of some study that has been done? My first counter-example to that would be Facebook. It is PHP and has an enormous amount of traffic.
-
I just had an interesting question. I've used many websites, being a child of the internet. And, in all my days of surfing, I've found that, in general, PHP-driven sites generally take less time to load than ASP sites. I've found that in about 4/5 cases (particularly with forums), sites that are obviously ASP-driven (you can see the .asp(x) extension in the URLs) often take several seconds longer to load than similar pages that are obviously PHP-driven. Any suggestions on why this seems to be? (I'm not saying ASP /IS/ slower... just that it /seems/ slower - my answer to my own question would be "Microsoft", which should explain everything, but I want the nitty gritty details!)
modified on Wednesday, February 27, 2008 7:33 PM
I've worked on some *fast* ASP.NET[^] sites, so it isn't a technological limitation. ASP.NET and PHP are targeted at two different types of developers. ASP.NET development is targeted at developers that just want to drop a bunch of controls on a form and have VS and the compiler work it's magic and poof you have a web site. They typically don't care that it takes a bunch of viewstate and extra page loads to make it happen. Plus to write fast ASP.NET code you have to limit the number of controls you use on a page, again something that goes against the form designer approach. I haven't used PHP, but I'm betting you are forced to deal with HTML and http requests more directly with less overhead. You end up having to do the same with ASP.NET if you care about performance and scalability, but it's rarely essential.
This blanket smells like ham
-
jesarg wrote:
Sites implemented in .NET (and Java EE, for that matter) tend to be higher-traffic sites than the ones written in scripting languages such as PHP or Perl.
That point. My question, better worded, is: Is this a conclusion of some study that has been done? My first counter-example to that would be Facebook. It is PHP and has an enormous amount of traffic.
Yes, I know that some high-volume sites are written in scripting languages. Yahoo also writes web applications in PHP. I said that higher-traffic sites tend to be written in compiled languages (and even pointed out that some are written in PHP). Almost all customer-facing financial applications for major banks are written in compiled languages nowadays, and from what I see, other industries that are writing new high-volume web applications are going the same route. No, I don't do formal studies, as I've been out of college for a few years now, but I and my friends and former co-workers work for a variety of different software development houses, some of which focus on compiled languages and some of which focus on scripting languages. (And facebook was slow just a few minutes ago, btw) :)