PHP compared to Java/J2EE

M

Mark Space

Jerry said:
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?
 
L

Lew

Jerry said:
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?
 
J

Jerry Stuckle

Mark said:
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?

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.

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

Jerry Stuckle

Lew said:
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?

Nope. And I haven't seen any unbiased "proof" in any of your links.

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

Lew

Jerry said:
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.
 
J

Jerry Stuckle

Lew said:
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.

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.

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

Mark Space

Jerry said:
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.
 
J

Jerry Stuckle

Mark said:
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.

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.

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

NC

" This is a funny result. I am my self a PHP enthusiast, but in the
journal $B!H(BACM SIGMETRICS Performance Evaluation Review, Volume 31 Issue
3$B!m(B there was an article called $B!H(BA performance comparison of dynamic Web
technologies$B!I(B 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. "

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
 
L

Lew

Jerry said:
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.
 
P

Patricia Shanahan

Lew said:
You're right, I shouldn't have gone there.


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

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
 
S

Sanders Kaufman

Lew said:
Nearly every agency in the U.S. Federal government uses Java for their
enterprise servers.

I was just being smarmy.
(Couldn't you tell by the tone of my voice and the expression on my face?)

Java is really no better or worse than any other language.
 
J

Jerry Stuckle

Patricia said:
...

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

Patricia,

Sorry, I'm done with Lew. Others in this thread have been reasonable.
Lew isn't.


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

Patricia Shanahan

Jerry said:
Patricia,

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
 
N

NC

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
 
M

Mark Space

NC said:
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...
 
R

Roedy Green

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

The company I do most of my consulting for makes the bulk of its
living rewriting apps in Java that have become too large for PHP, such
that every bug fixed seems to create two more.

With every tool, even assembler, a skilled programmer can have the
discipline to write arbitrarily large projects, but given that your
average programmer has average skill, it is best to use a language
for large projects designed for large projects, e.g. that enforce a
strong degree of order -- e.g. strong typing, object oriented,
information hiding, large standard libraries, enforced documenation,
rigid formatting and naming conventions...

One of my friends committed suicide after using Visual Basic for a
project. It was a perfect fit at first, and he dazzled everyone with
the progress but as the project grew larger it became an unbearable
embarrassment crawling with bug after bug. Nothing could be changed
without introducing ever more bugs.
 
P

Patricia Shanahan

Roedy said:
The company I do most of my consulting for makes the bulk of its
living rewriting apps in Java that have become too large for PHP, such
that every bug fixed seems to create two more.

However, are you sure that a similarly skilled redesign and rewrite in
PHP would not have done as well?

Patricia
 
N

NC

In 2006, not really last September, but the September before last.

Indeed. My apologies for the mistake.
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
 
L

Lew

NC said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top