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
Of course PHP scales as well as Java. Don't listen to those who don't like PHP. End of story.
Dave Bell
pudding is as good of a building material as tofu..
A computer without Microsoft is like ice cream without ketchup.
Why do 'serious' programmers poo-poo PHP? And why are programmers filled with such zeal for their preferred language and disgust for all others? For people who are supposed to work logically, you'd think they would see that (nearly) all languages have their good and bad points.
Just as irrigation is the lifeblood of the Southwest, lifeblood is the soup of cannibals. -- Jack Handy
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.
I call bullshit.
PHP is a useful language, and it certainly has its place. But for large enterprise applications, it can't hold a candle to J2EE, in terms of speed and scalability. If you drop some serious bank on an application server, you'll know what you're paying for.
Moderators, have mercy.
I thought the shocking revelation would have been "Java scales as well as PHP" under pathologically slanted circumstances.
Yes, but does it run PHP?
From excellent karma to terible karma with a single +5 funny post...
W/o fine grain controls such as managing the persistent connection pool to resources...
No, it's not.
That's not to mention all the other architectual mishaps within the language. You thought perl was bad..
-
ping -f 255.255.255.255 # if only
But given a choice which would you prefer to use.
I've used both, and for database access I would prefer PHP.
New pole option?
Jason
PHP by itself is a superfast scripting engine, both in installation and use. Java on the otherhand requires a lot of setup and maintainance, and usually requires one machine dedicated to hosting its applications. Now tell me how they equally scale?
"...a peek at the architecture beneath both hypes."
Assuming this is a typo, it's the most appropriate one I've ever seen.
Find me in ~/.sig
print "0wn5 j00";
?>
Trolling is a art,
Here comes the flame war
Just as irrigation is the lifeblood of the Southwest, lifeblood is the soup of cannibals. -- Jack Handy
ASP = Ass Sandwich Provider
Take your FUD elsewhere Microsoftie.
This is my sig. There are many like it but this one is mine.
And you are an Anonymous Retard making you qualified to fling your feces...
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
I'll stick with mod_perl and HTML::Embperl, thanks.
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 */
People compare PHP to Java. That isn't PHP's main competitor. The main competitor is ASP and so there fore, a better comparision would actually be between ASP/ASPX and PHP in regards to scalability. Once Mono is feature complete, then compare MS ASPX to Mono, then compare the two to PHP.
Once those comparisons are made, one can then decide whether the superior one is due to either the design/architecture or simply because one is better implemented than the other.
Personally, I find that both have a place depending on what you want to do. That is why there is diversity, because there isn't one product out there that is everything to everyone. Toasters for example all pretty much all the same. There is no difference between the taste of toast cooked in an elcheapo tiffany toaster vs and expensive Sunbeam, it is simply personal taste that dictates what is bought.
We can continue arguing which is superior but deep down inside every person here, things aren't done on technical superiority, it is done because the PHB got his creative juices following when he heard a marketer promote their "solution" over another.
"The difference between pornography and erotica is the lighting" - Woody Allen
Perl seems to scale as well--it runs a very busy site I frequent with few problems.
Have you used PHP?
:'( ) but at least with CF its much easier to connect to a database than with Java, and I've heard argument that PHP is even better than CF.
I program a number of different languages. Java is my first love, and I know it better than any other, but both PHP and ColdFusion do an excellent job at writing very dynamic web sites. I'm not much of a PHP programmer, only becuase its something I do on my spare time, and not for work (we are a macromedia/windows shop unfortunately
Of course in CF, you write custom tags in Java...
Anyway, why write 50 lines of Java when 5 lines of PHP will do?
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
Programmers generally pooh-pooh languages that common folk can understand and use. VB is a very powerful language that many people use to build enterprise class applications, but an idiot can understand and use it as well. The result? "VB SUX". And as an example, a C programmer is essentially a God, and don't even think about reminding people here at Slashdot that Perl has been dead for a few years. But show off something better and easier? Sacrilege.
We just had an ask slashdot discussion about this a while ago. Its kinda weird when you read an article posted on a site about a discussion on the same site... I got nothing....
I already wrote one post in favor of PHP. So here is my post in favor of Java. Don't dismiss Java too easily, it has a lot of libraries for doing things that are more difficult to do in Scripting languages... Anyway I like Java for client side apps, not for applets. I write code on my linux box, and it runs on my MS Laptop and on my Apple Titanium, end of story... The performance boost from C is really neglegable on the client side with computers running as fast as they do today.
Actually they both run on virtual machines. You might know this if you read the article.
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.
so what exactly would you say DOES scale? ASP.NET? Perl maybe?
...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.
Only for web applications. If the argument is that PHP can serve up HTML as fast as Java can, then I imagine he's right. But there's a lot more to the world of programming than shoving out HTML.
Cheers,
Ian
From the PHP manual
I'm not sure what your point is or how you got there. How is maintaining 100,000 libes of PHP any different than 100,000 lines of any other code? The fact that PHP has very much in common with C syntax should make it even easier. But really, what are you, a VB programmer?
do you use Java applications or are you speaking from what youve read, since everything on the internet is true? I actually use a lot of Java apps.
This article doesn't talk about scaling, but about performance. As one poster commented on the article, performance measures how long it takes to process a single request. Scaling is how well it handles many concurrent requests.
Also, the lack of any solid numbers is annoying. The author basically points to various levels of abstraction in the Java model and says "See! This is slowing things down" without any concrete comparison to PHP.
I use both Java (WebObjects) and PHP, and I actually really like both of them. As has been said many times before by sensible people, use the right tool for the right job. For a low-traffic website with a lot of static content and a couple dynamic forms, I'd much rather use PHP. For a huge app with a very large database, I'd rather do something in WebObjects.
PHP performs well, except for the fact that each page hit re-parses the script into executable php "bytecode". Using Zend Optimizer can make this much less of an issue.
However, the other big downside to PHP is that it's difficult to share data at the application level. Session-level storage works well, using $_SESSION variables, but if you want to have some application-wide information, your choices are to either:
* Store it in the database
* Use the filesystem
* Use some 3rd party application-level cache, or roll your own.
The first option leads to, you guessed it, NONSCALABILITY. By making the database the bottleneck, it makes it much more difficult to add extra servers to handle the load.
The second or third option would probably work O.K. but it's not quite as self-contained (or speedy) as using shared Java objects. Also, tacking on 3rd party shared-memory solutions to handle what should be a very simple thing seems, well, tacky.
Disclaimer: I've not used J2EE or JSP, nor do I want to. I'm a WebObjects programmer. Which uses Java. I think a lot of confusion results in people who say "Java" and really mean "JSP".
You drank my drink, you drunk!
I didn't read the article (too lazy), but the synopsys is sadly confused.
Java scales well in the design side - it's a cleaner language and it's easier to develop large systems without losing yourself in a shitload of unmanageable code. PHP, umm, doesn't.
Which scales better in terms of performance depends, of course, on what you're doing. I'm sure there are areas where PHP scales much better than Java. Conversely, in most real-world areas Java probably scales better.
nuff said
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
This is pointless discussion.
.... But even more importantly, PHP is nowhere as MAINTAINABLE as Java, which is just as important ( if not *more* )
You only really have to worry about scaling if you have a HUGE project.
Now if you do have a huge project, PHP doesn't even hold a candle to J2EE due to lack of features like JTA ( distributed transactions ), and all the rack of clustering capabilities of J2EE
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
Back when I was concerned about whether BRL had decent performance, I did a simple benchmark on a 586 Debian box with Apache/php3 vs Apache/Jserv/BRL. PHP could beat BRL if BRL used Sun's JRE, but BRL beat PHP using IBM's JRE. When I switched from Apache/JServ to a Jetty server, BRL totally blew PHP away. I tried again when PHP4 made it into Debian, and surprisingly saw no significant difference.
BRL's architecture is much like JSP, except BRL may be faster on the first request as it compiles a simpler language with no intermediate Java source. I would expect JSP to perform as well against PHP as BRL did, if not better.
The article doesn't ignore horizontal scaling. It scales to over twice the width of my browser.
You can make really big sites with PHP and you can make really big sites with Java, that's the fact. Each has advantages and disadvantages. Use what you want. Personally I use Java and while PHP lacks many facilities that Java has, Java also lacks things that PHP has. I would never look down on someone who uses PHP or any other language, because every language has trade offs. One thing that you get with PHP is a platform that is more tolerant of shitty code, when Java will blow, the PHP server will keep chugging along. With Java you have to use a more rigorous build and testing process, while with PHP you can deploy individual files here and there without too much worry. To me these sorts of consideration are as important, or even more important than distributed transactions, and session sharing. Not every site needs distributed transactions, or CMP or any of the other cool Java things. They are nice to have but they may not be required to make a specific site.
Now, Mozart-oz hasn't had the trial by fire that PHP or Java have had--you won't see it used in a lot of commercial sites-but Mozart does show how the type of applications that folks think could only be done in Java, C# or C++, using an army of programmers can be done by a smaller team. Can it be done? Sure. Will it be done? Well, that depends on the will of the community ultimately.
I personally think this is the type of thing that is key to reducing the complexity of large software systems, but it is a _hard_ problem and will take a while to sort out.
There have been requests for getting some of the key features of Mozart-Oz, namely logic variables, into Python. I include this to show some of the difficulties in the discussion here(i.e. we get a lot of really smart folks that don't come to an obvious consensus on how to proceed here). I'm sure that there are some things that you can do in Java that PHP can't do yet-and some of these deal with needs of key markets like banks. Can those features be added? Well, that seems to be contention of some serious researchers in the field.
Python Logic SIG
Applying Logic Variables to Conventional Languages
The infamous Logic Variable PEP
I like PHP, I'd like to work more with PHP in the future. But until the IBM products that I make my living on are built on PHP, I don't have much choice. Which is not to say that I don't like the Java that IBM is using -- I'm *very* pleased with the course and result of the Java development that we've done in relation to the IBM products that we deal with.
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.
Someone at a company we partner with wrote a web service, part of which made 400+ RMI calls to validate the input on a single (enumerated) field. Yeah, he probably was a former vb guy,and certainly had no clue, but this was in the "Real World", and it made it all the way to release before they noticed it (the staging tiers we all on the same server, the prod tiers were not...)
I'll bite,
Modern Java Runtime Engines (eg: Sun JRE 1.3, and 1.4) do not interpret most of the program. it Compiles the bytecode to machine code, and then executes it.
Some of the lesser used functions, and classes are interpreted. but if a function is used often, it is left in machine code, and never re-compiled again as long as the program is running. giving you code that is just as fast as C.
Look up information on the Sun Hotspot Virtual machine, and then respond.
There are a number of different aspects of scalability. It always starts with performance, which is what we will cover in this article. But it also covers issues such as code maintainability, fault tolerance, and the availability of programming staff.
These are all reasonable issues, and should be covered whenever you are choosing the development platform for any large project. But in order to convey a convincing argument in this small space, I need to reduce the term scalability to its core concern: performance.
I think he's chosen the shittiest option here. Sure, any technology will scale if you throw enough resources behind it. Just keep load balancing and you can make almost anything scale performance-wise.
I think there are a lot of other factors that are much more important. Code maintenance, fault taulerance, etc. are much more important because those can't be fixed by throwing more hardware at it.
J2EE application servers come with transactions, security, resource pooling, and concurrency right out of the box. That's a lot more than I can say for PHP.
Now another thing... he's got his J2EE Architecture completely wrong when it comes to EJB's. With EJB 2.0 (which has been around since 2001), there is no RMI overhead for servlets communicating with Local EJBs. You'd only use a remote EJB if the bean resides on another server.
"A mind is a terrible thing to taste."
Real programmers use Java ey? Real programmers use Java?! the fact Java is not a "real" programming language anyway begs the question.. are you a retard?
At least come up with something constructive against PHP instead of making one of the most insulting comments Ive ever heard against "real" programmers.
Anyway anything PHP is slow at can be fixed simply by codeing up a C module to handle what ever it is thats taking to long.. not many people have bothered to mention this have they.. no its not PHP anymore but PHP gives you that option atleast.
moo
apparently, the folks at JBOSS do think php scales as well as java. of course they have a product to push, but they did use php and found it wouldn't hold up.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
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...
For your information the JCP is working in an interoperability API to script web pages in J2EE using PHP as a language.
This will be available with PHP as a working example, but it will be possible to use qny other scripting language instead.
The scalability/security/transactionality/etc stuff could be handled by the J2EE back-end. It will be just another way of scripting webpages, using PHP instead of JSP.
Check JSR-223 for more information.
Ricardo
In my experience strict typing has little to do with maintenance issues.
I would rate design, proper partitioning, data packaging, code quality, etc. way above strict typing. In fact strict typing typically adds 10% to 20% code bloat to your application. Besides script typing is more for the benefit of the compiler and not the human developer.
Computers are so fast that even very inefficient systems can easily saturate any network connection you could possibly have. All of Microsoft could probably be served from a single laptop by PHP or Java (not so sure about IIS/.NET--there are limits :-) if it was just a question of how quickly scripts get invoked and can pump out data.
What makes web applications slow is database and file system access. So, no matter what language you use, you primarily have to worry about the scalability of your storage and database component.
The major difference between PHP and Java is how they scale in terms of programming effort and complexity. PHP is great for projects of small to medium sized complexity, but not so good for anything really large. Java, on the other hand, is equally bad for everything: it's tedious to use for small projects and it's better than PHP for large projects, but that isn't saying much.
s/do think/don't think/
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Compare JSP and PHP if you want, but to compare a platform to a scripting language is pointless.
The sad reality is that so few developers know enough to fully exploit J2EE that they wind up doing little more than what PHP does better in the first place.
Never pet a burning dog.
In a lot of applications horizontal scaling is much more important than vertical scaling.
I cannot believe an article that talks about scalability simply just "ignores" horizontal scaling.
LOL. More FUD from an Anonymous loser... I'm so hurt :)
This is my sig. There are many like it but this one is mine.
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.
hey! thats cool. I did not know that. does that mean a function as in a function() as part of a class or by function do you mean like more generic like an entire class file or large chunks of an application?
Wow man. that was a very good troll.
I had a whole big flame reply written and had the mouse pointer over the submit button, and was previewing one last time before I realized that it had to be a troll.
If you hadn't talked about writing Doom in VB, I think you had me, although the thing about the regexes should have been an instant give away
I used to code in Perl, Cold Fusion, and VBScript (ASP) back in the days that scripting was all the craze. I used to love (believe it or not) working with Cold Fusion. I could create a web application so quickly, and it had features like connection pooling, session management, and application management right out of the box (and this was 5 years ago).
Once clients started demanding "web applications", as opposed to basically static web pages with a little DB interaction, I quickly realized how no scripting solution would scale elegantly. Most people (at the time) would scoff at the idea of writing even a 10K line of code app with Perl/TK, why did we do the same with web apps?
I think the number one reason that scripting sucks for application development of any sort is it's lack of strict typing. This makes it difficult to implement a clean OO design, and it also makes it harder to code IMHO. Sure, there's the extra step of compiling, but that actually helps me track bugs in my code down quicker. Even for small projects I hesitate to use a scripting language because you never know what part of that project you'll want to reuse, or if that project will grow in the future.
So, while most of my resume contains scripting experience, I would have to say that my life as a "web developer" is much better now that I'm working with C# and Java.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
The problem is not Java's or PHP's scalability in terms of performance. If there is a problem, people write a better compiler, a better database, buy a faster server or buy more servers. Pocket change for web sites with millions of transactions per day.
The problem is that Java, being a general-purpose, modern programming language, can be used to write understandable and secure code for very complex problems. And PHP, well, is not. Maybe you don't have an application that can be most cleanly implemented as a 5-tier architecture. But if you think you might in future, you don't want to start writting it in PHP. Not the logic portion at least.
A lot of technologies - OO, EJB, relational data design - can seem useless and overcomplicated until one encounters a problem that is complicated. Maybe one of these days I will understand what inspires people to use XML, with schema and style sheets to communicate between their own client and server. Rather than using a nice binary RPC implementation, for example. But then maybe this is one example of a bad technology.
On the other hand, you can still open database connections directly from JSP and combine ease of use of PHP with security of PHP. At least you can still call functions from your class library for connection pooling and input validation.
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.
I code PHP at work & Java Servlets at home. The reason I'm useing Servlets for my at home project is that I can leave a thread running in the background to do any database writes after the page is returned. It may not actually be any faster, but it sure seems that way to the user.
Automatic conversion is weak typing in my book. Do you know some "everything is a string" language out there that doesn't internally convert strings to numbers when doing math? Just leaves everything the same type? If PHP isn't weak typed, what is?
This exact post is in every PHP/JAVA story on /., all the links are usually broken, and the writer is an idiot.
Java was written in C as well. Java compiles directly to machine byte-code on load (which happens once per class, which means only once per jsp file just like PHP).
My real question is how does this troll keep getting modded up?
Just for your information, I had to switch from PHP to Java because PHP was impossible to maintain.
Karma Clown
Articles like this are totally subjective and always boil down to what one person likes or how much they know about their pet technology.
What I don't see here is an objective comparison of how many $$ or how many lines of code it takes in one or the other. You can wave your hands around all you want in a passionate argument about architectural 'grace', but I remain unconvinced until I see the code, and the person-hours.
It all drives me crazy, because our clients see these little religious wars and it drives down their level of confidence in us as professionals. I build something in Java/PHP, and some other contractor says 'I could do that better (faster,stronger) in PHP/Java'. In the eyes of our clients, we're both idiots when we do that.
At least in Civil Engineering they can do hardness and durability tests on different recipes of concrete. Maybe I should have done that.
"... as is every other programming langauge."
As is the English "langauge", eh?
Really good joke that one, you almost got me up until point #3 where I realised you were being sarcastic. The data structures thing really took it too far though dude....
#include <sig.h>
.... Someone Had to Say It:
Your application's Scalability is directly proportional to the number of well used neurons by the application's programmer and the sysadmin.
Java has nothing to do with you being stupid or smart, neither does php.
On the other hand, Sun has a lot to do with the fact that most ITManagers are brain dead trolls that drool over whatever the um... 'leaders' of the technology revolution of the 'Internet' tell then.
NO SIG
The PHP Scalability Myth
... two only slightly related topics.
.Net/C# and Java/C++ performance.
... or PHP in a typical PHP engine, lacks the JVM :-) In a Servlet engine every request knows about all request made by the same session before. So all objects ever created by the same session reside side by side in memory until the session times out or they get removed.
... as you can not reliable isolate parallel requests, except via the DB.
The author should focus on PHP and what got improved there over the last years and not take an inocent other language into the dispute.
Comparing PHP with Java is not like comparing Apples and Oranges, as both are fruits, but like comparing Cheese with Bread
What is Scalability?
I dissagree with the author. Scaleability means: if I have a solution, and throw twice the problem (more requests, more data) on it, does it *only* need 100% more resources? Can I extend that by throwing 3 times, 4 times and so on the solution? Where is the point where the solution breaks? When I have it working on a problem ten times the original size? Or can it take 100 times the original size?
Language and Database Performance
Java performs as nice and well as a compiled language like C++. At least under Windows it beats both borland C++ and Visual C++, sometimes by a rather hughe factor. Hint: www.heise.de/ct latest articels about
Database connectivity is not really an issue if you compare "languages".
Comparing Architectures
The way you define an architecture is not the problem in a PHP vs. Java comparision. In PHP you can not keep objects in memory between different web acesses. You have to save the context allways in the DB. In Java you could use a prevalent system, or files, and cash all objects in memory.
The claimed RMI overhead in a Java N-Tier application only exists if you have each Tier on a different server. And then you have the SAME problem in PHP as well. The author points that out a bit late.
Stateful and Stateless Architecture
Nothing much to say here. IMHO an external session store is no real issue. The issue is keeping INTERNAL session state over several requests. To be able not to relly on the DB.
The Convergence of Web Application Architecture
I dont see the convergence. Where does PHP have something similar to container managed persistance for entity beans?
Where does PHP have something similar to container managed transactions and container managed access rights and role managemnt on method level for clients interacting with session beans?
Not at all.
If PHP on top of Java is scalable, then why isn't PHP on top of C?
Because PHP on C
In PHP my previous requests need to know which requests likel will come later. And they have to prepare that by storing all relevant data further requests might need in a DB. Basicly: all PHP applications are only DB frontends used via the web. The simply contain only out of three kinds of statements: html formatting, sql select and sql update statements.
True business logic is impossible in PHP
You can hardly reuse PHP on the business logic level as you are far to strong tied to the DB you had in your initial design.
You can not deploy "components" on different servers with differnt back ends and different configurations for the accessing front ends.
Sure: there is a class of applications for which PHP perfectly suits. But the classes of applications for which Java suits and PHP not, is much bigger.
PHP is only suiteable if you can write the application very monolitic. Java suits well when you can divide the Application up into individual components which get assembled and deployed later to form the application.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
At least with the Apache 1 model, every process is going to have a connection open whether it's serving a page that will use it or not, so it's essentially wasted. You don't have this problem with connection pools.
How do PHP persistent connections work in the Apache 2 model, I'd like to know? Hopefully it's a connection pool behind the scenes.
Heh. I'm not even sure where to start critiquing this one. But I'll give it a shot.
First off, PHP is an interpreted language. JSP is compiled on the first request. It doesn't matter that the PHP interpreter is written in C, it's still interpreted. JSP classes, after compilation, run as native Java classes, which as another poster noted, are often compiled to machine code in modern JVMs. PHP has no advantage here, at least not based on your argument.
Your benchmark links are all broken, so I can't evaluate your claims on that front.
And of course Java is just another language. So is PHP. So is C. What makes Java so useful is the included libraries that make it incredibly simple to rapidly develop network-aware applications. They've all got their place. And it usually comes down to a matter of preference, not performance.
The development world would be a better place without opinions like yours. I'm a professional Java developer, but I choose to use PHP in my own side businesses. They both have their place, and I like them both. Performance is fast on both technologies, regardless of your ill-informed claims. I strongly suspect that you are basing your comments on your experience with only one of the two technologies you're trying to compare, supplemented by unsubstantiated claims you've heard about Java. Use both languages extensively for awhile and you won't be as uninformed.
-j
Then use Jetty.
Yeah... Perl lets you do C modules too, it's one of the nicer features of the scripting languages. Another cool thing is you can run external programs you've developed elsewhere to offload parts of your task. So let's say you've got something really horrible and complicated, which could best be done using OOP techniques. No problem; use the Perl or PHP script as a frontend, and call an object oriented program from within the script, passing in the data in one of a few ways. Then you get all the benefit of object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language, etc, but you also get to work with scripting. I'm pretty sure doing something like that is at best nontrivial in Java. If it's possible at all.
Although I lean towards Perl, personally, I've heard only good things about PHP. Looks interesting!
Farewell! It's been a fine buncha years!
Show me a PHP application that uses session data that can scale to more than one machine, without hitting a database to re-load your session data on every request.
Any half-decent Java app server will do that sort of thing without requiring any supporting code.
very clever
Just ran a quick line count on our dev server and got back 87,501 lines of code. Up until a month ago I was the sole developer for 3 years.
Oh, and I'm our senior Linux admin as well. So I got to do those duties as well. Joy joy.
I don't think strict typing has anything to do with it. Java development scales well because of projects like struts which let you seperate the layers of the project across different departments.
In PHP and Python I'm absolutely certain a single developer can handle more lines of code than in Java. The languages are just so much easier to work with. But Java's design does make it easier to have multiple people working on the same project.
Scalability, maintainability, and performance are derived from a factor much more important than the choice of language/platform, and that is the developers who are creating the site/application.
PHP, mod_perl and ASP projects can turn into unmaintainable morasses quite easily if the coders aren't careful, but Guess What? So can JSP and ASP.NET!!!
The most royal piece of sh*t intranet site I've ever seen was a JSP-based one done by a series of contractors. It was nice'n OO, alright, but this didn't help at all. There was absolutely no consistency in the 'design', they were failing to close recordsets, they weren't using stringbuffers appropriately, business rules in page-level code, etc. It wasn't unusual for users to have to wait 30+ seconds for responses. Thank Buddha that they weren't using EJBs! Happily, it was salvagable w/ many corrections and much refactoring.
This isn't a slam against JSP. JSP can be beautiful and offers great performance when done well. But so can PHP, classic ASP, ASP.NET and mod_perl! Well, maybe not classic ASP! ;)
What really counts is the developers who are working on the project. The knowledge, experience and self-discipline of the developers will always count for far more than choice of platform.
If a company wants a fast and reliable website/web-app then the choice of using JSP, PHP, ASP.NET or mod_perl is pretty much a no-brainer... just go w/ whatever will most closely fit with the technologies you are already using and/or the tech that the company would most like to support/have supported and make damned sure that the developers are up to speed. Using the cheapest generic clods that you can find is a sure recipie for failure.
The only thing that we learn from history is that nobody learns anything from history.
Whew. Some of us have been experiencing this. It's nice to see some data to back up what I've been living through.
My Greasemonkey scripts for Digg &
PHP is great! It serves up pages even during a /. attack... It even serves up the "MySQL died" type pages rather well.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Scaling != performance
...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 ?
That's why he spends a lot of the article talking about architectures rather than individual machine performance - it's architecture that's key to scalability. The article is right on in this regard.
DB is the bottleneck for most websites... Java did considerably better than PHP in terms of both
This may well be true (though I haven't looked at benchmarks lately). Still, it isn't a problem inherent to script languages - just something to be fixed.
The point of doing it in C is to do it well (and it's really not hard, I do this fairly regularly). Neither Java nor PHP is a good language to do image processing in. Either may perform acceptibly, but they're just not as good at it as C. And there is nothing wrong with mixing languages in this fashion when the relative strengths are so disparate.
In any case, most developers are going to be using an opaque third party tool for charts, and the calling language (if it's even being called by something on the server at all) is going to be irrelevant.
Using a tool for web development doesn't mean it needs to be the only tool in the process. If my PHP database connector is written in C, it's not like the system suffers some horrible everything-is-not-the-same meltdown.
Basically, the article was on target: in the architecture shown, the differences between a scripting language, Java, or even CGI needn't affect horizontal scalability - and this (and database scalability of course) are the only things that matter in the end.
In terms of server counts required, we're back to a straight performance question - and that's another article.
Let's not stir that bag of worms...
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.
I have never found that lack of strict typing damages maintainability.
Besides, 100,000 lines of PHP, Perl, or Python probably does the equivalent of 1,000,000 lines of Java, so it's not a good comparison in the first place.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Many people just keep saying "Java scales better". However, for small (and even mid-sized) projects, Java's overhead is just unacceptable, and you end up using a BFG-9000 to kill an ant.
I may agree that PHP code is sometimes terrible to maintain, but one has to understand that Java can be a PITA too. Many PHP coders don't even try to make their code at least well-organized, embedding whole queries and stuff like that inside the HTML code. That could be easily replaced by a template system, but it takes more time, so they just do things the fastest (and dirtiest) way.
I oversee a team of web developers and administer a production and development linux network for them, and there is no question that we use php over jsp. Anytime they're designing from scratch and we know something will need scalability, they go with php. I can only provide insight from a systems administration point of view. For small projects, it really doesn't matter, but every JSP project I've seen go from small to big has ended up running slowly and poorly.
JSP is what has always forced me to get bigger hardware, never php. We have some php guys, and some jsp guys, and many that do both. Obviously it's hard to get a good reading as to which is easier to scale, as everyone is biased... but from what I gather, JSP is slightly easier to scale from a coding perspective. With only a marginal difference, I (and my development team) favor PHP for new projects as JSP tends to give us headaches while php runs quickly and quietly.
I'm sure others agree, I'd love to talk to a linux admin for Friendster and see how much he likes JSP....
People seem to forget that it's not scalability, or even performance in general, that limits the reach of PHP-type languages compared to Java. It's the enterprise libraries, programming conventions and built-in features of Java (security features, strict implementation of OO style and type checking) that make it enterprise. PHP does NOT have the architecture, design patterns and frameworks to support complex, MAINTAINABLE design for big apps. I use both, Java in the office and PHP for my own web programming.
Frankly, I wouldn't dream of trying to write the banking software I build in PHP... what a nightmare! People need to learn that the issue isn't one of quality, but of targeted useability. PHP and Perl have their uses, it's just not enterprise software. I mean, hate it as I might, C#/.NET is an actual competitor to Java in that area, but PHP/Perl will never be.
If I have to explain how an insult creates FUD in a social network then you are more stupid than I originally thought.
Never under estimate the LOW IQ of an anonymous bastard.
This is my sig. There are many like it but this one is mine.
Not to jump into your guys' troll fest here but I thought I would point out for info that passing off processing to other langauges/runtimes/etc is pretty easy in Java.
:-)
You can simply use native calls or invoke another process (you can call any executable from within Java). Native calls allow you to directly call into other compiled languages (I've usually seen C as that other compiled language). Additionally, you can invoke any executable, passing input just like a command line and reading output just like a command line.
Although I will say that I think your point is rather moot since you argue that you can pass off processing to get the benefits of "object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language" from a scripting language, but you pretty much have all that in Java already, so there would be no need to do so from Java. You would need another compelling reason to pass of processing in order to make your argument. So the fact that you could or could not invoke other processes or hand off processing doesn't really matter from Java.
Anyway, please continue, sorry for the intrusion....
Forget it. He's just a Microsoftie that can't support his argument with anything intelligent. Flush him along with the rest of the floaters.
This is my sig. There are many like it but this one is mine.
... Java scales?
Sticking feathers up your butt does not make you a chicken - Tyler Durden
My point is, however, that the ease-of-use directly affects scalability. Assuming that both Java and PHP were equally scalable....the issue then falls to how easy it is to get there. Does it become an education thing? Or does it become an ease-of-use thing?
I'll admit, I know nothing of Java. Never tried. So I can't honestly say that one language is easier than the other. Maybe Java is easier than PHP? If so....maybe that's why Java seems more scalable.
Over at the ServerSide
I beg your pardon, but I'm not trolling. I was making a totally serious comment. I know it's traditional slashdot etiquette to label all opinions you disagree with as "trolling" but let's keep a civil conversation civil, ok?
Ok, having said that, I was under the impression that you had to take a couple of extra steps in Java to run an external program, mostly due to its sandbox approach to security. I.E. that it was doable, but slightly more complicated than it is in a scripting language.
Why you might want to do it in a scripting language is obvious; compiled code is very fast, features you might want are supplied in your compiled language but not your scripting language, and you might want to do something complex which would be helped by an OOP approach. Also, if you build your external apps well, you can access them from code you'll write in the future, not just from the script you're writing right now (kinda like web services, eh?).
Since you mentioned it, you might want to do it from Java because you might want to benefit from using REALLY compiled code rather than JIT compiled code. A JIT compiler compiles each class as it hits it. So unless you have a prep app which touches each class at least once, your stuff is going to be compiled on the fly for at least some of your users. Thus slower than a completely precompiled app. Of course, you won't find this compelling, because is it? I don't know. Maybe not. But it's a possible reason for using external modules, etc...
ANYWAY, my point was that scripts can get a performance and development benefit from using external modules, and that I think that's kinda neat. Useful. Not really related to script vs. Java, but sort of interesting in a tangential way.
Farewell! It's been a fine buncha years!
Sorry, suckah ...
As a disclaimer, I am a big fan of PHP, but PHP is as much of an object oriented language as C is ... which it's not.
It pretends to be and is wrapped up to be convincingly well enough (and quite usefully) in some regards, but really .. it's not ...
Java isn't even completely Object Oriented ... with chars and ints and what not ... now SmallTalk .. that's pure baby ..
"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.
Java sucks. SUN is dying, McNealy is driving it straight into hell. Its too bad really.
At least in Java, it's very simple to set a whole site up to use UTF-8 all over once and for all, and thanks to the native support for unicode throughout the language everything just works, automatically.
I can't remember seeing a single PHP app that handled multiple languages in any was even closely resembling sane.
...From the end user experience, I'll be the first to say Java is a festering piece of shit. Every time I've had to run a Java based applet in a browser or (god forbid) over an X session, it's been ungodly slow! Java DOESN'T scale well if you are talking performance. And now the company I work for is moving to a Java based client application for a big database we have. The bandwidth alone is going to gobble up our network when our 2000+ users all come in in the morning an launch the app. Java Sucks. If you can keep this shit all on the backend with PHP, more power to you.
I try to be fu
I hate it when people talk about "CGI model vs. in-process model" or whatever. Even if your interpreter (PHP, Perl, JSP, etc) is running "in-process", you're still using CGI (assuming that the user is sending data).
CGI is not about how the web server interacts with your program - it is how the web browser sends data to the server.
If you've got something like: http://mysite.org/foo.php?key=value
You are using CGI! Sorry, just one of my pet peeves.
where does Yahoo run PHP? I believe they use Python quite a bit.
And Python, with mod_python or maybe Twisted, can probably scale much better than PHP.
I had a serious case of PHP scales once; I thought it was a rare disease, but now I see it's being given exposure in respected news sites like Slashdot. Word to the wise: cortisone cream gets rid of it. Worked for me!
Standing at the very edge of my imagination, I peered into the inky void and realised -- I couldn't think up a new sig.
That'd be the definition of linear scaling. Scaling can apply to n, .5n, or other rates. So, saying X and Y scale at the same rate could they both scale at 0 (ie, adding machines have no effect).
:-)
You are of course right.
However, everyone uses the phrase "it scales" without further adornment to mean "it scales linearly and with a factor of not much less than 1.0". That's just us humans taking sensible linguistic shortcuts.
On a more academic front, there are two separate issues to consider, the first being linearity (the scaling factor not dropping off as you increase N, ie. overall throughput remaining on the straight line), and the second being the value of the scaling factor, as you point out. They're both important in practice, simply because in the real world it's not just scalability that matters but also absolute performance and efficient resource utilitization as well.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
I think that you make an excellent point, but with a caveat: the tools do not make the developer.
I am in the midst of rewriting a PHP app. Why am I rewriting it? Because you are absolutely right: the original PHP app was impossible to maintain. However, the new app is being written based on the lessons learned in the first and is being built using OO principles from the authentication to the page output to the form input. This new app will be maintainable and also extendible.
They are both PHP apps, it's just that one was written well and the other wasn't.
You can write good C code and bad C code, good Java code and bad Java code. PHP deserves special recognition though: it's really tempting to write unmaintainable code.
HBH
"Smart is sexy." -- D. Scully ("War of the Coprophages")
After reading all the comments, it's clear that everyone thinks they know the right way to do things... and I thought it was only guitar players.
Almost all (if not all) of freshmeat.net's pages rely on the database, as that is where all of the project content is stored. It's written in PHP. I believe there may be some sort of cache in between at least some of the public pages and the Internet, but I'm not sure. We get a few hits now and then.
This is especially true for applications like a search engine, where it's difficult to implement them without hitting the database multiple times.
WMBC freeform/independent online radio.
Especially when you can get it for free linux virtual server. Yes you could pass along all your values in hidden form fields. But then you could also write a C++ compiler in cobol.
Still not convinced? Consider JSR 223, the effort to turn PHP into the front end for J2EE by porting it to Java. If PHP on top of Java is scalable, then why isn't PHP on top of C?
...I had a hard time figuring out if this was a joke article or not.
Language syntax does not count for much, nowadays since everyone has everyone elses best features. Library and runtime is what really counts. That's the point behind JSR223, and even .NET to a large extent. They've realized that in the end, it's all bytecode anyway. If the author doesn't understand that, well I dunno.
It has absolutely nothing to do with scaling.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Progress always seems anti-social to those being passed. :)
This is my sig. There are many like it but this one is mine.
This whole PHP/Java fight is getting simply ridiculous. Isn't it about time that it stopped? If you think PHP will do the job then use PHP, if you think Java will do the job the use Java. You'll see soon enough if you were right in your conclusions.
Both have their strong points and weaknesses, just like assembly, which makes for some extremely fast code and is good for stuff like drivers but tends to take a bit longer when you're writing your webserver in it.
Having read a lot of the posts with their information and misinformation on this topic I think it is safe to say that there are idiots on both sides of the fence. A buddy of mine mentioned that maybe someone should implement the infamous pet store application in an attempt to show that PHP can scale to a large degree. That has been the best idea I have heard.
You never saw a fish on the wall with its mouth shut.
Sorry but I can't perform miracles. Try reading a book on it. You can find them at your local library. :)
This is my sig. There are many like it but this one is mine.
because you could always break the type abstraction.
You can do so in the Java language as well: serialize an object to a byte array, modify the byte array, and deserialize the objects.
A warning does not a type system make.
-Werror anybody? (-Werror is a GCC flag that treats C warnings as errors.)
Will I retire or break 10K?
Couldn't have said it better msyelf. Very well stated, :-)
we are all one consciousness experiencing itself subjectively - bill hicks
I'm a fairly advanced PHP developer and use things like Open Mosix to afford SMP to apache and my php-daemons.
I have used PHP to create stand alone services utlizing TCP/IP over SSH tunnels to create distributed networks, multi-user environments, supply real-time XML data and provide database synching across networks as well.
It comes down to the coding I think.
Out of the box, PHP is probably not as scalable as Java for several things beyond a simple web-store or blog.
But, if you go the route I did and spend several months creating a custom object architecture, you'll find many ways to pull the proverbial rabbit out of the hat and afford enterprise class solutions with a lowly scripting language.
Java is great, and I intend to use it more due to market demand. But, I get lots of interest in my library and have used it in production in 3 services so far in the year since it hit 1.0. Perhaps it's time I did a code review and posted to sourceforge, an object architecture that supported portals and daemons out of the box could be useful even in th face of PEAR and PHPNuke.
wow, that was really an entertaining read!
Aren't all characters in PHP 8 bits? What about internationalization?
Ask Google and you shall receive. PHP seems to support UTF-8, and the developers hope to have more extensive internationalization ready by version 5.0.
Will I retire or break 10K?
at least this jackass puts her name to the comments.
--- P,L,G
Nope. I call that telling you to educate yourself.
This is my sig. There are many like it but this one is mine.
i have seen unmaintable perl, php, asp and yes jsp code ... where do i do my GOF work with php?
for everyone who replied like I was serious (which I'm not), and the mods who modded me "flamebait" it was a joke, check my user name...:P
Heh. Now you beg? This is getting amusing. :)
This is my sig. There are many like it but this one is mine.
What a unique opinion..anyway you wrote..
You have no clue what enterprise class means. I am a developer for a fortune 500 company with 110,000+ employees.
I work for an Ivy league medical college, and the application that is used to track all of the medical students in the US is written in VB. Plus the hospital we are affilliated with writes some apps in VB also. Maybe you don't use VB for large apps, but that doesn't mean no one does.
Personally, I like VB but I work with Java. It is a waste of bandwith to write posts flaming away at people and personally attacking them based on your own personal preferences. Yet that is half the posts on slashdot. Yes I know, I must be new here. (here comes the guy with the "new here" handle).
or can't comprehend...
Heh. This is hilarious. What 3rd grade tactic are you going to use next?
This is my sig. There are many like it but this one is mine.
Obviously you are referring to VB6 and earlier and not VB.Net, which is a true object-oriented language (with the same lame syntax) so I won't go into any more of that.
I am a developer for a fortune 500 company with 110,000+ employees.
That means absolutely nothing in terms of credibility-- Fortune 500 companies do hire idiots, too.
However, many "enterprise" applications consist of a simple program running on the client (like a VB program) and all it's doing is transferring data to and from a back end database. You don't NEED a powerful language on the client side, if all of the magic is done with stored procedures and you're just displaying it.
But being from a Fortune 500 company with 110,000+ employees, you probably knew that.
running perl can handle the load that many other sites out there just crock on
Maybe it has something to do with the fact that Slashdot is hosted on 8 load balanced web servers (3 of which are dedicated to images). And you're comparing slashdot's ability to handle load compared to some dinky little server that gets slashdotted easily? I've got news for you... even cgi/perl boxes get slashdotted. It's all about the hardware. Sorry.
Thats part of the problem right there. If you dumb down a language too much such as VB, you loose all the power features that comes with a language such as C, C++. It also contributes to all the headaches in the world of IT when you have tons of piss poor code written by sup-par "programmers" that cannont grasp anything harder then VB. 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.
You are obviously an intern, or fresh out of school, and haven't had a lot of real world work experience yet.
Yes, VB makes it easy to write bad code that still somehow manages to work. Many languages do. Believe it or not, it is possible to be a GOOD programmer and write in VB.
If you were a real programmer, you would know that good programming is about HOW you use a language vs. whether you use it, because often you simply don't have a choice in the matter (unfortunately).
Here are some reasons Slashdot runs so fast compared to some other dynamic web sites:
No, I can't think of any more reasons directly related to Perl features.
Will I retire or break 10K?
Basically they say that Resin isn't that fast. I think this has started with Tomcat 4.
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.
Well, I have seen a bit of Java the last four years, and can tell you two things:
1.- To check the performance of things you have to _measure_ and not _guess_. Words from the gurus out there, not mine. If you have not seen a system like the one you describe with java (I have mounted two quite more complex at the time of this writing) you just don't know. You are guessing.
2.- I don't know PHP (beyond the basics, that is) but with the description that you give, Java can do the job quite well. And
Sorry, but java is being used in quite big systems out there. It scales well. What you have to prove is that PHP scales BETTER.
Actually, a forced cast will let you do that in most circumstances. Of course, that's exactly why you don't cast if you don't need to. People who ignore their compilers generally make life hard for the rest of us.
Javascript + Nintendo DSi = DSiCade
So basically Yahoo! are moving from an interpreted language written in C, to an interpreted language written in C. Woo hoo.
A major web site with millions of viewers is moving from a proprietary framework to a commodity framework. This shows how mature this particular commodity framework is.
Will I retire or break 10K?
Ah... yep. That was the other 3rd grade tactic I was waiting for.
This is my sig. There are many like it but this one is mine.
If Unicode is dead, what else should one use? What widely used character encoding, other than a popular Unicode encoding, supports English, Japanese, Hebrew, Arabic, Korean, Russian (Cyrillic script), Hindi (Devanagari script), and Greek?
Will I retire or break 10K?
It's too bad the Slash Mods have such God damn THIN SKIN, they can't see a reasonable comment when it is not consistent with their own myopic opinion. I'll take the "flamebait" as a badge of honor.
I'd say anyone working for a 'true' enterprise doesn't need an article to tell them what's best; otherwise, they're in trouble already. I'll also note I've seen plenty of things I might classify "enterprises" using ASP as a primary language.
First, don't go counting PHP's compile time. If you're balancing across several servers, you're paying for the Zend Optimizer, and you've got code precompiled and parsed, and optimized. When I converted my ~30k line project to encoded, CPU use fell by 30-50%.
Second, unless you're absolutely gluttonous, then session data is not an incredibly significant thing to store in the db. You're working off a single key with a chunk of data, you're keeping the table small with constant GC checks... it's possible that using the db is faster than using the disk-based caching. And note you can split off the session data to a separate db; there's not significant overhead forming connections because you can use persistent connections that stick around through many pageviews.
I have a high volume site I've worked with to split their e-commerce app across servers. Session data is handled via the db; it is ready to be split off to a separate db as needed. Most data is read-based and not very time sensitive (people looking up items, searching for items, generating dynamic pricing data based on sales and so forth), and this balances easily across many servers.
One thing I'm quite sure of is that your design skills count more than the technology in PHP vs Java. One wrong query, one bad decision about caching, and you're wrecking your performance. If one looked at 99% of the apps out there, they'd benefit 5x as much from optimizing the application logic as compared to 'switching languages', regardless of which has the edge. So I view the whole discussion as a red herring; if you're Amazon.com, or the FTC, maybe you need to solve this question. Otherwise, it is unlikely.
For me, this article is all about the PHBs. In my experience, most of the web applications I've seen could be built quickly, cheaply, and reliably using PHP (or perl for that matter). But the PHBs get all caught up on "scalability" and "extensibility" and "portability" and "promotability" and "budgetability" and "sexappealability" and "studability" and think they have to plan for everyone in the world accessing every feature of the application at the same time, from two different computers.
The end result is a project that costs three times as much, takes twice as long, is half as reliable, and barely works.
This is not true for all projects in the world, and of course YOUR project is far too complex to be done in a scripting language, but in my experience 100% of the non-PHP web applications I've worked on (in largish teams, so it's not all due to my incompetence) would have been better delivered using PHP. And 100% of the web applications I've built using PHP have been unqualified successes.
He looked at me and said, "Kid, we don't like your kind, and we're gonna send your fingerprints off to Washington."
http://www.odi.ch/prog/design/php/index.php
I wrote that independetly.
The only problems I've ever had with Runtime.exec() is when the underlying process outputs to stdout and/or stderr, fills up the buffer, and blocks. That can be avoided by draining stdout/stderr, using a background thread if necessary.
If you want to code in a crappy, hacked language like PHP, then do it. I'll stick to the language with some semblance of design behind it. :-)
(Also I get the feeling that if your PHP app consists of 100 source files, then the interpreter has to parse all of them every single request. Do you have to do that in Java? Nope.)
Karma: It's all a bunch of tree-huggin' hippy crap!
Zope gets surprisingly little mention in these sorts of discussions. Zope has...
/sites/clienta AND /sites/clientb). So you can have the same codebase running two sites without setting up a seperate server.
* a persistant enterprise level object database, that handles a distributed backend completely transparently (so you dont have to use nasty hacks like hidden variables to store state data. The session data can store key-value pairs of any python object, and is duplicated across multiple servers using ZEO)
* Zope Page Templates
Possibly the best templating language in existance, ZPT fullfills everything you need for your presentation layer.
* Python Scripting
Zope supports python scripts and python products. Scripts are stored inside the ZODB and are generally used to help process data for page templates.
Python Products are where the meat of the processing happens. This is where you define your classes. Each class can be instantiated multiple time into the ZODB (i.e.
* CMF and Plone
Two out-of-the-box products available for Zope, CMF and Plone are probably the most powerfull content management systems known to man. You can extend these to your hearts content- I've created systems for under $1000 that were estimated at $50,000 by a J2EE development firm. I've consistantly been able to duplicate a weeks worth of J2EE in about a day of Zope.
I havn't even began to touch the full power of zope. It's really such an extreme difference in philosophy to J2EE or PHP design models that you need to experience it for yourself.
PHP is awsome, and from what i've seen of presentations regarding PHP5, scalability is not the only thing in common, but so is public,private,protected types, exceptions (try & catch), and other things that for now have been the domain of Java or C++...
When php5 comes out i believe i'll start to dabble in it again. Php is an awsome language and i believe the future will be built around interpretive langauges.
By the looks of php5 (following link) it has a great future!
take a look at this
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
heh, gee:
perl -i -pe 's/\sEmma\s/Emma(R)/g;' *.php
Nicolas Mendoza
Prepare for MSIE 7
But here's the thing with Perl. Alot of times the code is unreadable after say... a week. Even commented code can be a mess. PHP *can be* unreadable and messy, but most of the time you can clean it up enough to still figure out how something works. PHP fills that niche of being easy to learn, simple to writea and good for beginner programmers. When I want to use a non-web interface, I choose Python for it's powerful, yet simple syntax, which is similar to PHP in many ways.
I think you mean value object instead of view object. Value Object is actually one of the design patterns that's expected fot this sort of use.
http://www.google.com/search?q=php+yahoo
EXCELLENT POINT. If only I had the modpoints... :(
creation science book
What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.....PHP is perfect for small projects, but when you have huge....
The static typing versus static or "loose" typing Holy War has been going on for ages. I think it has more to do with development style and personal preference.
Anyhow, you are not going to settle it in 20 messages. Software people have spent years debating this topic in every programming forum I have ever seen and still don't agree.
Personally I dig dynamic typing. It allows one to view large applications as multiple smaller applications and keeps the code simpler and closer to pseudocode IMO.
Table-ized A.I.
But we are all supposed to be using C++ and Object Oriented programming, and the Microsoft OO framework is this abomination called MFC (I am beginning to sound like the 2nd and 3rd Dune novels. Abomination! Abomination!). The dudes at Microsoft had trouble programming cleanly in C, and turn them lose in C++? MFC is this ugly mess of typedefs, macros, classes, templates, AND wizard-generated code. Abomination!
If you want to pound out a quick GUI program, you are much better off in VB 6 than to wade through MFC. All of the Windows stuff, including support for COM objects is designed into the language rather than (Abomination!) the way it is in MFC. I would just as soon use the Borland languages (I use Delphi -- I am told C++ Builder is pretty much the same) to generate COM and ActiveX objects and then use them from VB 6.
So don't blame the wanna-be programmers for not understanding C++ and being lazy and using VB 6. Blame Microsoft for not knowing how to program in C++ to develop a usable framework for it.
One good news is that Zope is implemented with Python, C and GDB - I think it would work several times slower would ALL THAT ZOPE FUNCTIONALITY be implemented on Java or PHP.
Another good news is that there is ZEO (Zope Enterprise Object) which lets you to have several load-balanced Zope web servers sharing several replicated ZODB instances.
PHP developers can only dream about such functionality as ZEO brings for web-clusters. Well, with Java you can have the same, but the price will be really very high: Java Application Servers will not work (even start) on a hardware you can run Zope (in terms of memory and CPU requirements). And, aside of JBoss, you have to pay gold for the commercial software license.
However, I agree, there is certainly a lack of Zope benchmarks and performance tuning guides and that makes bad for Zope marketing. Personally, I think that this lack of performance documents is a big strategic mistakes of Zope Corporations.
Less is more !
I just took a look at freshemeat.net and it looks like there are at least 9 images on the front page. I would guess that means 9 HTTP requests where the database connection was not used and 1 where it was used.
And Amazon is using Mason/Perl/mod_perl/Apache. Methinksts they know something about scaling.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
THAT'S one good reason to use XML between your own processes, rather than in in-memory data structure and/or RPC. Mgt. is often former COBOLers used to archaic mainframe style processing of many simplistic programs dumping into many many temp files. It's the architecture they know. XML sucks much less than many file formats, but files aren't always the best way to join tasks / processes, as you seem to be "hinting" at.
Yow! I'm supposed to have a plan?
Comment removed based on user account deletion