 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007PHP compared to Java/J2EE
Hi, I'm wondering if I can get a reasonably civil (without starting any huge wars) opinion on how server-side PHP compares to server-side Java. I've been strictly a Java developer for almost 10 years now, and I'm pretty happy with it. However, I can't help but notice that there are a significant amount of PHP-based development projects where I live, and I've also noticed when searching around the internet for ready- made web applications that a lot of them are in PHP. As an object-oriented programmer I've always assumed PHP was more of a scripting language for doing things on individual web pages or writing small applications and that Java/J2EE was better positioned for writing large applications, but maybe that's no longer true. Let me know what you think. Thanks. Frank > Hi, > [quoted text clipped - 16 lines] > > Frank Frank, I asked myself the same question some time ago. most of the answer i found it at: http://www.tbray.org/ongoing/When/200x/2006/11/10/Comparing-Frameworks hope it helps flarosa wrote : > Hi, > [quoted text clipped - 12 lines] > small applications and that Java/J2EE was better positioned for > writing large applications, but maybe that's no longer true. I have done work in both PHP - scripting language. The source code gets read and interpreted every time a page hit occurs, unless you are using a precompiler, but then the host server must have a special Apache extension to run it. - becuase of the above it is expensive to use a lot of constants, so you end up with a lot of magic numbers - sort of OO. It has classes, but the implementation is not complete. It was bolted on after the fact, so you can mix OO with procedural. - one of the big features is the ability to "include" (or "requires") a file. That way you build up a web page from many smaller files. However, any variable which an included file might use from the parent file, must be created by the parent file. So you may include a file which requires a variable, only to have it crash becasue that variable is not present. Makes debugging difficult. - by design, presentation code is mixed with business logic - great for small projects Java - compiled language. The compiler produces byte-code. The server reads the byte code and uses the Java Runtime Environment (JRE) to run it. - All constants are resolved by the compiler, so using many constants makes the code more readable. - The JRE will inspect the code execution path and will optimize it on the fly. So the longer your code runs, the faster it runs. - Is OO by design - great for large projects. So for small simple projects I use PHP. For anything serious I use Java. $0.02  SignatureWojtek :-) .oO(Wojtek) >PHP >- scripting language. The source code gets read and interpreted every >time a page hit occurs, unless you are using a precompiler, but then >the host server must have a special Apache extension to run it. There are also several PECL extension for PHP to cache the compiled bytecode (PHP code is compiled first and then interpreted by the ZE). One of these caches (APC) will most likely be part of PHP 6. >- becuase of the above it is expensive to use a lot of constants, so >you end up with a lot of magic numbers Huh? I use hundreds of global and class constants. This is definitely not a performance hit, there are "better" ways to waste CPU time. >- by design, presentation code is mixed with business logic Such mixing is possible in other languages as well. And it's always the developer who decides if he wants to make use of it or not. Of course you can also properly separate business from presentation logic. >- great for small projects Also great for bigger projects. Of course like in all languages you have to know what you're doing and know the tools you're using. Micha Michael Fesser wrote : > I use hundreds of global and class constants. Hundreds is not a lot. SignatureWojtek :-) .oO(Wojtek) >Michael Fesser wrote : > >> I use hundreds of global and class constants. > >Hundreds is not a lot. Doesn't matter. They're resolved by the compiler like all other symbols. If you run into performance issues the first thing to do is to profile your code to see where the real bottlenecks are. In most cases it's the algorithm, not the language. Micha > flarosa wrote : >> Hi, [quoted text clipped - 20 lines] > a page hit occurs, unless you are using a precompiler, but then the host > server must have a special Apache extension to run it. not true at all! php can run all by itself or as a module to most *any* web server (if that is how you intend it to be executed). > - becuase of the above it is expensive to use a lot of constants, so you > end up with a lot of magic numbers 'because of the above' being FALSE, your point of expense is moot. not to mention silly, even if what you'd claimed were true. last time i checked, apache was still free. as for 'magic numbers'? well hell, that's completely unrelated to the point you were trying to make. second, *people* create magic numbers...not programming languages. you may need to explain yourself a bit more here. > - sort of OO. It has classes, but the implementation is not complete. in what way? > It was bolted on after the fact, so you can mix OO with procedural. in *ANY* language, you can mix OO and proc code. as for being bolted on after the fact, again that's a completely FALSE statement. aspects of OO have been in php since at least php 3.0 and remained largely unchanged until php 5. the major provisions of what is prized about OO were *all* there at that time...that was back in early 1998 fwir! > - one of the big features is the ability to "include" (or "requires") a > file. That way you build up a web page from many smaller files. ok...but again you assume php just does web pages. you do that with perl too? or ruby? or java? > However, any variable which an included file might use from the parent > file, must be created by the parent file. So you may include a file which > requires a variable, only to have it crash becasue that variable is not > present. Makes debugging difficult. well, that's a stupid argument. that goes to developer architecture, implementation, and lack of error checking to prevent 'crashing'. it has little to do with being a php weakness. > - by design, presentation code is mixed with business logic ONLY BY THE DESIGNER !!! > - great for small projects AND FOR THE MULTI-BILLION DOLLAR projects for the fortune 100 companies for whom i've developed php applications. lots of data, lots of users, lots of hits, lots of bad consequences if php (or my implementation of it) fails. > Java > - compiled language. The compiler produces byte-code. not a fully compiled language. just like msil that is executed by the .net framework, java need jre. not much of a greater advantage there. > The server reads the byte code and uses the Java Runtime Environment (JRE) > to run it. see above. > - All constants are resolved by the compiler, so using many constants > makes the code more readable. NO DIFFERENT THAN PHP. > - The JRE will inspect the code execution path and will optimize it on the > fly. NO DIFFERENT THAN PHP. you need to quantify and qualify 'optimize'. > So the longer your code runs, the faster it runs. that is UTTERLY FALSE! there is a thing called an optimal limit. java will hit a primary, ultimate, optimzed execution plan at some point. however, it evaluates what 'optimal' is EVERY SINGLE TIME that code portion is going to be executed. as far as web development goes, php and java only get ONE pass at doing an optimization. i think your point here is coming up a little short. > - Is OO by design nothing *IS OO*...java was written with OO support in mind from its onset. though php put it in its tertiary release, it was done in short order. the only argument to be made here is what of OO is supported by either AND of the things NOT supported YET by php, which are NEEDED to get the job done. > - great for large projects. just like php. moot point. > So for small simple projects I use PHP. For anything serious I use Java. > > $0.02 yeah, i think you're charging to much. i'd rate your overview about...one peso, if that. Steve wrote : > your point of expense is moot. not to mention silly, even if what you'd > claimed were true. last time i checked, apache was still free. Expensive in terms of processor time, not currency. SignatureWojtek :-) > Steve wrote : >> your point of expense is moot. not to mention silly, even if what you'd >> claimed were true. last time i checked, apache was still free. > > Expensive in terms of processor time, not currency. yeah, i got that after i reviewed the post. :) even still, when talking web dev, php has a supremely smaller footprint than java coule ever hope to attain. what php does provide, it makes sure it doesn't sacrifice speed. and, as i think i saw someone else post, you can get php to a semi-compiled state just as java does. > Steve wrote : >> your point of expense is moot. not to mention silly, even if what >> you'd claimed were true. last time i checked, apache was still free. > > Expensive in terms of processor time, not currency. No more so than Java, and in many cases, less. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > not a fully compiled language. just like msil that is executed by the .net > framework, java [sic] need jre [sic]. not much of a greater advantage there. Actually, Java JVMs are quite effective at runtime code optimizations. "Wojtek" <nowhere@a.com> wrote in message >> The server reads the byte code and uses the Java Runtime Environment (JRE) >> to run it. > ... >> - The JRE will inspect the code execution path and will optimize it on the >> fly. > NO DIFFERENT THAN [sic] PHP. you need to quantify and qualify 'optimize'. Actually, it's quite different, for most JVMs. JVMs perform inlining, loop unrolling, enregistering, escape analysis, common-code refactoring, just-in-time adaptive compilation and various forms of run-time analysis that static-compilation tools are hard-pressed to achieve. While it's certainly possible to do these things with PHP, most interpreters don't. The various optimizations in the JVM achieve at least a ten-fold increase over strictly interpreted bytecode, according to articles I've read. I saw that simply switching a major enterprise server at a job site from "-client" to "-server" doubled its throughput. If I may be so bold, resorting to /ad hominem/ remarks in your exposition redounded to its detriment. SignatureLew Steve wrote : > php and java only get ONE pass at doing an optimization. Nope. Modern Java implementations use adaptive optimization during runtime. With traditional compiled languages, the compiler does it once. http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization SignatureWojtek :-) > Steve wrote : >> php and java only get ONE pass at doing an optimization. [quoted text clipped - 3 lines] > > http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization what i'm saying is that this is not a continual process, like a gui, or running process on a system. in the context of the web, java doesn't get to capitalize on more than a few adaptations given the run-produce-output-and-done nature of a web hit. make sense? Steve wrote : > what i'm saying is that this is not a continual process Yes it is. SignatureWojtek :-) >> Steve wrote : >>> php and java only get ONE pass at doing an optimization. [quoted text clipped - 9 lines] > capitalize on more than a few adaptations given the > run-produce-output-and-done nature of a web hit. make sense? No, because the JVM's optimisation is over the lifetime of the JVM not the liftime of a single request. A request just invokes a method in a pre-existing Java application. That single, long-running Java application is the servlet container (something like Tomcat or Jetty). The container can either run standalone and serve-up everything (including HTML and static resources) or, more common in large systems, it can sit behind Apache, which will serve the static content and defer to the servlet container for dynamic content. So the JIT compiler can (and does) use information it has gathered from hundreds or thousands of hits over hours or days in order to optimise the code. Dan. SignatureDaniel Dyer https://watchmaker.dev.java.net - Evolutionary Computation for Java >>> Steve wrote : >>>> php and java only get ONE pass at doing an optimization. [quoted text clipped - 22 lines] > hundreds or thousands of hits over hours or days in order to optimise > the code. Steve, Check out the white papers and articles on JVMs and how they optimize code. SignatureLew "Wojtek" <nowhere@a.com> wrote in message >> So the longer your code runs, the faster it runs. > that is UTTERLY FALSE! there is a thing called an optimal limit. java will > hit a primary, ultimate, optimzed execution plan at some point. however, it > evaluates what 'optimal' is EVERY SINGLE TIME that code portion is going to > be executed. You are mistaken. JVMs do not use a static optimization plan. It changes how it runs different code paths depending on the runtime profile. It will decompile code back to bytecode, for example, if it falls into relative disuse, and JIT another part that is currently undergoing heavy use. It can also dynamically examine things like method arguments to determine if it's safe to lift instance variables into registers or not. Go back and review how JVMs actually work. Sun has a number of white papers on java.sun.com that explain the sorts of things they can do. IBM DeveloperWorks has a series of articles by Brian Goetz that explained these matters back in about 2003 / 2004. SignatureLew > Hi, > [quoted text clipped - 16 lines] > > Frank Frank, PHP is more popular because it's supported by all the web servers. When PHP first came out, for instance, Apache and IIS didn't support Java well on the server side (don't know what it's like now). Plus is is fast and has a smaller memory footprint than Java, which made it better for shared hosting companies. The result is that a lot of hosting companies offered PHP really cheap - but Java support was comparatively lacking and more expensive. PHP is getting more object oriented. It still has a ways to go - Java is much better in that respect. But PHP is getting there, a little at a time. Now when you're talking larger applications, I agree Java is a better language, especially when you're talking GUIs. There is a GUI available for PHP, but it is sadly lacking in functionality compared to Java. And Java's event model makes some things much easier than in PHP (which doesn't have an equivalent). Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > > Hi, > [quoted text clipped - 44 lines] > jstuck...@attglobal.net > ================== This is an interesting discussion. I have used Java but never used it for a web application. Can anyone point me to a good place to learn how to use this? Is this using JSP and servlets or is this something else? I am starting work on a project and I was going to do it with PHP, MySQL, and some AJAX stuff. I considered doing it in Java but my timetable is pretty short and front end GUI stuff in Java is a nightmare to me (not good at it, not bashing Java). So with my short time frame, I figured that a web based application would be the best way where I can quickly build the interface. My application is not huge, probably 50-75 hours for me to do. THanks. > This is an interesting discussion. I have used Java but never used it > for a web application. Can anyone point me to a good place to learn > how to use this? Is this using JSP and servlets or is this something > else? Yes, JSPs and servlets. java.sun.com has tutorials on the topic, and you should search their site for information on "Model 2" architecture, a Model-View-Controller pattern for web apps. > I am starting work on a project and I was going to do it with PHP, > MySQL, and some AJAX stuff. I considered doing it in Java but my [quoted text clipped - 3 lines] > way where I can quickly build the interface. My application is not > huge, probably 50-75 hours for me to do. GUI in JSP is just GUI in HTML. If you can make PHP, you can make JSP. If you use Java Server Faces (JSF), things get more sophisticated, but the approach is still markup oriented. SignatureLew > This is an interesting discussion. I have used Java but never used it > for a web application. Can anyone point me to a good place to learn > how to use this? Is this using JSP and servlets or is this something > else? Yes, web apps for Java mean JSP and servlets, plus some other stuff. You could do it with just sockets, but your brain would probably explode. Sang Shin is a technology evangelist who works for Sun, and teaches free online classes on Java and J2EE. (J2EE = JSPs and the webby bits.) His J2EE class starts in about a week. You should check it out. http://www.javapassion.com/j2ee/ > I'm wondering if I can get a reasonably civil (without starting any > huge wars) opinion on how server-side PHP compares to server-side > Java. I've yet to see a cross-posted language comparison that remained civil. This may be the exception, but I doubt it will be. > I've been strictly a Java developer for almost 10 years now, and I'm > pretty happy with it. However, I can't help but notice that there are [quoted text clipped - 8 lines] > > Let me know what you think. Thanks. Learn both - and Ruby, Perl, Python, C, C++, C#, etc. The more tools you have in your toolbox, the better-equipped you'll be to apply the most appropriate one for the task at hand. The phrase "object-oriented programmer" makes about as much sense to me as "brush painter" or "saw carpenter." I can't see the point in limiting one's options so narrowly. sherm-- SignatureWV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net .oO(Sherman Pendley) >> I'm wondering if I can get a reasonably civil (without starting any >> huge wars) opinion on how server-side PHP compares to server-side >> Java. > >I've yet to see a cross-posted language comparison that remained civil. >This may be the exception, but I doubt it will be. It's just a question of when to leave the thread. ;) Micha >> I'm wondering if I can get a reasonably civil (without starting any >> huge wars) opinion on how server-side PHP compares to server-side [quoted text clipped - 25 lines] > > sherm-- Sherm, Obviously you didn't grow up (programming, that is) in the age before OO. Back in the 60's and early 70's, structured programming was a novelty! :-) Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > Back in the 60's and early 70's, structured programming was a novelty! :-) It still is. SignatureLew >> Back in the 60's and early 70's, structured programming was a novelty! >> :-) > > It still is. Naw, in the late 70's and early 80's it became more mainstream. It still is in a lot of circles. What I'm talking about it the age of GOTO's, etc. COBOL, FORTRAN, etc. Much different than what we have available in a lot of languages today. Even COBOL has an OO version now... Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >>> Back in the 60's and early 70's, structured programming was a novelty! >>> :-) [quoted text clipped - 3 lines] > Naw, in the late 70's and early 80's it became more mainstream. It still > is in a lot of circles. i think lew was making a joke there. >>>> Back in the 60's and early 70's, structured programming was a novelty! >>>> :-) [quoted text clipped - 4 lines] > > i think lew was making a joke there. I think you're right, Steve. But at midnight after a night out with the guys, I'm not always in the right frame of mind to get the subtleties :-). Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >>>>> Back in the 60's and early 70's, structured programming was a novelty! >>>>> :-) [quoted text clipped - 7 lines] > I think you're right, Steve. But at midnight after a night out with the > guys, I'm not always in the right frame of mind to get the subtleties :-). s'all good, momma. hope you had a good time. it's good to get away from the screen now and again, eh. cheers >>>>>> Back in the 60's and early 70's, structured programming was a novelty! >>>>>> :-) [quoted text clipped - 8 lines] > s'all good, momma. hope you had a good time. it's good to get away from the > screen now and again, eh. It was more of a wry commentary than a joke. SignatureLew > Hi, > > I'm wondering if I can get a reasonably civil (without starting any > huge wars) opinion on how server-side PHP compares to server-side > Java. I'd like to suggest a protocol for maintaining civility in this type of conversation. *Only make definitive statements about a language if you are an expert in that language.* If you are a Java expert who sometimes uses PHP, say things you know about Java, but ask "How would that situation be handled in PHP?". Other way round for PHP experts who sometimes use Java. Patricia > Hi, > > I'm wondering if I can get a reasonably civil (without starting any > huge wars) opinion on how server-side PHP compares to server-side > Java. Civility in language comparison can be asking a lot sometimes. I am going to start by saying that I have very limited experience in this question: I've worked a total of 1 PHP projects and 0 Java EE projects. > I've been strictly a Java developer for almost 10 years now, and I'm > pretty happy with it. However, I can't help but notice that there are > a significant amount of PHP-based development projects where I live, > and I've also noticed when searching around the internet for ready- > made web applications that a lot of them are in PHP. My general impression is "stay with what you are comfortable with if feasible." > As an object-oriented programmer I've always assumed PHP was more of a > scripting language for doing things on individual web pages or writing > small applications and that Java/J2EE was better positioned for > writing large applications, but maybe that's no longer true. PHP's largest use case may well be scripts or simple applications, but that by no means indicates that it has to be used as such. At times, it seems to me that PHP is torn between catering to scripts or catering to large applications. Above all, my biggest problem with PHP is how it appears to interact with OOP. To me--this may and probably does vary between people--PHP has a weary relationship: it wants to use it but doesn't quite want to go that extra step. Since I came on to my only PHP project after the brunt of it had been developed, this may simply be a manifestation of the other developers. My $0.02... not that it's worth much these days... SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > Above all, my biggest problem with PHP is how it appears to interact > with OOP. To me--this may and probably does vary between people--PHP has > a weary relationship: it wants to use it but doesn't quite want to go > that extra step. Since I came on to my only PHP project after the brunt > of it had been developed, this may simply be a manifestation of the > other developers. If we think of programming as flying, then we can think of PHP as a hang glider and Java EE as a commercial jet airliner. I wouldn't want to leap off a cliff hanging on to the landing gear of a Boeing 747. Nor would I want to fly a couple of hundred people across an ocean in a hang glider. The languages have fundamentally different philosophies and programming models. It's like comparing Apples and PCs. SignatureLew > If we think of programming as flying, then we can think of PHP as a hang > glider and Java EE as a commercial jet airliner. Of course - if you think of programming as programming, then there's almost NO difference. It's like asking - which is *better* - Enlish or Spanish? It all depends on with whom you're trying to communicate. Sure - there's some folks who will write mainfestos in preference of one or the other, but their advocacy won't help you get the job done. > I'm wondering if I can get a reasonably civil (without > starting any huge wars) opinion on how server-side PHP > compares to server-side Java. The biggest difference is architecture. PHP does not have an application server in the Java meaning of the term; the PHP interpreter is either loaded into the HTTP server as a module at the startup or runs as a CGI/FastCGI executable. Both PHP and Java work well with Oracle; when it comes to MySQL, however, Java (at least in its Tomcat implementation) tends to have performance issues. One widely publicized example is Friendster; the performance problems in its Linux/Tomcat/MySQL stack were so pervasive that the whole application had to be rewritten in PHP. So for applications where license costs are a factor (or, to put it another way, for situations when you can't afford Oracle and a commercial application server), PHP (or Python) is usually preferable. > I've been strictly a Java developer for almost 10 years > now, and I'm pretty happy with it. However, I can't help > but notice that there are a significant amount of PHP-based > development projects where I live Maybe, but have you looked into going pay rates for those projects? > and I've also noticed when searching around the internet for > ready-made web applications that a lot of them are in PHP. Well, PHP hosting is by far the easiest to come by... > As an object-oriented programmer I've always assumed PHP was > more of a scripting language for doing things on individual > web pages or writing small applications and that Java/J2EE > was better positioned for writing large applications, but maybe > that's no longer true. It's never been true in the first place. PHP is easier to learn than most alternatives, so there are a lot of inexperienced, yet eager, PHP developers out there, who keep cranking out operational, but poorly structured, code. It does not mean, however, that it is impossible to produce a well-designed application in PHP... Cheers, NC > Both PHP and Java work well with Oracle; when it comes to MySQL, > however, Java (at least in its Tomcat implementation) tends to have > performance issues. One widely publicized example is Friendster; the > performance problems in its Linux/Tomcat/MySQL stack were so pervasive > that the whole application had to be rewritten in PHP. Could you give some specific citations how Java has "performance issues" with MySQL, and why it would differ from Java's performance with Postgres or Oracle? The only thing that could affect performance between Java and a database would be the JDBC driver. (Application code issues we will take as equivalently dangerous be it Java or PHP.) MySQL provides their own JDBC driver. SignatureLew >> Both PHP and Java work well with Oracle; when it comes to MySQL, >> however, Java (at least in its Tomcat implementation) tends to have [quoted text clipped - 10 lines] > equivalently dangerous be it Java or PHP.) MySQL provides their own > JDBC driver. Yes, but MySQL (and many other databases) access through the jdbc drivers is much slower than in PHP. The JDBC driver is often byte code and needs to be interpreted. OTOH, the PHP driver is compiled C, and uses the C calls to the database, which are generally faster. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > Yes, but MySQL (and many other databases) access through the jdbc > drivers is much slower than in PHP. The JDBC driver is often byte code > and needs to be interpreted. OTOH, the PHP driver is compiled C, and > uses the C calls to the database, which are generally faster. First of all, bytecode interpretation is a fraction of the overhead of talking to a database. Secondly, all production-grade JVMs optimize the heck out of bytecode to a degree at least comparable to C code. Do you have citations for the differences in Java MySQL speed and PHP MySQL speed? Do you have citations for the reasons for any differences? I am still interested - do you have citations for performance differences between the Java / MySQL combination and other Java / RDBMS combinations like Postgres or Oracle? I hear the conclusions that have been stated: - Java / Tomcat to MySQL is slower than other Java / RDBMS combinations. - Java / Oracle works better than Java / Tomcat / MySQL. - There were severe performance problems (unspecified) with Linux / Tomcat / MySQL. - These problems necessitated a switch to PHP (implying no other solution would have worked?). - Java / Tomcat to MySQL is slower than PHP / Apache / MySQL. - This latter is due to bytecode interpretation being slower than C binary execution. - C calls to MySQL are generally faster than JDBC calls to MySQL. One at least is incorrect. I am interested in the evidence for the others. SignatureLew >> Yes, but MySQL (and many other databases) access through the jdbc >> drivers is much slower than in PHP. The JDBC driver is often byte [quoted text clipped - 6 lines] > Secondly, all production-grade JVMs optimize the heck out of bytecode to > a degree at least comparable to C code. And it still isn't nearly as fast as compiled code. > Do you have citations for the differences in Java MySQL speed and PHP > MySQL speed? Just experience. No hard facts. > Do you have citations for the reasons for any differences? Knowledge of drivers and 40 years programming experience, including around 10 years in Java. > I am still interested - do you have citations for performance > differences between the Java / MySQL combination and other Java / RDBMS > combinations like Postgres or Oracle? DB2 access is also slower, but those are the only two I use regularly. > I hear the conclusions that have been stated: > [quoted text clipped - 10 lines] > > One at least is incorrect. I am interested in the evidence for the others. And which one is incorrect? Have you actually compared them? Note that I am NOT bashing Java. I love the language. I am stating what I have found. Java is a good language. But it is not the last word in languages that some people make it out to be. And it is not the fastest or best in every circumstance. But then neither is PHP or any other language. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > Just experience. No hard facts. No facts at all with all that experience? I'm a little doubtful, to tell the truth. How many systems/server? How were they configured? All did the web server and db run on the same system? If not what type of channel did they communicate over? Other systems involved? How many queries, how big were the tables, how many rows were returned? How many joins were involved? An experienced engineer should be able to list some facts.... >> Just experience. No hard facts. > > No facts at all with all that experience? I'm a little doubtful, to > tell the truth. No hard measurements I can lay my hands on. But about 18 years of C++ experience and 10 years Java. > How many systems/server? How were they configured? All did the web > server and db run on the same system? If not what type of channel did > they communicate over? Other systems involved? Typically all on one system, although some were on remote systems. Comm links were the same in both cases, so that's immaterial. > How many queries, how big were the tables, how many rows were returned? > How many joins were involved? Biggest would have been around 200 tables, regularly joining around 15-20 tables. A hundreds of gigabytes of data. Largest table probably had 10M rows. But again, not germane to the conversation because the database and request were identical in both cases. This was using DB2. > An experienced engineer should be able to list some facts.... Sure, if I went back through stuff. But I've been a consultant for 17 years now. I've worked on numerous projects during that time. And I don't keep detailed notes when I'm done with a project. Those go to the customer. But I do remember one project where some big manager said it had to be Java. They spent about a year on the project - around 25 programmers in all. The resulting applications were so slow as to be basically unusable. Users complained from day 1. Nothing the did could get acceptable performance. They ended up rewriting it in Visual C++. Now I am not a fan of MFC, but the result was a significant decrease in response time for the user. Enough that it was now acceptable. Note that nothing else changed - databases, etc. were still the same. The manager didn't actually get fired, I don't think but he wasn't with the company for much longer. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > database and request were identical in both cases. This was using DB2. And yet, I was asking about your problems with JDBC with Linux and MySQL...... >> database and request were identical in both cases. This was using DB2. > > And yet, I was asking about your problems with JDBC with Linux and > MySQL...... I didn't specify Linux and MySQL. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >>> database and request were identical in both cases. This was using DB2. >> >> And yet, I was asking about your problems with JDBC with Linux and >> MySQL...... > > I didn't specify Linux and MySQL. OK, NC did. You just specified JDBC, which is assumed to be written largely in bytecodes. Should I be able to reproduce this on smaller tables? Say, less than 1 million rows and less than 5 joins? Or does the problem only happen with larger DBs? >>>> database and request were identical in both cases. This was using DB2. >>> [quoted text clipped - 9 lines] > million rows and less than 5 joins? Or does the problem only happen > with larger DBs? Makes no difference the number tables, size, etc. Once it gets to the database (where all that work is done), the language is immaterial. It does, however, depend on the number of rows actually retrived. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > Makes no difference the number tables, size, etc. Once it gets to the > database (where all that work is done), the language is immaterial. > > It does, however, depend on the number of rows actually retrived. Thanks. I'm going to be at a point in a couple of months to do some performance testing, and I had already decided to check out both PHP and J2EE. This will help me focus the tests a little more. >> Makes no difference the number tables, size, etc. Once it gets to the >> database (where all that work is done), the language is immaterial. [quoted text clipped - 4 lines] > performance testing, and I had already decided to check out both PHP and > J2EE. This will help me focus the tests a little more. That's always the best. Different circumstances can provide significantly different results. Which is why I didn't like any of the reports referred to here. None of them provide enough information to replicate the results - an important validation point. Both languages are good. And unless I expect problems for one reason or another, performance is not a criteria I generally rate very high in determining what language to use. It's seldom a problem in either language, and if is going to be a problem, it probably will in both. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > I hear the conclusions that have been stated: > [quoted text clipped - 5 lines] > - These problems necessitated a switch to PHP (implying no other > solution would have worked?). Performance problems with Linux / Tomcat / MySQL are very specific; whatever the reasons, the response time of a Tomcat / MySQL setup increases with the number of simultaneous connections much faster than that of a PHP / MySQL setup. Could there be solutions other than switching to PHP? Of course! Here are a few possibilities: 1. Switching from JSP to Python. 2. Switching from MySQL to Oracle. 3. Switching from Tomcat to a commercial application server. 4. Switching from Tomcat to JBOSS. 5. Investigating the root cause of the problem and fixing it (which could possibly mean developing a new JDBC driver for MySQL). Options 2 and 3 entail significant license costs. Options 3 and 4 may not solve the problem (if the problem is indeed in the JDBC driver, changing the application server may not help). Option 5 has an indefinite timeframe and highly uncertain cost, plus it requires technical knowledge that the organization experiencing the problem may not possess. What's left? Abandoning JSP altogether for something that is known to work better with your chosen OS and DBMS... Cheers, NC >> Both PHP and Java work well with Oracle; when it comes to MySQL, >> however, Java (at least in its Tomcat implementation) tends to have [quoted text clipped - 5 lines] > with MySQL, and why it would differ from Java's performance with Postgres > or Oracle? I had an issue with the load-time for the java runtime. I did a site that only got a few hits per month, but on ONE day, it would get like a thousand. When people weren't hitting it all the time, they'd experience as much as 30 seconds delay while the runtime (or whatever) booted up (or whatever). It was a teeny, tiny, simple servlet - like 10 lines of code. But if nobody hit it in a while, the first hit would be slllloooowwww. > The only thing that could affect performance between Java and a database > would be the JDBC driver. (Application code issues we will take as > equivalently dangerous be it Java or PHP.) MySQL provides their own JDBC > driver. > > Both PHP and Java work well with Oracle; when it comes > > to MySQL, however, Java (at least in its Tomcat [quoted text clipped - 5 lines] > Could you give some specific citations how Java has > "performance issues" with MySQL, Not exactly a very technical explanation, but here's an insider's take: ...on Friday we launched a platform rearchitecture based on loose-coupling, web standards, and a move from JSP (via Tomcat) to PHP. The website doesn't look much different, but hopefully we can now stop being a byword for unacceptably poky site performance. http://troutgirl.wordpress.com/2004/06/29/friendster-goes-php/ who, by the way, was fired for writing it: http://www.news.com/Friendster-fires-developer-for-blog/2100-1038_3-5331835.html > and why it would differ from Java's performance with > Postgres or Oracle? I would make the same guess you did: there's something wrong with MySQL JDBC driver... Cheers, NC > ...on Friday we launched a platform rearchitecture based on > loose-coupling, web standards, and a move from JSP (via [quoted text clipped - 3 lines] > > http://troutgirl.wordpress.com/2004/06/29/friendster-goes-php/ " This is a funny result. I am my self a PHP enthusiast, but in the journal “ACM SIGMETRICS Performance Evaluation Review, Volume 31 Issue 3″ there was an article called “A performance comparison of dynamic Web technologies” where Perl, Java server technolgy (also tomcat) and Perl was benchmarked in a labratory environment. It was concluded that Serverside Java outpreformed PHP and Perl by a factor 8. " > > ...on Friday we launched a platform rearchitecture based on > > loose-coupling, web standards, and a move from JSP (via [quoted text clipped - 10 lines] > was benchmarked in a labratory environment. It was concluded that > Serverside Java outpreformed PHP and Perl by a factor 8. " Wow... Or is it supposed to be "Huh"? :) Here's the actual abstract of that article: Today, many Web sites dynamically generate responses "on the fly" when user requests are received. In this paper, we experimentally evaluate the impact of three different dynamic content technologies (Perl, PHP, and Java) on Web server performance. We quantify achievable performance first for static content serving, and then for dynamic content generation, considering cases both with and without database access. The results show that the overheads of dynamic content generation reduce the peak request rate supported by a Web server up to a factor of 8, depending on the workload characteristics and the technologies used. In general, our results show that Java server technologies typically outperform both Perl and PHP for dynamic content generation, though performance under overload conditions can be erratic for some implementations. http://portal.acm.org/citation.cfm?id=974036.974037 &coll=ACM&dl=ACM&idx=J618&part=newsletter&WantType=Newsletters &title=ACM%20SIGMETRICS%20Performance%20Evaluation%20Review &CFID=6782527&CFTOKEN=17180559 As you can see, "the factor of 8" refers to serving static content outperforming dynamic content generation, not to Java outperforming PHP and Perl... Note also that the article mentions Java's erratic performance under overload conditions for some implementations... Cheers, NC >I'm wondering if I can get a reasonably civil (without starting any >huge wars) opinion on how server-side PHP compares to server-side >Java. PHP is for small projects, maybe at most a forum.. J2EE is for giant ones. You need to know a lot less to get your first PHP database project working. It is better, which is better a water ski boat or an oil tanker. It depends what you want to do. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > PHP is for small projects, maybe at most a forum.. J2EE is for giant > ones. And yet - PHP is *constantly* used for large, successful projects - while Java sites are pretty much limited to pretty pinball games and such. >> PHP is for small projects, maybe at most a forum.. J2EE is for giant >> ones. > > And yet - PHP is *constantly* used for large, successful projects - while > Java sites are pretty much limited to pretty pinball games and such. How about Ebay? I think that qualifies as a large, successful project: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf Also, parts of Amazon's platform are Java too (along with C++ and Perl). Your pinball game is surely a client-side application, is it not? Applets may be one or the more visible aspects of Java but they are largely irrelevant. The vast majority of commercial Java development is server-side (i.e. web applications). Dan. SignatureDaniel Dyer http://www.uncommons.org Sanders Kaufman wrote: >> And yet - PHP is *constantly* used for large, successful projects - while >> Java sites are pretty much limited to pretty pinball games and such. Nearly every agency in the U.S. Federal government uses Java for their enterprise servers. A host of major health-care firms do likewise. IBM makes a fortune with WebSphere. BEA remains in business despite having been founded before the 2001 dot-bomb. How's Oracle doing lately? Sun's change of stock ticker symbol to "JAVA" was immediately followed by a bump in their stock prioe. Java remains by recent surveys the most "popular" language in professional use, slightly up from last year. This is not necessarily evidence of Java's suitability, let alone superiority, only that it's widely used, and in quite serious projects that do not involve "pinball games and such", let alone pretty ones. Or was that comment simply BS thrown out to inflame? In fact, Java has many features that make it suitable for enterprise systems. Being a strongly-typed, compiled language with runtime performance that equals or exceeds native-code statically compiled systems (C, C++), the extremely strong tools support with a broad base of well-funded suppliers proffering a healthy smorgasbord of choices, a large labor supply of trained practitioners and inherent support for distributed, heterogeneous programming make it a match for the kind of complex edifices needed in that market. SignatureLew > Sanders Kaufman wrote: >>> And yet - PHP is *constantly* used for large, successful projects - [quoted text clipped - 3 lines] > Nearly every agency in the U.S. Federal government uses Java for their > enterprise servers. A large number also use PHP. Java isn't the only language used. > A host of major health-care firms do likewise. Ditto. > IBM makes a fortune with WebSphere. BEA remains in business despite > having been founded before the 2001 dot-bomb. How's Oracle doing lately? It's a lot to you and me, but a drop in the bucket to IBM. And Zend Studios doesn't try to make a fortune with PHP - rather, they give it away - even the source. And IBM makes a lot more money off of CICS than it does WebSphere. > Sun's change of stock ticker symbol to "JAVA" was immediately followed > by a bump in their stock prioe. So? What does it prove? A change in a stock symbol often causes a change in the stock price. > Java remains by recent surveys the most "popular" language in > professional use, slightly up from last year. Who's survey? And define "professional use". > This is not necessarily evidence of Java's suitability, let alone > superiority, only that it's widely used, and in quite serious projects > that do not involve "pinball games and such", let alone pretty ones. I don't think anyone ever argued that Java isn't widely used. But so is PHP, C, C++, COBOL... > Or was that comment simply BS thrown out to inflame? > [quoted text clipped - 6 lines] > distributed, heterogeneous programming make it a match for the kind of > complex edifices needed in that market. I have yet to see Java equal the performance of any decently-written C or C++ program. Not to say that there aren't other things going for it - there definitely are. But performance is NOT one of them. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >> Sanders Kaufman wrote: >>>> And yet - PHP is *constantly* used for large, successful projects - [quoted text clipped - 51 lines] > or C++ program. Not to say that there aren't other things going for it > - there definitely are. But performance is NOT one of them. And yet the current crop of benchmarks consistently place Java runtime speed in the same ballpark as C++ programs. Jake2 achieves pretty high frame rates, and that's with Java graphics which always are going to be slower, just not by nearly as much as people suppose. When it comes to CPU computations and other operations typical of many application mixes we find Java systems equaling or exceeding the performance of statically-compiled languages. This is in part because of garbage collection - C++ programs have been measured as spending 25-30% of their execution profile in allocation and deallocation. Java's techniques are much faster than most C++ allocation strategies. <http://www.ibm.com/developerworks/java/library/j-jtp09275.html?S_TACT=105AGX02&S _CMP=EDU> <http://www-128.ibm.com/developerworks/library/j-jtp01274.html> <http://www.idiom.com/~zilla/Computer/javaCbenchmark.html> The age of these articles points to how long the urban legend of Java's supposed slowness has been debunked. JVMs for Java 5 and 6 are far ahead of earlier versions for performance. <http://java.sun.com/performance/reference/whitepapers/6_performance.html> Here's a recent link that favors C++: <http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html> Notice that here the performance gap is much lower than people suppose - about 2.5:1 overall. And that included JVM load time! This is a bit of an unfair advantage to C++. No one denies that Java takes a while to load, and its optimization profile is run-time tuned, not static. That means you don't get optimal performance from a Java program until it's been running for a while. We have to make sure that we aren't saying a sprinter is a better runner than a marathoner because our test race is 100 meters long. We can say it's better to put the sprinter in the dash and the marathoner in the long-distance race. When benchmarks compare longer-running processes like server systems, we find that Java actually outperforms C++. Even so, there's a need to consider results like: <http://blogs.sun.com/dagastine/entry/sun_java_is_faster_than> (linked via <http://blogs.sun.com/teera/entry/java_performance_benchmark_roundup> ) Remember, too, that we're talking about large-scale systems, for many Java shops. There is an awful lot of multi-processing, multi-threading, inter-process communication (IPC), XML, security and certificates and stuff like that going on. Such systems typically measure performance as throughput and uptime. SignatureLew >>> Sanders Kaufman wrote: >>>>> And yet - PHP is *constantly* used for large, successful projects - [quoted text clipped - 109 lines] > stuff like that going on. Such systems typically measure performance as > throughput and uptime. First of all, I understand what you say about large scale systems. But part of the performance gain comes from the relatively easy means of multithreading in Java. It's harder in C++, but can be done. However, having to deal with shared memory, etc., makes things slower. I agree that some C++ compilers don't do a good job allocating memory; but at the same time I've seen some very poorly written C++ programs. Ones where some relatively simple work would make it run significantly faster. And quite frankly, some of the C++ libraries I've seen out there are written so poorly it's a wonder you get any performance out of them at all. Many of Java's classes (especially the UI's) are typically more efficient in that many C++ class libraries. Uptime is a non-point. Either one can have 100% uptime. Throughput is one measurement used. However, CPU load is another, especially when it comes to large systems. And Java typically requires more CPU cycles to do the same job than a compiled language does (again, if both are optimized). If that's the only job running, then yes, Java can outperform C++ if the C++ program is single threaded. However, get a heavily loaded CPU, and Java will typically slow down more quickly than C++. Now please don't get me wrong. I am NOT bashing Java. I use it, and at one time was Sun Certified in it (just never kept up the certification). And I agree it is a good programming language. But it is not the answer to life, the universe and everything. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > comes to large systems. And Java typically requires more CPU cycles to > do the same job than a compiled language does (again, if both are > optimized). That's just not true. I have shown you many links explaining otherwise; you've provided absolutely no evidence for your assertions. Are you following the Big Lie principle - repeat a big lie often enough and people will start to believe it? SignatureLew >> comes to large systems. And Java typically requires more CPU cycles >> to do the same job than a compiled language does (again, if both are [quoted text clipped - 4 lines] > following the Big Lie principle - repeat a big lie often enough and > people will start to believe it? Nope. And I haven't seen any unbiased "proof" in any of your links. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >>> comes to large systems. And Java typically requires more CPU cycles >>> to do the same job than a compiled language does (again, if both are [quoted text clipped - 6 lines] > > Nope. And I haven't seen any unbiased "proof" in any of your links. So even the article that favored C++ you regard as biased, eh? And what is your evidence that these articles were biased? All they did was report facts. I hear rhetoric from you, but no evidence. At least I dug up objective results. You have grown tiresome. SignatureLew >>>> comes to large systems. And Java typically requires more CPU cycles >>>> to do the same job than a compiled language does (again, if both are [quoted text clipped - 16 lines] > > You have grown tiresome. Spoken like a true evangelist. My product is better, no matter what anyone says. And no, I don't place any trust in any of them because they didn't lay out detailed conditions for the test. There is not enough information in any of them to determine how valid the test was. You have long ago become tiresome. But I still tried to carry on an intelligent conversation with you. I see now that is impossible. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== > You have long ago become tiresome. You're right, I shouldn't have gone there. > And no, I don't place any trust in any of them because > they didn't lay out detailed conditions for the test. > There is not enough information in any of them to determine how valid the test was. Some of those sites laid out source code for their tests. How much more detailed does it get? They also laid out things like what the hardware was, what parameters they used to compile the C++ code or run the JVM, what other loads if any were on the computers, what the exact results were. Then you come back with provably false comments like "they didn't lay out detailed conditions for the test." People can follow the links for themselves and judge. I laid out a cross-section of benchmark sites and technical articles that explained the techniques used to optimize JVMs, and btw, also the Microsoft CLR. For three or four years technical experts have explained why the gap is narrower than commonly supposed, and occasionally inverted. The JVMs have continued to improve in that time. For you to out-and-out mischaracterize the content of those benchmarks with such patently contrafactual remarks is startling. Then you speak of "intelligent conversation" - I don't dispute your intelligence at all. However, I have provided much evidence and hard evidence at that, that the issue of performance bears closer examination. I have been balanced in the presentation, linking sites that show C++ being faster and under what circumstances - as importantly, by how much. The numbers and conditions are laid out in sufficient detail to make results duplicable. This quite aside from industry-standard benchmarks like those from SPEC that also speak to these matters. If you're going to stick with Monty Pythoneque "No, it isn't" responses, at least pick ones that won't fall apart the second anyone follows the benchmark links provided upthread. If hard evidence and real-life measurements don't fulfill your requirements for "intelligent conversation" then you're pretty much SOL, you're right. SignatureLew >> You have long ago become tiresome. > [quoted text clipped - 8 lines] > was, what parameters they used to compile the C++ code or run the JVM, > what other loads if any were on the computers, what the exact results were. ... May I suggest a constructive approach to analyzing the issues: 1. Lew pick and post links to one or two benchmark reports that he feels most strongly support his case, and are most defensible. 2. Jerry comment on whether, if sufficiently documented and reproducible, the benchmarks would mean what Lew claims they mean. 3. Jerry comment on what, if any, specific information is missing that would be required for reproducibility. Once that is done, it should be possible to contact the authors and ask about any missing data. Was it collected? If so, can it be posted? Patricia >>> You have long ago become tiresome. >> [quoted text clipped - 26 lines] > > Patricia Patricia, Sorry, I'm done with Lew. Others in this thread have been reasonable. Lew isn't. Signature================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== >>>> You have long ago become tiresome. >>> [quoted text clipped - 31 lines] > Sorry, I'm done with Lew. Others in this thread have been reasonable. > Lew isn't. Would you go along if we change step 1 to "Patricia posts the links that most strongly support Lew's case"? I'm have been interested in computer performance for a long time, so I want to get the performance aspect of this back to the issues, not personalities. Patricia > I'm have been interested in computer performance for > a long time, so I want to get the performance aspect > of this back to the issues, not personalities. It's a commendable attitude, but in the final analysis, performance of complex systems is always going to be about personalities (meaning, personalities of those who fine-tune those systems). Last September, Rasmus Lerdorf, the creator of PHP, gave a keynote speech at the php|works conference in Toronto. During his presentation, he demonstrated several performance-tuning techniques that increased an application's performance from 17 requests per second to 1,100: http://www.internetnews.com/dev-news/article.php/3631831 Cheers, NC > Last September, Rasmus Lerdorf, the creator of PHP, gave a keynote In 2006, not really last September, but the September before last. A minor point... > speech at the php|works conference in Toronto. During his > presentation, he demonstrated several performance-tuning techniques > that increased an application's performance from 17 requests per > second to 1,100: I didn't see any optimizations or code there. Did I miss them? It's just an article saying that he did. No info at all... > > Last September, Rasmus Lerdorf, the creator of PHP, gave a keynote > > In 2006, not really last September, but the September before last. Indeed. My apologies for the mistake. > > speech at the php|works conference in Toronto. During his > > presentation, he demonstrated several performance-tuning > > techniques that increased an application's performance from > > 17 requests per second to 1,100: > > I didn't see any optimizations or code there. But that's the point. No coding was required. Performance improvement was achieved purely by means of system administration (installing an opcode cache and changing MySQL configuration settings). So every time I see a performance test, I wonder which optimizations testers chose not to use or didn't know of... Cheers, NC > But that's the point. No coding was required. Performance > improvement was achieved purely by means of system administration > (installing an opcode cache and changing MySQL configuration > settings). So every time I see a performance test, I wonder which > optimizations testers chose not to use or didn't know of... Optimization is always both situational and non-transferable. The best one can do is create a benchmark that is reasonably representative and is duplicable. Ececution speed is also not the only, or even usually the most important consideration. By far the largest cost of most software is not when it's running, but when it's not (or not correctly at least). Once performance gets in the ballpark, in other words, once with appropriate effort you can get Java or PHP or C++ or C# or whatever to run with approximately equal efficiency, the ability to manage team projects, create all desired features and minimize risk will be the dominant factor in platform selection. Development and maintenance costs will trump execution costs. Benchmarks have shown that Java, C# and C++ are all in about the same ballpark with respect to performance for most applications where these platforms are considered. Strongly-typed languages like those three tend to win in the choice of platforms for managed projects because of the robust API libraries, language support for risk mitigation and feature support for concurrent programs and other common requirements. The availability of trained programmers factors in as well. The best benchmarks will simulate typical work loads for a host under explicit conditions. None will ever be perfect, because the real world is not committed to working the way benchmarks do. At some point one has to assert that the platform is fast enough, and look for other criteria to choose the right one. SignatureLew > Optimization is always both situational and non-transferable. Situational, definitely. Non-transferable, I am not sure I agree. For example, deploying PHP as a CGI executable is always a losing proposition compared to either HTTP server module or FastCGI. The choice between HTTP server module and FastCGI usually depends on the HTTP server and the operating system. On BSD, regardless of the HTTP server, FastCGI usually works better (that's the setup Yahoo! uses). With Zeus, regardless of the OS, developers also recommend FastCGI. The Linux/Apache crowd is unevenly split, with majority preferring the Apache module and a sizable minority (including folks at GoDaddy) leaning towards FastCGI. > Once performance gets in the ballpark, in other words, once > with appropriate effort you can get Java or PHP or C++ or C# [quoted text clipped - 3 lines] > selection. Development and maintenance costs will trump > execution costs. For small-scale applications, almost always. For large-scale applications, almost never. In 2006, Google's R&D costs were $1.2 billion, while its purchases of long-lived assets (mostly computer equipment and buildings housing it) amounted to $1.9 billion: http://www.sec.gov/Archives/edgar/data/1288776/000119312507044494/d10k.htm And that's Google, running its production systems on a proprietary Linux-based software stack. Were we talking about a company whose production systems run on an out-of-the-box commercial stack (WebSphere/Oracle or Windows/SQL Server), R&D costs would be lower (no in-house development of kernel and file system) and purchases of long- lived assets, higher (licenses for commercial software running on numerous production servers). > At some point one has to assert that the platform is fast enough, > and look for other criteria to choose the right one. Indeed. And one of these factors just happens to be licensing cost. And that's where PHP (and, I might add, Python) shine, as they can be deployed on an open-source software stack. Cheers, NC Lew wrote: >> At some point one has to assert that the platform is fast enough, >> and look for other criteria to choose the right one. > Indeed. And one of these factors just happens to be licensing cost. > And that's where PHP (and, I might add, Python) shine, as they can be > deployed on an open-source software stack. Many Java-based systems, including one of the benchma |
Enable EMail Alerts
Start New Thread
Reply to this Message