Slashdot Mirror
PHP Scales As Well As Java
mactari writes "Jack Herrington at the O'Reilly Network has had the audacity to claim that
both PHP and J2EE architecture... are converging on the same design [regarding scalability]. Can it be that he's disproven the idea that 'Java scales and scripting languages don't' when he says, 'The idea that PHP does not scale is clearly false at the performance level'?
Even if a little oversimplified (ignores horizontal scaling), it's an interesting comparison that takes a peek at the architecture beneath both hypes."
And the other recent additions that add to the scalability of Java?
Java and PHP Scale equally well... Well that isn't a big surprise since Java as I understand it doesn't scale very well..
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
pudding is as good of a building material as tofu..
A computer without Microsoft is like ice cream without ketchup.
we use PHP here for huge web applications.. we have six servers pumping out one website and it connects to a redundant database server.
The same system in java probably would not work, and if so would take up so many resources as to be no efficient.
If you are interested in more examples of some somewhat crazy things you can do in PHP check here to see examples of using it on the commandline for ncurses (which I wrote the primary tutorials on zend.com for) and for handling sysv shared memory.
Cheers
anime+manga together at last.. in real time.
Okay, talk about asking for a flaming! I'm a PHP developer whose done a bit of Java but knows nothing about J2EE. Can someone explain how this is relevant to me, as I start looking at larger applications with hundreds, perhaps thousands of users?
Well seeing as Yahoo is switching over to php, from C no less! Plus if you want to, you could use slashdot as an example of scripted sites. Of course slashdot at random interval won't load for about 10 or 15 minutes (rarely longer).
/* oops I accidentally made a comment, sorry */
Perl seems to scale as well--it runs a very busy site I frequent with few problems.
2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem ... last time I checked, Java did considerably better than PHP in terms of both.
3. As PHP was not designed as a multipurpose language, sometimes a PHP-only solution is simply a kludge. PHP's power is in writing webpages quickly, if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy. Yeah, you can do that in C, but what's the point ?
The Raven
Java scales up very well, PHP scales down better.
If you're trying to run on a budget where you can't add a ton of servers and are limited to aging technology, Java will not scale to that environment very well. PHP can do quite well there.
Sun isn't interested in that market, which is a shame because there are a lot of companies still cutting budgets. I'd love to buy a server newer than a P2 1ghz, but it's not going to happen until at least next fiscal and even then, unlikely. We don't all work for technology companies who understand or care.
The global economy is a great thing until you feel it locally.
...then yes, it does. However:
"PHP can use the database as the back-end session store."
and
"The ideal multi-server model is a pod architecture, where the router round-robins each of the machines and there is only a minimal session store in the database."
are pretty tough assumptions to swallow. Storing session state in a database only works when you have a small amount of session state to store. Otherwise the database quickly becomes the bottleneck for any operation you need to perform. The alternative is that you have to have your session state distribuited in a cluster, which is something that, AFAIK, you cannot do in PHP. You can, however, do it Java. In fact, some of things that JBoss is trying to do will make session replication across a cluster fairly easy.
PHP can be very useful. I think PHP as a view layer sitting on top of a a J2EE controller and object model would be a wonderful idea. But to say "PHP scales as well as Java" is a huge oversimplification of the extremely complex problem that is enterprise computing.
When I read the story above, I saw "Jack Herrington at the O'Reilly Network has had the audacity to claim that ..." and thought to myself, "why would the person who submitted this write it like that?".
Then I read the comments, and it seems that people actually get seriously OFFENDED by statements like that! You're reacting almost as if the guy insulted your mom! Calm down... breathe...
-- Dr. Eldarion --
"A page showing ten fields from twenty objects would make two hundred RMI calls before it was completed."
Sure if it was coded by former vb guy w/o a clue.
Even naive J2EE applications I saw would be smart enough to use a view object (containing all twenty business objects and their fields) to come back from the buisness layer in one call.
A person to use argument like this about J2EE scalability has no credibility whatsoever.
The article repeats that it just scales as well as Java quite a bit. Maybe it does. At runtime. But it sure doesn't at maintenance time!!!
Daniel
Carpe Diem
PHP offers us no way to build an application server (unless you write one in C or C++ and send commands to it via a cli or directly through sockets). If you embed Tomcat in your application server, you can simply create contexts and mount them with mod_jk. Quite simply, you can take any server that you've written in Java and web enbale it fairly quickly. PHP lacks persistence, and I'm not talking about sessions.
Let's say that we want to add a request to our application from the web. With Java I can toss the request on a queue which a thread picks up and balances to several other worker threads who interpret the request and works with it. With PHP I would have to enter data into a flat file, or a database, and have a cronjob setup to run every minute or so and do something with data in the database. Even then, at that point, I can only have one thread unless I want to mix and match several cronjobs to run at seperate times (or unless I want to fork the process off very uncleanly using exec() or system()). In any case, does PHP scale as well as Java? Maybe, I'd need to do more tests. Is it nearly as useful? No, not right now, probably not ever. Unless you are willing to write your own custom PHP module in C and play with PHP that way, I think big jobs should be left to the heavyweight in this discussion.
"It's here, but no one wants it." - The Sugar Speaker
The article doesn't ignore horizontal scaling. It scales to over twice the width of my browser.
Programmers like other professionals need to establish a sense of professional elitism. PHP is a language that just about anyone can use, and when you have something that just about anyone can do, then you won't get the big bucks.
Programmers, doctors, lawyers need to fortify their salaries with an impenetrable layer of jargon. Java has the jargon.
The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.
Php and Java aren't the same kind of language, so why do people insist on trying to compare them? Php works great for a lot of applications, but expanding its function base is a fricking nightmare, and you're dealing with a certain amount of compile time overhead on every page view.
With Java you have easy access to a lot of OOP features that are very difficult to implement in Php, and the function base is simple to expand. Yea it's big and beefy, but that's what you need sometimes.
They're both just tools. Use the one that's appropriate. People scream about Java being bad for small pages. What kind of idiot is using Java on a small page? Conversely I've never even heard the Java vs Php agrument for a big site--it's always Java vs VB, and that's another no brainer.
Just my opinion.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Storing session state in a database only works when you have a small amount of session state to store
I think developers need to commit to smaller session footprints on servers anyway. Our goal here is to have nothing but security information stored on the server - and I think that's very reasonable. Make everything else come on the request.
We see a lot fewer bugs this way, and everything becomes easier to maintain. The database can handle the login information fine (thus far at least - our applications are all very data intensive to begin with), and being in the database means session info is easy to manage.
To me, having another a session quasi-database replicated around the cluster seems like an ill-fated enterprise.
Web development, though, is like that I guess. It's always difficult to picture what works for applications different than your own. The 100,000 lookers at site A call for a different setup than 10,000 workers at site B might need.
Let's not stir that bag of worms...
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
In the article, the author assumes that the J2EE application includes EJB's and from this assumption he builds in additional layers of overhead, especially with RMI calls to the EJB layer. His assumption is incorrect.
If you really want performance in a J2EE app, you can stick to JSP's and servlets and limit the usage of EJB's. Still keep the presentation in the JSP layer and isolate the business logic in servlets. This approach is quite lean and scales hugely.
When and how to use EJB's is just one part of J2EE application design.
Then start your own company, or become an independent consultant and take the contracts you are interested in.
There is more at stake in any given project then what YOU can do faster since there are probably other people that can do it faster with the tools they want to use. If you are in a company and have an opportunity to promote the technology or language you think is best, do it--but don't make "because I can do it faster" one of your arguments. Unless you *ARE* the development team it really doesn't matter what you can do faster. Maybe you're not the right person for this job.
I'm an independent consultant and I often peruse job sites to see if there are any interesting consulting jobs out there. I've actually never found one using those sites, but I often see lots of entries for ASP work, etc. I obviously don't bother contacting them and try to convince them, "No, I don't do ASP. But what you REALLY want to do is..." That won't work. I just move on and find a company that coincides with what I agree is the better solution. Fighting the powers-that-be to use a different language is a high-stress, tiring proposition and what I want to do is develop, not campaign.
i've used PHP, and it's a bitch to debug and to understand in general. it's nice for script kiddies, but outside of that, i'd leave it alone. java isn't really a good tool for websites either though, at least not java's jsp. There's many nice templating engines available under java which are VERY nice for dynamic sites (velocity, freemaker, etc). Let java handle your business logic, and let templates run your user interface.
The problem with PHP isn't dynamic typing, it's loose typing.
Scheme has strict dynamic typing. You get more concise code, but not so error prone as PHP.
Java has strict static typing, possibly somewhat less error prone, but less convenient.
Languages like ML have strict static typing, but type inference makes the code more concise.
This seems extremely unlikely. Do you have any evidence to support your claim?
I would say that the zeal and disgust is partially a marketing tactic. It's partially a way to differentiate between someone who has dabbled with and actually lives the zen of the job.
You might see a similar zeal within print-graphic designers against kids and small-business with immature corporate identity. We all know traditional printers have been hurt by the availability of cheap grapic ap's and ink-jets. We all poo-poo a bad web design when it has the hallmarks of someone who doesn't know what they are doing. When anyone and their dog can build an HTML page, you can't be indifferent about bad design when you are an experienced developer. Clients will learn there is no benefit to paying you, and they will realize that useless websites have to be the norm
We have to make those comments though, because otherwise most clients wouldn't know the difference between good work and bad work unless you point it out. And not every manager will immediately connect the dots (even with a presentation) of concepts like lowering cost by reducing bandwidth.
So you have to train yourself to stand up for what you've committed yourself to. More importantly you have to SELL what you believe. If you treat your own skills with indifference, then others will consider your skills as such. They will also put more trust in the programmer who is not just convinced, but *knows beyond a shadow of a doubt* that rolling with a particular language is the right thing to do. What else does a non-programmer have to go on? (Besides, do you expect a programmer so say... "I only work with slow, awkward languages")
Jetty running on that single aging server will blow the doors off of PHP. That's what I saw when I did some BRL benchmarking some time ago. Presumably you'll get similar results with JSP.
"PHP doesn't have strict typing, so it's harder to maintain."
That's not a language issue, it's a programmer issue. Learn good habbits.
Perl seems to scale as well--it runs a very busy site [slashdot] I frequent with few problems.
I've been having a great deal of broken pages lately.
I also have been having a lot of problems with the RSS feeds lately.
Overall, I like using slashdot as an example of why mySQL and perl are bad ideas for busy sites.
Any language can be used to write bad code, but I've rewritten really perl projects (2M line range) that were impossible to maintain into java (for example) applications that were not only easier to manage, but performed better.
Whether raw perl is faster than raw java, who knows or cares? When I want raw speed, I write apps in ocaml (or C if I need slightly more speed). When I want to prototype something quickly, I write apps in python. When I want to build a large scale application, I use java (and python for parts). With a proper design, going from one application server to two doesn't double the strain on my database server (not even close), but usually doubles my capacity. It also doesn't require a rewrite of the app.
Then I start making things happen asynchronously with threads and message queues. These days, my apps are looking more like mainframe apps from performance monitors. We maintain a pretty high load here, and I watched it triple during some event for a few minutes. Processing speed was constant due to surge protection I was able to make using a simple thread and a linked list. For our most common type of database work, there is no more than one insert/update occuring per application server instance. That makes such a huge difference.
-- The world is watching America, and America is watching TV.
We have a 500,000+ line VB project that is very GUI intensive and it works/scale quite well. OO is good for some applications, but its more work than its worth for others. There are places in our project where having inheritence would be very helpful, but we have designed around this limitation. Threading for would have limited use as well. The ease of the GUI building more than makes up for the threading and OO limitations, at least in our project.
I'm not sure if your post was a troll or not, but it is pretty arrogant to assume any one language, especially one as widely used as VB, is for "kiddies."
and
Can I create a class and inherit from it?
So your Fortune 500 company obviously hasn't heard of VB.Net, I take it?
I have no dog in the language semantics fight here, but most of your points are valid pre-.Net days, which means your points are invalid.
I pulled a jack move to cop this sig
I work for a Fortune 500 company as well, and one of our major web apps is written in a combination of ASP, VB and C++.
It's not clear to me that object oriented programming is a criteria for enterprise applications. Many of our big enterprise apps still use COBOL.
This all depends on how you define scalability, and what the app does. On our app, the web, business logic and data tier is all in VB, the calculation engine is in C++. We use Oracle as a back end. It handles the volume, for now.
Does it scale? Well, that all depends on your definition. Right now we have like 36 two-proc servers handling the load. It scales horizontally, just like PHP in this example.
For the past year they've been rewriting the whole app using C#, and it's almost done. During testing they've been able to handle the same load on four 8-proc servers, which is a bit easier to manage than 36.
"Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make."
It depends. The C++ part of our app costs 4 times more to maintain than the VB part. It may be worth it, it's hard to say. I'm just glad we now have options like Java and C# out there, so I don't have to beat my head against the C++ wall.
Python, Perl, PHP, Ruby... Thats four object orientated languages without strong typing, all of which have an extremely happy and loyal fanbase, and theres a lot more.
Just for once, I'd like to see someone explain why strong typing is so important. I develop most of my code in Python, and I have yet to see any problems. Hell, I find strong typing restrictive as it prevents me from doing things I otherwise should do. I'm currently working on a project of (according to cat | wc -l) 320812 lines, an god knows how many classes. I've yet to have one bug related to the lack of strong typing.
So heres my challange to all you strong typed zealots. Explain why it's so important!
Python, Perl, PHP, Ruby... Thats four object orientated languages without strong typing
/: 'str' and 'str'
Python is a strongly typed language with extremely late binding.
Variables can change type at runtime, which means it's late binding.
Strong typing just means that variables definately do have a type (even if it can be easily changed) and you can't apply an illegal operator. For example:
>>> one = '1'
>>> two = '2'
>>> two / one
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for
>>> one = int(one)
>>> two = int(two)
>>> two / one
2
>>>
so, you can change a variable's type, but it still does have a type, and as long as it has that type it's enforced strictly.
Social scientists are inspired by theories; scientists are humbled by facts.