Php is not good?

Anon

Hi everyone,my boss gave me a document from a big Java-software-house, to declare the power of Java vs. PHP it says:

...As the size and traffic on the site goes on increasing it becomes indispensable to use distributed architecture with multiple layers logically arranged to carry out business processing and database interactions.
To illustrate main problem with PHP for using as middle layer and back end processing is illustrated by a simple example. Lets say, a front-end PHP page has only one page included for doing business processing and one page for data extraction from database, and each page is of size 2Kb(very likely to be larger).
Now, for every hit of this page 6KB of memory will be used till the time request is being processed, and if there are 100 hits at a time for 600KB of memory will be used.
This is a case of a single page and there may be a number of pages like this.

But if the above system is implemented in distributed model then objects doing business processing and database operations can be shared and pooled across a number of requests, which will make system more stable and easy to handle for heavy traffic.

It'is true? 100 hits = 100 different process?I can't believe it, please help me to defende PHP (they want to change our architecture in a Java based one...)

Tanks a lot
Laura

Anon

I bet if you go to php.net they will say that php is better than java. Get your bench marks from mysql and mysql will say its faster. Get bench marks from postgesql and suddenly postgresql is faster. Get me some unbiased bench marks then Ill make a descision. Im not going to be bias to php just because I use it.

Anon

Privacy and security are of growing concern to surfers, an increasing number of whom now disable client-side scripts, java, javascript, Active-X & cookies. Don't alienate your customers. Server-side PHP is more 'trustworthy', can't be 'malicious' and can't be turned off.

Anon

Their example is silly and misleading. Yes, if you really do have 100 pages being served <i>simultaneously</i> then you do have 100 process or threads along with 100 tcp/ip connections, but so what? If all it took were 600KB of memory to keep 100 simultaneous connections happy, then our life would be wonderful and Sun, HP, IBM et al would be selling a lot fewer of their big server boxes!

Besides, if all 100 simultaneous pages were hitting on exactly the same Java business-logic component, you'd either have an additional 100 processes/threads active to handle all of them, or you'd have 100 requests queued up somewhere making a bottlenect at the business-logic level.

Finally, there's no reason PHP (which is really optimized for creating html output for display) can't coexist nicely in a multi-tier system where it communicates with other components written in other languages.

PHP is actually used by a number of fairly large sites; php.net has a list somewhere...

Anon

Kirk Parker wrote:

PHP is actually used by a number of fairly large sites; php.net has a list somewhere...

You can find it at:

http://www.php.net/sites.php

Just by simply pointing out that some extremely high traffic sites such as www.honda.com or www.xoom.com are using php can make your point heard.

If you want difinitive proof they are running php (and what version) goto:

http://www.netcraft.com/whats

and type in either of their homepage url's and it will tell you what OS and web serving combo the site is running on. Hope that helps!

Chris King

Anon

If your boss read that and believed it, you should immediately find another boss, preferably one with a brain.

The fact is, for EVERY incoming connection, your web server has to fork or have a second thread. Each of these threads weighs in at 1 to 10 Megs depending on who wrote the web server and what kind of application serving you're using.

The fact is, an apache thread to handle that incoming page is gonna weigh about 1.5 megs, a php apache thread will weigh about 2 megs. They will each have about 90% of that be shared memory, meaning the incremental increase in memory usage is about 150 to 200k per page.

That Java paper was written by an idiot in marketing who has NO idea how to build a scalable web server, but was just spouting dogma from his boss.

Generally speaking, Java Server Pages and PHP Are pretty close in performance on similar hardware, but PHP scales better, because each apache/JSP child weighs in at about 5 Megs or more, of which only about 2/3 of which are shared memory, resulting in a machine that will eat up available ram faster under a given number of connections than will PHP.

Anon

