PHP compared to Java/J2EE

[Sanders Kaufman]

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.

 

[Daniel Dyer]

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.

 

[Jerry Stuckle]

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.

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:

- 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.

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Jerry Stuckle]

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.

I don't think that's fair. PHP can be and is used for a lot of large
projects. And Java can be and is used for a lot of small projects.

But what you're saying is that Java isn't good for a forum or smaller
project. And that is definitely not true.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Lew]

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.

 

[Jerry Stuckle]

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?

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.

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Lew]

A large number also use PHP. Java isn't the only language used.


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.


So? What does it prove? A change in a stock symbol often causes a
change in the stock price.


Who's survey? And define "professional use".


I don't think anyone ever argued that Java isn't widely used. But so is
PHP, C, C++, COBOL...


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.

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.

 

[Jerry Stuckle]

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.

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Erwin Moller]

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.

PHP for fora at most?
You must be joking/trolling.

I have written big stable mission critical applications running in
serious companies, with only PHP/Postgresql. They still run and perform
greatly up to today.
I am sure a lot of the folks in here did the same.

If you think PHP can only handle a forum, that says a lot about your
understanding of PHP, not PHP itself....
It is a totally untrue observation.

I have done a lot of work in both languages, and I deliver about 2-5
times faster in PHP than in J2EE.
But maybe that says something about MY understanding of J2EE.
;-)

Bottomline is that PHP is a lot easier to learn than Java, so a lot of
bad programmers program in PHP, since they don't get Java.
That is not PHP's fault, but leads to an army of avarage/bad programs in
PHP, and also give PHP a silly name to a certain extend.

It is totally 100% possible to program right in PHP AND make complex big
industry strength applications.

Why on earth do you claim a forum is the best PHP can do?

Regards,
Erwin Moller

 

[NC]

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

 

[Mark Space]

I have written big stable mission critical applications running in
serious companies, with only PHP/Postgresql. They still run and perform
greatly up to today.

Just curious: You mean Apache/PHP/Postgresql, right? Because I've
never heard of anyone writing just PHP by itself.

How large were these mission critical apps? For example, how many lines
of code, and how many files? I'm just trying to get some objective
metrics here.

 

[Rik Wasmus]

Just curious: You mean Apache/PHP/Postgresql, right? Because I've
never heard of anyone writing just PHP by itself.

Well, it could be done. Not really a standard though, and hardly advisable.

 

[NC]

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?).

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

 

[Mark Space]

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....

 

[Jerry Stuckle]

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Mark Space]

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......

 

[Sanders Kaufman]

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).

Actually, no.
I was thinking of a game I used to play on (i think) iWon.com - back when
Java first came out, pre-php.
It had both a client and server component in Java.
I thought it was pretty cool because it was the first game I found where web
users could compete with each other.
Not exactly a massive-multiplayer thing, but it was a start.

 

[Mark Space]

...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/

" 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. "

 

[Daniel Pitts]

And yet - PHP is *constantly* used for large, successful projects - while
Java sites are pretty much limited to pretty pinball games and such.

I disagree, I know large sites that are written in Java. As a mater of
fact, the company I work for (a *huge* internet presence) is largely a
Java shop. Some of our child properties use PHP, but they run into
scalability problems more often than the Java shops.

 

[Jerry Stuckle]

And yet, I was asking about your problems with JDBC with Linux and
MySQL......

I didn't specify Linux and MySQL.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================