views:

17327

answers:

20

I'm looking for some metrics. I'm currently tech-editing a book in which the author boldly states that "ASP executes faster than CGI and Perl". It's not backed up by any sources or anything that would lead me to believe that was a fact, so I'm wondering, does anyone know the answer to this question? I've done some google searches, but have not found any solid data as of yet.

So, which executes faster? Old school ASP or Perl/CGI? I know these are pretty out-dated tools, so I've thrown PHP and JSP etc into the question title to kind of make this a little more relevant to the community...

A: 

ASP is going to beat CGI for speed, simply due to the way it works. Don't dismiss Perl though, use it with FastCGI or mod_perl and its much faster (since the server doesn't have to spawn a perl instance for each request). You can even use PerlScript inside ASP.

David Dorward
A: 

For your spread, it probably would be a good idea to perform the benchmarks yourself. Some things to consider:

  • A dry run, without anything else, to see how much overhead the interpreter has
  • Hello world app
  • Benchmarks on some common algorithms, implemented in userspace code. For extra win, don't use anything that has a language-level equivalent
Edward Z. Yang
+1  A: 

It probably depends on your usage but i remember doing some speed tests with a heavy database driven site and PHP thumped ASP for speed by 300%.

Gary Willoughby
So you built the website in both languages and benchmarked what ran faster? =) Just curious.
Till
+25  A: 

You can have a look at some programming language benchmarks but there is a lot more to factor in than language speed:

  • Is there in-memory application or data caching?
  • How fast is the data access layer?
  • How fast is that platform's filesystem for the task?
  • How well written is the application?

