The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Fastest web language

While I appreciate this is maybe yet another q whose answer begins with 'it depends...' but I was wondering if there is any research/opinions/anecdotal evidence out there for the fastest (runtime) language to use when building data driven websites?  eg Is there a difference between the overhead for java's just in time compiled bytecode and that of the popular (interpreted) scripting languages like php?  What about RoR with it's framework?

I'm starting a greenfield project and have previously used classic ASP and JSP (with struts).  I have free rein this time round, learn-time and to an extent development time is not an issue.  I want the highest performance when the site is up and starts dealing with requests.
Entropy Send private email
Saturday, May 06, 2006
 
 
PHP?

ASP.Net is good (pre-compiled) but a different type of application.  PHP is more comparable to classic ASP (amirite?).  AJAX seems to be a buzzword these days :)

Nate.
Nate Send private email
Saturday, May 06, 2006
 
 
I wouldn't regard asp.net as a different type of 'application'.  Yes php is akin to asp in that it's a scripting language, asp.net running on top of a vm much the same as java's jsps. 

Explicitly what im looking for is given the same request submitted to multiple web applications doing identical processing, differing only in implementation language, which one returns the http response first?
Entropy Send private email
Saturday, May 06, 2006
 
 
In most cases, once you filter through all of the fanboy rants against their language's rival, most web-app languages perform similarly.  For most high-performance sites, the difference between interpreted and natively-compiled languages (like C, not Java) is minimal because the web app isn't doing incredibly complex computations.

Yahoo benchmarked their own compiled custom-C language against PHP+eAccelerator and Perl+FastCGI, and found that the difference wasn't very large.  (They chose PHP as their primary new development language.)

Once you scale up to the point at which performance actually matters, the database is usually the bottleneck.  Using efficient queries against an efficient schema is far more important than the language you choose for the front end.

Similarly, using efficient algorithms in your code is more important than whether it's compiled or interpreted.
Marco Arment Send private email
Saturday, May 06, 2006
 
 
Part of the "it depends" is what you consider as a "web language".  A C or C++ ISAPI filter would be very hard to beat for performance, but it has its downsides.
On the other hand, I'm not sure what the point of your question is.  The amount of time your code runs in a round-trip HTTP request/response is pretty small.  TCP/IP latency and db access are going to dwarf it.
bmm6o Send private email
Saturday, May 06, 2006
 
 
Yes, I agree with some of the other posters -- the language plays a small role in the whole scheme.

When Google use C++ or Java, actually they have their own frameworks built with those languages. I heard Google have their own web server made with C++ for example.

Thus, what you should look for is how to keep the data readily accessible to your applications, like in memory cache or pre-handled. How to cache the pages or partial pages to save the reprocessing every time they are used. And what way is the fast enough for your code, like Apache Module? FastCGI in Lighttpd? Something else? Load balancing, fail over, etc.

Ruby on Rails has out-of-the-box support for some of the above.
Lostacular
Saturday, May 06, 2006
 
 
thanks for the heads-up guys, I often wondered about this q and why I've never really seen comparitive studies on the web before, but if there are more pertinent issues then I guess that's why
Entropy Send private email
Saturday, May 06, 2006
 
 
Actually every Rubyonrails website I've seen so far seems terrible slow. Don't know what the problem is, but this is one thing that actually keeps me from putting more effort into Rubyonrails.

I like a snappy experience. Most Servlet/Jsp based sites seem to be very quick. PHP/ModPHP doesn't seem too bad either.
Fritz Huber Send private email
Sunday, May 07, 2006
 
 
I find it interesting that the single most useful web language, javascript, is also the slowest.  At least according to the language/compiler shoot-out web sites.

If you're going to have a high-volume web site you'll want to structure things so you can partition the back end across more hardware to get more performance.  The hardest thing to partition is the database.

I the RoR literature there is an interesting essay on "Shared nothing" that applies to any backend technology for partitioning.  The essay is probably in one of the Switchtower/Capistrano web sites.
Fred Seltzer Send private email
Sunday, May 07, 2006
 
 
"The hardest thing to partition is the database."

Actually, that's the easiest, since it involves virtually no programming. Most RDMBS's today have some kind of support for clustering -- even MySQL -- so it comes down to a question of good configuration.
Berislav Lopac Send private email
Sunday, May 07, 2006
 
 
My opinion is that all the language-runtimes are of commparable speed (particularly if you use a compiled-code-cache for PHP).