I'm pretty new to PHP, but in my humble experience, Java Application Servers take up much more RAM than PHP. For example, the minimum requirement for WebSphere is NT Server, 256 MB RAM... and is not very fast. WebLogic does a much better job, but it also needs a minimum of 64 MB in RAM. PHP, on the other hand, needs less RAM and CPU, but doesn't pre-compile the pages before using them.
You know, Java Applicaton Servers are designed to provide a complete object-based framework, and are suppossed to be forced to implement the complete J2EE specification, which makes them pretty big... PHP, at first sight, only pretends to serve pages written with its script language, which is very powerful, and does a lot of other things through third-party modules. It gives it a very small footprint (but PHP does not implement an HTTP server, and J2EE normally does).
But you can't forget that Java's object framework is incredibly powerful and well-designed, so I wouldn't be so afraid about changing to object-oriented design; it will surely look nice on your resume :-)

And I would tend to suggest a J2EE App Server if I was to implement enterprise-wide solutions, as banking or financial ones. I don't know if there are any PHP modules for CICS or MQSeries, or even connections to TP monitors (Tuxedo, etc). You know how much big enterprises like to spend their money on these kind of technologies...

But of course, for development speed, a nice bag'o'tricks, and elegant design, I would always suggest PHP. And you can't beat its price :-)

Anon

QUOTE:

I don't know if there are any PHP modules for CICS or MQSeries, or even connections to TP monitors (Tuxedo, etc).

ENDQUOTE

We use IDMS where I work and need to get data out of it and into PHP to do things like make live pdfs from renewal notices and quotes.

We use Vega 90, the web server from finland, sold by CA, and it has the ability to deliver XML and run SQL queries right agains the IDMS database. It's prmimitive, and kinda ugly (especially the code on the IDMS side...) but it works a charm, and costs a lot less than MQ or TPF or the pseudo odbc CA makes (it only works with NT and 95...) or any of the other really expensive pacakges for connectivity we've looked at, and at the same time we can convert adso dialogs to web based dialogs, eliminating the need to train new people on how to run a 3270 green screen IDMS session, which is way more complicated than it needs to be.

As for the belief that "enterprise" class stuff works better with Java, what I've seen tells me that that's more market-speak than reality. For some situations, it has better connectivity than PHP, and for others, PHP is better. The real difference I've seen is development time, which is usually much greater under Java than PHP, Perl, or Python.

My primary complaint is still that it feels like the J2EE standard is trying to EVERYTHING in Java, and nothing in the database or external systems. Maybe it's not really like that, but all the examples I've seen seem to be trying to replace the logic I already have in my databases with their own layer of logic in Java.

Anon

Well, it's great that these kind of unusual modules exist somewhere... Of course, you should ALWAYS be able to build your own home-made access to any kind of database or middleware. I guess PHP and Java would be at a tie here, since both allow this kind of low-level solution (maybe it is harder in Java - have you tried to use JNI?)

I was talking about my experience because I worked at a bank, where we were trying to catch up with the whole hype world of internet financial services. Most of the code was ASP, some PHP (the apps that didn't need to connect to enterprise dbs), but at the end, when migrated to Java, all the pieces started to interlock more easily. Note that I'm not saying that this was a good solution, since the App Server really sucked (is the one that IBM sells 🙂 and there were way too many problems. But from the development point of view, it was a lot easier to join all database access under the same abstract layer and reusing financial math again and again. Also, the access to CICS and DB2 on the mainframe was lightning fast. So I would say that on this special case, Java was better than PHP. But again, I'm relatively new to PHP.

I think you're right about J2EE trying to do everything, at least on most of the tutorials. If you have most of your logic embedded in stored procedures, triggers and similars, I think that's the better approach. It is not very portable to other databases, but is maybe the fastest solution around. I just think that tutorial writers are very program-oriented and not database-oriented. But that's what Entity Beans are designed for: they let the database do its work and just try to interact with it to encapsulate the data into an object. Maybe nobody uses them because they don't deliver what they promise?

Regards