ASP is pretty old and pretty slow but there are components for it that add decent caching, provided you use them. PHP is also pretty old and it lacks decent built-in caching features that newer frameworks have (eg: ASPNET's in-RAM Application/Cache stores) but it's made up for by community driven projects like memcached, APC cache, xcache, et al. Again, you have to use them to reap their benefits!

When you get to it, it's fair to say that you shouldn't be choosing based on performance, because with enough tweaking, you can get practically any language/framework to run damned efficiently. In short:

Make your choice on development merits, not deployment.

(or how much it costs to deploy efficiently, if money is a tight factor)

Edit: I wrote this post a long time ago and I've since found out another key factor in the battle of TCOs: maintenance of not just the application but the stack it sits on.

If you go with a paid-license platforms consider the costs of the licenses, how they renew, how many hiccoughs there might be between upgrades. And then there's the language itself: How easy is it to maintain your app written in x vs y?

I've personally found that Django/Python provides by-far the best rapid development environment (subjective), some of the fastest running code (though ASP.NET does come a very close second) and a very simple deployment setup that lends itself to scaling in all directions quite easily.

Your mileage will vary and you only learn the answers to some of these questions by developing something in a certain scenario but my big-bold statement above stands true: development is still the most expensive part of the puzzle.

Oli
I'm pretty sure the statement has absolutely nothing to do with programming language, any everything with the invocation model (process fork for classic CGI, not matter the language, while ASP is integrated into the server).
Michael Borgwardt
While I agree with what you are saying, I believe the post I marked as "the answer" answers my specific question, which was asking if the statement "ASP executes faster than CGI and Perl" should be included in a textbook on web development I was tech editing...
cmcculloh
+1  A: 

There are speed tests of languages on Debian's site.

PHP is slower than Java, and as JSPs are compiled into Servlets (i.e., Java code) they will be extremely fast as well.

I am also certain that all implementations will be held back by network latencies and communications (e.g., to the database, to downstream web services, etc). The faster languages will therefore be waiting longer than the slower ones (although that waiting is free cycles for other threads and processes to run).

Let's not get onto the issue of poor algorithm selection and data model choices slowing down the execution time of even the fastest language.

JeeBee
+4  A: 

CGI isn't directly comparable to ASP. CGI is just a gateway or protocol to interface with a program on the server and defines things like how GET and POST arguments are passed to the server-side program. That program could be any script or executable, assuming the permissions are set correctly.

That being said, the CGI model tends to require a process fork and complete initialization of the target program for every request. On the other hand, something like mod_php or mod_perl runs inside the Apache webserver (and probably ASP is implemented similarly in IIS but I've never used it). On one hand, it's much heavier to start a separate process every time than to keep one running inside the web server. On the other hand, it can provide some isolation in case the program crashes.

One solution that provides a compromise is FastCGI. It's faster than regular CGI and allows distributed processing of requests but retains the language-agnostic nature of CGI.

sk
A: 

I hope everyone here knows that ASP is different from ASP.NET. ASP.NET will probably beat out PHP in the real world. ASP is script, similar to PHP, but ASP.NET is optimized and compiled.

http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

peer edit: It should me mentioned that the text of this post is basically correct but the linked article is wildly inaccurate

Arron
This page is soo wrong, I can't believe this got upvoted.
André
+3  A: 

This is highly subjective, and depends heavily on implementation..

For example, CGI could be a C program, or it could be a perl program. CGI itself is just an interface between a HTTP Server and an application.

Likewise, PHP running on IIS6 does not have native integration and has to use a CGI bridge, while ASP/ASP.NET is natively integrated through ISAPI, so of course ASP/ASP.NET is faster....

The bottom line is that different languages may be faster (For example, the CLR that ASP.NET leverages is blazingly fast), but the form of integration really makes all the difference.

Since you are editing a book, I'd recommend the author remove this highly subjective content.

FlySwat
It also depends on how well written the code is. Plus if it is running on Apache I think the ASP.NET would be slower. Speed of languages is a terrible thing to discuss. It's far too subjective a topic.
Brendan Enrick
A: 

Not getting into a language war but

PHP and CGI are script languages. This means that Java and ASP.NET have about a 600% advantage over them. The numbers are there. As for which is faster between ASP.NET or Java, it is ASP.NET.

Speed tests via white papers have declared ASP.NET is faster than java. One good example is Cold Fusion is built off compiled java and MYSpace wrote a white paper when they switched from CF to ASP.NET.

They specifically state that ASP.NET is 40% faster in almost all categories.

Look it up and be impressed.

Scott
CGI is not a language it's a standard interface
André
And "script language" is a pointless distinction.
David Dorward
+10  A: 

This kind of statement needs to be backed with some context. Both Perl and PHP are interpreted scripting languages. As far as I know classic ASP (with an .asp extension) is also an interpreted scripting language which has to be interpreted with each web request. The overhead of loading a script and all of it dependencies with each request can be a significant part of the request to response time. Perl has mod_perl which essentially caches the results of an interpreted script and PHP has equivalent accelerators. But Perl and PHP do not come with these accelerators directly. Assuming you are running the Apache web server you need to compile these accelerators for your copy of Apache and set them up. From my experience that has been a tricky process but it does dramatically speed up your Perl and PHP sites.

With classic ASP I assume an accelerator comes out of the box so you do not have to take the extra step of putting it in place. I have been surprised how fast ASP has been for sites I have had to update. Since I started working with the Microsoft platform after years of working in the LAMP side of things (FreeBSD, Apache, and Perl in my case) I never did much ASP work. I just touch ASP occasional for legacy maintenance. I went straight into ASP.NET which is compiled, not interpreted. Normally you can expect a compiled solution to be much faster than an interpreted solution. If your author means ASP.NET (which some have started abbreviating as ASP in some books) then you may be dealing with the interpreted versus compiled distinction.

Still a script can sometimes be faster than a compiled solution, in some cases. A scripting language like Perl has been around a while and the interpreter has many optimizations that are in place to address known performance issues. Those optimizations take very readable code that is typical for the language and applies these optimizations. If you were coding something up in C, which specifically controls how a program is executed, you would not benefit from a runtime optimization in the same way. Also with Perl you may be using a module which offloads the processor intensive tasks to a C compiled component that does the heavy lifting very quickly. The benefit is that it is faster to write the script for your custom needs while it runs possibly as fast or faster than the purely C solution. With more work to manually optimize the C alternative you could make it much faster. But where do you want to spend your labor dollars? If I can do it quickly and essentially get sufficient performance in 10% of the time, why would I do more work?

With the possibility that a scripting language can be faster than a purely compiled alternative then your authors absolute statement that one thing is faster than another cannot be true. I would at least note the distinctions in a side bar. Not all things are equal, as the phrase goes.

Brennan
+2  A: 

The general rule I to go by is that interpreted languages (i.e. languages that require the script to be interpreted [e.g. PHP, ASP, Perl]) are an order of magnitude slower than compiled languages (ASP.NET, C, Lisp, Native Java).

Nevertheless, the performance effects of compiled vs interpreted code do not come into play until a server gets hit with AT LEAST 200+ users at one time.

Matias Nino
+1  A: 

I'm not completely sure how to answer because there are different factors that affect your performance. Generally when you're comparing languages, actual programming languages vs. scripting languages like php will perform better since it will probably be precompiled. When you have to precompile, you've performed a chuck of the work already. In php, your code is interpreted and compiled dynamically when your script runs. So, php has more work to do off the bat interpreting your stuff, which is already done in a precompiled solution.

A: 

Learn once and program forever--if you are a java programmer,jsp use JSP. If you are .Net (C# or VB) simply use ASP and, likewise-if you are a C use PHP

I disagree with that sentiment, keep learning all the time! Also, C and php are very different!
Jiaaro
+2  A: 

Non-interpreted languages execute faster, but this isn't really here nor there since the longest wait times are on database transactions, and web applications aren't used for CPU intensive tasks. Therefore whichever has the best DB driver support, for one, could be factored in to analyze what you think is the 'quickest' language, however....

Really, 'which language is faster' is a pretty darn open-ended question to which no meaningful 'quick answer' will work or mean anything. Books, technical books that is, could be written on this, en-volumes.

Zombies
+2  A: 

Given that you can write CGI pages in C ...

Vasil
A: 

All things come at last that what is more economical,robust and secure. If you have a combination of all in terms of human,money and time you should opt that. Have a business analysis between asp,jsp and php http://phpwala.wordpress.com.

A: 

Here is a test which shows that ASP.NET running on a home server (Windows XP) runs several times quicker than PHP on the Zend accelerator: http://www.pzycoman.myby.co.uk/lspeed.html

PS: Somebody posted a Wrensoft link above and said PHP is faster than ASP, though this is misleading since, PHP in this particular test may be faster than ASP, BUT ASP.NET is faster than PHP:

Regards, Financial Developer

this isn't really a fair comparison, php on mod_php is significantly faster on linux than windows, not to mention that windows xp isn't exactly a server
Jiaaro
+1  A: 

The question is not only how fast should a particular development technology is but how well does it scale on real world production environment. CGI may be fast in handling single requests at a time compared other technologies but it does not scale well for real world scenarios where request are enormous using the same set of hardware.

nitroxn
A: 

About ten years ago, (how's that for leading with an implication I'll be talking about old, outdated technology?) my CEO and CTO called me in a panic shortly after I started with the company. An advertisement came out prematurely before the company had a chance to bullet proof it's website which was still in beta at the time. Traffic flooded in and the one poor web server ran up a CPU load of I think 50 or 80 which was far higher than I had seen in my years of Unix system admin experience.

The application they were running was a 14,000 line Perl CGI program. No mod_perl. No FastCGI. So, every time a person visited the site, Apache would bring in perl, all 14,000 lines of code (with all the includes), and then do a just-in-time compile. After that, the application would start running, initialize its variables, log into the database, and only then could any real work take place.

The lead engineer made a very small modification, made it a FastCGI program with a loop so the program would start with the web server and loop. It ran literally 135 times as fast. One alternative we might have chosen was to buy and rack up 135 servers instead, but once the change was made, we had a hard time getting the two servers to show any indication they were being burdened in the least, so we had plenty of room to grow.

That's a wordy way of saying what the others said, that FastCGI is a way of delivering Perl based services in a way that can be blindingly fast compared to CGI, and that can be true regardless of what language you use.

Now, as for PHP, I set up an APC cache for my web applications. I believe it brings in the PHP code, does the just in time compilation thing, and then keeps the code in memory giving a similar boost. You can also issue commands to store data in the memory cache for fast access which sort of brings up the point of caching, and there are many kinds. APC caches your code and can cache data. Memcached is a memory cache that can be accessed via tcp meaning that several web servers could share a single cache. I think it is about 2 or three times slower than APC, but it serves a different purpose. Memcached also lacks security protections, so you have to rely on good firewalling to keep it accessible only where you want it to be.

Many blogging and CMS systems based on PHP have modules or plugins that can make use of APC memcached or other caching methods including caching to the disk. There are page caches that can store the entire generated page if desired with limitations so that logged in users don't get cached, for example. There are object caches that may store the results of a module or block making construction of pages happen faster. And there are caches for database queries which are usually done in memory possibly for the time of a session, but more likely just to avoid making the same query twice during generation of a page, and sometimes that can be done better sticking the results into a variable rather than trying to access something external.

And whatever language you use, if you're using Apache, for instance, or most likely most web servers, you can generate the page and stick it into a cache directory on disk and tell your server to check there first before going back and re-generating the page. This will buy you some rather extreme speed as well. For Apache, this is usually done in .htaccess pages, but since I'm on a VPS and have the freedom to configure my apache server more completely, I avoid using .htaccess files altogether to get a little bit of a performance gain there as well. So, I put all that stuff into a mini-configuration file for each virtual server and "Include" them at the end of my httpd.conf file.

Java is a fast language--about half the speed of C or C++ I believe since there is a little interpretation going on. But, it's nice in that it is multi-threaded and it's pretty easy to set up connection pools for a database. Other languages also have methods for setting up persistent or shared database connections. You have to be careful about security, but it's so common that security measures are also common.

However, whenever you have some multi-threaded listener or handler or multiple processes waiting on ports for a connection, you have the possibility that one of them will hang. On the other hand, there are ways to get around that. For example, having one process write to a request queue internally while other readers pick up the requests and execute on them much the way Tuxedo works, for example. If one server hangs, it can be killed and restarted and there is a good chance that only the outstanding request will be affected.

Another thing you might consider for speed is plain old Ajax. Set up places on your webpages for forms and places to receive data, and let your browser's javascript and the server talk tersely rather than passing a whole web page each time. Do as much form validation as possible in the browser to keep the load on the server light. Minify your javascript and CSS and optimize your graphics. Consider spriting your graphics where it seems appropriate so that all your buttons, icons and stuff come in one fell swoop rather than forcing the browser to request 10 or 20 different gifs, pngs, or jpgs. If you have a lot of photographs, consider keeping them on a content delivery network to keep the traffic off your web server.

What else? Design your javascript and CSS in several files for maintenance, but glom them all together and minify the whole bunch of them to lower the number of requests.

What else? Minimize the work required of the database. It will make your application scale better. It's easier to multiply the number of web servers than the number of database engines since the databases would have to be kept in sync. Analyze your database tables. Make sure they're indexed properly--not overdone, not under. They will speed up your access and slow down your writes.

Every time I touch on something, it seems there are a million more things to go into, and I've probably gone into way too much and have veered far off from the original question about which languages were fastest. I just have to concur with some of the other folks who may feel that any language can be fast or slow depending on how you code and configure it. But, for raw speed, I imagine C would go like blazes with C++ only slightly slower, Java about 1.5 to 2 times slower these days with older versions slower. It's weird. I use PHP all the time, but I have never compared it to other languages, but with an APC cache, I find my WordPress installations pretty fast on a simple VPS. I cannot say about Ruby or Python as I've only played with them a little. I've heard Ruby is nice but slow and that Python is easy for beginners.

I hope something I wrote here will be worth reading. It sure was long :-) Yikes...

Dan Dick
A: 

I've seen lots of analyses and ASP.NET is the fastest server language. The order of speed is:

ASP.NET --> JSP (JAVA) ----- orders of magnitude slower ---> ASP and finally PHP

ASP.NET in general runs much faster than Java because it is usually optimized to the particular OS, whereas Java is abstracted more, therefore adding more layers between it and the OS call. I've looked at the base code to ASP.NET and I have to agree that it is better optimized.

But of course if you spend more time in your Db engine and your Db engine is integrated into PHP and not natively into ASP.NET, you can see that the PHP runs faster in that particular case. But every time I have used PHP it always ran many times slower than the ASP.NET pages. (And yes, I was forced once to rewrite a web app into PHP from ASP.NET!)

In a perfect world, I would make everything C#, ASP.NET with C and assembly when possible. ASP.NET a serious improvement over Java. And with the Oracle takeover of Sun, I am really not sure Java will be able to catch up. It already lacked enough support as it was and now... game over...

Jordan