I've been doing PHP and Java development for the last five years, and I've seen some *extremely* fast PHP sites on very low-grade hardware (and in many cases, on shared-hosting accounts). These were web-applications performing 20 ~ 30 database queries for every single page and doing tons of string processing and formatting. These applications could serve hundreds of page-views per minute, effectively handling over a hundred concurrent users.

I've also seen Java applications absolutely craaaaaaaaawl. I've seen Java applications deployed to expensive, multi-processor machines with 4GB of memory get bogged down under the load of...ahem...twenty concurrent users.


The thing is, all other things being equal, I know that Java is an inherently faster execution environment than PHP. But enterprise Java developers waste all of that extra processing power on overly-complex architectures (Have you ever heard of a PHP developer writing a ReflectiveRequestInterceptorFactoryImpl class?)

So, I think Java/C# are probably the fastest web languages (I don't know much about .Net development, so I can't say much about C#) but most enterprise Java applications are mired in architectural complexity, so applications written in PHP end up being waaaaay faster most of the time, and able to handle more concurrent users.

(Of course, PHP has its own list of ridiculous problems, starting with things like "register_globals" and "magic_quotes_gpc" and the fact that the php.ini config file can drasticly change the behavior of any code in the PHP environment.)
BenjiSmith Send private email
Sunday, May 07, 2006
 
 
"Have you ever heard of a PHP developer writing a ReflectiveRequestInterceptorFactoryImpl class?"

Actually, yes. Check the postings on Sitepoint's PHP Application Design forum ( http://www.sitepoint.com/forums/forumdisplay.php?f=147 ) and you might be surprised. Personally, I nave used reflection, Request class, interceptors and factories in PHP, but admittedly not all of them together. :)  (And I do all my PHP completely OOP.)

"Of course, PHP has its own list of ridiculous problems, starting with things like "register_globals" and "magic_quotes_gpc" and the fact that the php.ini config file can drasticly change the behavior of any code in the PHP environment."

This is true, but this goes for any Web development framework. Remember, PHP is only secondarily a language; primarily it's a Web dev framework implemented in C.
Berislav Lopac Send private email
Sunday, May 07, 2006
 
 
In my company we have quite an experience working with different web languages as we develop Dreamweaver Extensions which should work the same on PHP, ASP Vb, ASP .NET and CF. Now, I may tell you that the first reason that you didn't see a comparing matrix between these languages is because everyone sucks from the point of view of speed on something.

Take the ASP and you'll have major speed problems when simply concat strings. Then if you take the ColdFusion you have a very good logic application but as language is slow and difficult to work with big applications. The PHP is very fast but full of bugs and the work arounds sometimes are slowing it down.

My personal opinion is that among all the languages here the PHP is the fastest except the native C-C++ cgi's. I think there is a second parameter that should be considered when talking about the speed: scalabillity. You may do a script run very fast but may take lots of mega of memory or lot of the processor. They will not be able to work on a live every day middle size server. I've seen old server machines (without keeping the database behind) that may handle 200-300 simultanous PHP requests with no problems and which crash on a 50 requests on ASP and they are dead if you simply install a CF on them.
Cristian MARIN Send private email
Sunday, May 07, 2006
 
 
good . seem php is fast than java .
Robin.Zhang Send private email
Monday, May 08, 2006
 
 
Robin, I think you may have slightly missed the point.

I think Java *the*language* is actually many many times faster than PHP. But Java *developers* tend to write code that overspends their windfall of extra CPU cycles.

So PHP applications often perform faster (and can handle more users, with less memory usage) than Java webapps.

But it's the developers fault, not the language or the runtime.
BenjiSmith Send private email
Monday, May 08, 2006
 
 
"I think Java *the*language* is actually many many times faster than PHP."

The question is does "language" speed really matter.  I remember when VB5 came out with native compilation; Unless you were doing a lot of tight calculation loops it had very little impact on performance over VB4.  Most of the time in VB you're calling out to some natively-written library functions that does most of the work. 

The same is true of Java and PHP.  Every library call in PHP is written in C and very few cycles are spent actually interpreting the PHP code itself.  While Java has the JIT for all it's code -- you've got significantly more layers of code to get through.  This is why Java is, in theory, faster but in practice seems to be much slower.
Almost H. Anonymous Send private email
Monday, May 08, 2006
 
 
A.H.A. is correct. As said above, PHP is a Web development framework written in C; on the other hand, Java Web frameworks are written in Java, which is a lot slower than (well-written) C.
Berislav Lopac Send private email
Monday, May 08, 2006
 
 
Well, if you want to get pedantic about it, the JVM is also written in C.

The Zend Engine 2 (which is the VM that compiles and executes PHP scripts) is a pretty sophisticated piece of software, with support for interfaces, classes, dynamic typing (and type hinting), reflection, exception handling, function overloading, serialization, dynamic code compilation and evaluation, and a reference-counting garbage collector.

Sorry, but PHP is not just a macro-language for a bunch of C libraries. That used to be true (back in PHP 3). But for the last five years or so, PHP has been a full-fledged VM-based programming language. Just like Java.

With significant development experience in both platforms, I'm sticking to my guns on this one: the reason PHP is often faster than Java is not because of the language or the libraries. It's because the most commonly used architectures in Java are far more (needlessly) complex that the architectures of most PHP applications.
BenjiSmith Send private email
Monday, May 08, 2006
 
 
It's tough to generalize a language's speed from the code architectures people write with it.

PHP has a bad reputation as a "toy" language because it's incredibly easy to pick up and use (especially if you're familiar with C-style syntax), and therefore it has been used a lot by amateurs to write very, very bad code.

It's possible to write code in Java that's just as bad, and I'm sure it happens at a normal rate.  But in Java, the awful code is always object-oriented. :)
Marco Arment Send private email
Tuesday, May 09, 2006
 
 
"But in Java, the awful code is always object-oriented. :)"

Well, I've seen more than one Java programs that have everything inside the main() method. I noticed the smiley, but "code being contained in a class" and "being OOP" are far from being necessarily the same.
Berislav Lopac Send private email
Tuesday, May 09, 2006
 
 
Another reason why the observed speed of PHP may beat Java, is because there is more stuff below the level of the VM in PHP.

For example, when you call some built-in function to do X, in PHP, that function is implemented in C and all the VM has to do is call the C (and therefore native code) that implements that function. But when you say do X in Java, lots of the X's seem to be implemnented in Java, or at least substantially in Java, before you get to the native code.
S. Tanna
Tuesday, May 09, 2006
 
 
I find it hard to believe that a comparable php application would be as fast as java.  Does Php have JIT compiling?

Also, From what I used to know of php, it was not a 'shared memory' system, meaning caching goes out the window even on a single machine.  If that is still true, right there I can tell you *Interpreted*  java would be orders of magnitude faster for a DB driven website.
Vince Send private email
Wednesday, May 10, 2006
 
 
"I find it hard to believe that a comparable php application would be as fast as java."

Why not?  Java might be JIT compiled but in this discussion we've already mostly ruled that out as a factor.

"it was not a 'shared memory' system, meaning caching goes out the window even on a single machine."

Yup.  On the otherhand, you don't have any memory locking issues either. 

"If that is still true, right there I can tell you *Interpreted*  java would be orders of magnitude faster for a DB driven website."

I don't think whether or not Java is interpreted or JIT'd has anything to do with it.  I think Java is just too fat -- too memory intensive and too many layers of software.  PHP is, by comparison, lean and mean.
Almost H. Anonymous Send private email
Wednesday, May 10, 2006
 
 
Vince, you have no idea what you're talking about.

1. Yes, PHP's code is compiled in a way, but this is not important, as 99% percent of any function you will call are already compiled in underlying framework. Of course. you could write everything from scratch, and that will be much slower than any Java app, but that would be utter nonsense -- PHP already offers quite a lot of basic Web functionality you need.

2. PHP does have a shared memory implemented as an extension, but it doesn't really need it. It closely follows the Web paradigm of asynchronous client/server requests, which makes it ideal for the Web. Due to this it's even a safer language for Web applications than Java, as this separation prevents a single page call to crash the whole application.

PHP is a Web framework; Java is a generic language. That makes it very different, and one needs to adjust to the technology used. You just can't write a PHP application the same way as you would a Java application, plain and simple. If you did, you'd get suboptimal results, for sure.
Berislav Lopac Send private email
Thursday, May 11, 2006
 
 
"
2. PHP does have a shared memory implemented as an extension, but it doesn't really need it. It closely follows the Web paradigm of asynchronous client/server requests, which makes it ideal for the Web. Due to this it's even a safer language for Web applications than Java, as this separation prevents a single page call to crash the whole application."

*I* don't know what I'm talking about?  What does "asynchronous client/server requests" have to do with shared memory?  The point is, in most web applications the bottleneck is not processing speed on the app server but going over the wire, hitting the db (which usually hits the disk).  SLOOOW. Am I missing something? Or do you want to explain to me how caching is negligable or useless?
Vince Send private email
Monday, May 15, 2006
 
 
Wow this topic is still going...

"What does "asynchronous client/server requests" have to do with shared memory?"

Each HTTP request is fully independent and each PHP request is fully independent.  If you want to scale you add more servers, that's it.

"Am I missing something? Or do you want to explain to me how caching is negligable or useless?"

Caching isn't useless but having a shared-memory application isn't caching.
Almost H. Anonymous Send private email
Monday, May 15, 2006
 
 
"Each HTTP request is fully independent and each PHP request is fully independent.  If you want to scale you add more servers, that's it."

Ok, I see what he was getting at, but thats just bad design.  You would most likely be scaling the least performance intensive part of the system. 

"Caching isn't useless but having a shared-memory application isn't caching.".

Ok, you got me on a technicality but I know your smart enough to know what i'm talking about. 

(I'll spell it out for the rest in one possible, really quick example).

public class ObjectFactory {
public static getObject( int id ) {}
}
Vince Send private email
Monday, May 15, 2006
 
 
Yeah, Vince, I know what you're talking about. I've always wondered why the PHP folks have never added an ApplicationScope or a (real) SessionScope to the PHP environment. Unfortunately, all of the variables created during the request are cleared when the page is served, and then the next client request has to reconstruct them all over again.
BenjiSmith Send private email
Tuesday, May 16, 2006
 
 
It turns out that I've actually done the PHP to C comparisons.  http://www.linuxjournal.com/article/6863

For lean and mean stuff, PHP is comparable to C in speed.  If you have more complex processing logic, C wins.  My testing was done with a MySQL backend on identical hardware.

I don't know where Java and Perl fall in this spectrum, and ASP and ASP.NET are complete unknowns.  What this article didn't show but I verified in my own testing is that C++ is consistently slightly faster than C, presumably because of very efficient code in the STL.

Your tradeoff comes in development time.  With a solid toolset you can develop with C very quickly.  I have that toolset (and contact me via email if you need it for yourself).  If you don't have that toolset then C is pretty slow for development compared to PHP, because you'll spend your time reinventing that wheel.
Clay Dowling Send private email
Tuesday, May 16, 2006
 
 
"I've always wondered why the PHP folks have never added an ApplicationScope or a (real) SessionScope to the PHP environment."

Locking.

ASP has Application scope and guess what happens...  you cannot put anything in it because every access is locked.  Instead of multitasking you have users going through the application scope in serial and performance tanks.

The "ObjectFactory" has the exact same issue.
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
The other nice thing about each request being independent is that you cannot crash the application.  You can crash a single request but that's it.  Your variables do not end up in some corrupt state because they are created a-new on each request.

This discussion is basically all about premature optimization..  is it really that much slower to recreate the environment on each request?  Is that really where a web-application bottleneck is?
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
"Locking."

Very good point. It's something I hadn't given much thought.

Of course, many PHP applications still need to maintain some notion of application state, but they just do so in the database. (Some of my projects have had a dedicated table in the db for keeping track of application-scoped state variables.) The same locking issues still apply, but the database is responsible for the locking.

There are many variables that change only infrequently (so they would be locked only very rarely), and it would be nice to have those variables persisted in application memory.
BenjiSmith Send private email
Tuesday, May 16, 2006
 
 
"Of course, many PHP applications still need to maintain some notion of application state, but they just do so in the database."

I've written 2 very large scale PHP applications (hundreds of classes, thousands of files) and I store no "application state".  I store data in the database but no differently than other application (even desktop) -- This is perminent storage of application entities only.

I have two other pieces of state: Page state, which is stored as a hidden field on the form and session state, which is held in files on the disk (and locked only when read/written to and unique for each user).

"Some of my projects have had a dedicated table in the db for keeping track of application-scoped state variables."

Ugly!

What sorts of data are you storing?
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
"ASP has Application scope and guess what happens...  you cannot put anything in it because every access is locked.  Instead of multitasking you have users going through the application scope in serial and performance tanks.

The "ObjectFactory" has the exact same issue."

What do you mean having a factory class would have the same 'locking' issue.  I guess I don't see what you mean...  Do you mean in php?
Vince Send private email
Tuesday, May 16, 2006
 
 
Well, I assume for your ObjectFactory to be of any use it's actually sharing the objects it returns.  If you don't have locking around shared objects, then you have chaos.
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
"Ugly!"

Yup.

Though it's not as bad as it sounds. I didn't use the database as a general-purpose variable persistance mechanism. It was just for a few specialized pieces of data.

I did it because the application needed to report the number of currently-logged-in users and the name of the most active user, and a bunch of other stats like that. I set up a cron job to run every minute, and it performed a few dozen queries to get all of those site statistics. Then it inserts the results into another table, and each page view queires that summary table when it renders the site statistics.

It may sound like premature optimization, but it wasn't. I already had the website up and running for a year or so at this point, and it had more than 300 active users (averaging around 30 page views per minute during peak times of day). Using one summary table for commonly used application-scope allowed me to eliminate an average of ten database queries per page view, and it significantly sped up the overall user experience. (I profiled the website before and after, and it made a big difference to generate stats during a batch process and then to retrieve those stats using just one query.)
BenjiSmith Send private email
Tuesday, May 16, 2006
 
 
"I did it because the application needed to report the number of currently-logged-in users and the name of the most active user, and a bunch of other stats like that."

Ah yes, I've had the same problem.  It's funny how we both came to different solutions to it.  I did the count of the number of currently-logged-in users as well as a bunch of other site statistics.

Rather than a cron-job, my site has a caching mechanism that can cache any sub-part of any page.  If the part is in the cache and it's not stale then the completed rendering is pulled from the cache.  If it is stale (or doesn't exist) that page-part is re-rendered and the appropriate queries are executed.  I use this for the stats information as well as about a thousand other things.

This way, I don't require any seperate processes or cron-jobs.  I also don't have any extra tables to deal with.  I have a 100% dynamic site (everything is under content management) but most of the time the HTML is rendered statically from the cache.

"It may sound like premature optimization, but it wasn't."

Not at all.  I have a pretty heavily trafficed site -- in January, our busiest month, we received 18,225,530 hits (on average 421 hits per minute) and the site was only on one single underpowered server.  It's now, thankfully, on two servers.

"Using one summary table for commonly used application-scope"

I don't consider that application scope..  summary tables is just regular 'ol de-normalization for performance.
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
The cron job was handy because it could do perform lots of periodic cleanup that was previously done by the actual page-generation scripts.

Deleting expired sessions, locking old threads, rebuilding db indices, finding (and deleting) bot posts/accounts. The cron job was something I needed anyhow, so it seemed like the natural place to regenrate the summary tables.

But I've taken the other route before, too, using the caching mechanism to preserve the HTML view of the statistical content. Both approaches work well.
BenjiSmith Send private email
Tuesday, May 16, 2006
 
 
I have a nightly cron job for various maintaince tasks (sending out emails, etc).

I agree, both techniques have merit!  I wonder what the Java proponents will say about all this...
Almost H. Anonymous Send private email
Tuesday, May 16, 2006
 
 
Both seem like good designs to me.   

For global object caches,  its really not as much of a problem as it seems...  Its really treated just like a database.  You don't need to lock for reads (most of the time), and when you need transactional integrity, you lock on the object in the areas that need that functionality. 

Funny that you mentioned front-end page caching.  I'd venture to say that ANY web app that implements well done page caching would be much faster then one who doesn't, regardless of language.  That completely negates both database processing time AND application server processing time (aside from fetching the page). 

The only reason I can think of that it wouldn't work well would be if there were about as many 'writes' as reads, but I think thats rare in a web type application.
Vince Send private email
Tuesday, May 16, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz