Slashdot Mirror
On PHP and Scaling
jpkunst writes "Chris Shiflett at oreillynet.com summarizes (with lots of links) a discussion about scalability, brought about by Friendster's move from Java to PHP. Chris argues that PHP scales well, because it fits into the Web's fundamental architecture. 'I think PHP scales well because Apache scales well because the Web scales well. PHP doesn't try to reinvent the wheel; it simply tries to fit into the existing paradigm, and this is the beauty of it.' (The article is also available on Chris' own website.)"
PHP inherntely will not lead to scalability, however, if you ever try to create any applications that use a DFS-type algorithm, it can happen. PHP (I know it is web-based, shouldn't ask too much) does not allow for extremely simple soloutions in DFS type algorithms that are apparent to most users. Many will end up with too many "while()" statements and bring down script efficency exponetialy.
it simply tries to fit into the existing paradigm
Allright, he used the word "paradigm", that makes his opinion automatically invalid.
The only real argument I could really find was "Java doesn't do X well, therefore PHP must be great". The author seems to live in a universe with only two choices, his straw man Java, and his favorite web language, PHP. When he does try and argue PHP's merits on its own, it seems to collapse into a PHP is good because its good argument. I don't see any part of the article addressing how PHP can benefit the developer facing real issues of large scale web development (such as the need for caching systems on high volume websites, or the maintence challenge of larger code bases on complex sites). While good arguments may exist for PHP, they just don't seem to be here.
Perhaps it's not mentioned very often because it's obvious, but I think it's an advantage for systems like PHP, or Rivet that they scale down very well.
What does this mean? That they don't consume too much in the way of resources, and are very easy to get started with. This puts a dynamic web site within reach of more people, which is a good thing, even if inevitably some of them will, yes, write crappy code. It is another example of the "worse is better" philosophy.
I just wish they had used Tcl or something else already out there instead of creating a language that in and of itself is nothing very exciting, and has been a bit slow.
http://www.welton.it/davidw/
Here's an article from Jack Herrington on PHP's scalability.
h p_ scalability.html
http://www.onjava.com/pub/a/onjava/2003/10/15/p
if someone wants to produce a high performance web site in Java, jsp is a bad choice. use Velocity - pure java objects - a decent DB abstraction mechanism (Hibernate, iBatis). . Plus, i used php, ok, it is easy to use and can be preferred small to medium size web sites. but call me biased, it is nowhere near the elegance of java.
I've seen a friendster stack trace before, when the app was running slow at 5 am. For those of you who don't know what this is, it's when Java runs into an error and tells you were your program died. It was really funny. Basically there was a servlet and a call to Database.java and on line 8000 of database.java they were calling mysql directly. Real nice architecture, NOT!
I think the term is subjectable depending on the context in which it's used. Scalalable does have many definitions but I don't think that they are all wrong except for one.
His definition suits him well but it might not be helpful for me.
I might use scalable just to say that an application can easily (with little or no modification) handle 100x more users. This doesn't necessarily mean that the difference in system load varies a minimal specific amount per each extra request. All that matters is that it will work with higher demand. Who cares how or why.
I think scalable can also mean that an app can handle 10,000 users when hosted on a single machine but when put on a cluster of computers it can handle exponentially more users. To me that is a scalable application.
Scalable has no set definition in the contexts of applications.
Scalability is rarely that much of an issue- any halfway decent architecture (php, java, even .net) will let you scale horizontally- and Moore's law will take care of any performance problems in time.
My big issue with PHP is maintainability- I see it (perhaps incorrectly) as a glorified templating language, which places it on the same evolutionary track as ASP and cold fusion; developers will tend to munge sql calls into the templates, blow off any MVC separation, and get a system that is very hard to keep going for more than a few revisions.
What a strange bird is the pelican, his beak can hold more than his belly can.
I worked in a small shop developing web apps, and while it wasn't mission critical stuff like banking, it wasn't exactly brainless "dump data from MySQL" stuff either. I was lucky that my boss wasn't picky about languages. But if anyone I work with doubts the power and simplicity of PHP, I usually bring up Yahoo.
IMHO, PHP rocks. It's suitable for pretty much any and all web development. It can be used for quick hacks, or you can code it like a pro with objects and stuff.
PHP's problem is that it quickly becomes unmaintainable in larger projects. That's why it doesn't scale, not because the platform isn't fast enough or Apache can/can't scale.
PHP will continue to have this problem until someone comes and tells the developers about a nifty invention called 'namespaces'
Some other things that could help: Standard templating for easier separation of design/content from code, a better module architecture that doesn't require me to recompile just to get some new functionality, some nice standard modules that go with that new architecture.
Of course if someone did all of that you'd have Perl and since we already have Perl, I'll stick with it.
The Anti-Blog
The term "scalable" has become an industry buzzword. It is fruitless to argue whether something is scalable or not if there is no clear defination. It's like arguing whether you believe in freedom or not. Of course most people in the world will say they believe in freedom, but if you ask 100 people to define it you will get 100 different answers (the Bush administration has had a field day with this because the minute you oppose them, they accuse you of not believing in freedom; their defination of course).
It is impossible to say php is or is not scalable unless a defination can be agreed on. And with "scalable's" current buzzword status, I don't see that happening very soon.
I will start with mandatory links to the great series of articles that Ace's Hardware ran, describing their server scenario and their migration from PHP to Java/J2EE:
The PHP Scalability Myth starts of by defining three types of server architectures. The first, two-tier, and the last, logical-three-tier, are the same conceptually (there is the slight distinction between whether display and business logic code is "mingled", but this is typically not a performance issue, but just an aesthetic or design issue). This two-tier/logical-three-tier architecture is the only one PHP supports natively. The article then proceeds to compare a two-tier PHP architecture against the most elaborate full three-tier Java architecture, which is used rarely in practice, and extremely rarely in the same domain in which a PHP solution is feasible. Instead of comparing apples and oranges (if PHP supported a full three-tier architecture, I would imagine two-tier PHP vs. three-tier PHP would have the same performance discrepencies), let's simply compare the only architecture PHP supports natively, two-tier, against JSP talking directly to a database, as this scenario is the most analogous to the PHP one. Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state. And let's assume the database is the largest bottleneck.
The article states:
I'm not sure what "stub" the article is referring to, but I will assume it means an Apache module which talks a "native" protocol to the servlet engine. The first such module was mod_jserv, which could run the servlet engine both in-process and over a compact protocol called AJP (Apache Java Protocol), which represents essentially a pre-parsed HTTP requests. This module, as well as the AJP protocol itself has gone through severel revisions, from mod_jk, to mod_jk2. I cannot quite recall, but I think some version of mod_jk might have lost the ability to run in-process. Every other version, including the most current, can, if I recall correctly. This is besides the point, because as far as I know, AJP always has been a trivial performance overhead (I believe recent versions can run over Unix domain sockets). In fact, Apache is routinely used in production as the front-end web server, instead of the built-in servlet engine web server, simply because it is faster at serving static content, and that the AJP protocol is negligable. If the "stub" referred to in the quote is not the AJP module, then this may not be relevant, nevertheless AJP has always been highly efficient and typically negligable with regard to performance (the same typical connection min/max/idle count configurations apply as do to Apache itself).
The article goes on to proclaim the complexities of caching and data object persistence which we have eliminated from our comparision. Let's move on to the real bottleneck - the database. The article says "PHP's connectivity to the database consists of either a thin layer on top of the C data access functions, or a database abstraction layer called PEAR::DB. There is nothing to suggest tha
I think to settle this debate is a possible real-world example. Look at the story on the Jboss Nukes Project. It explains the CPU utilization and speed of the PHP version and how moving to a J2EE implementation decreased the wait times dramatically.
Its difficult to argue with facts.
It is not a good thing that there is a short learning curve on PHP. While it does put the ability for dynamic webcontent at the fingers of most users, it also creates a crapflood of insecure sites.
I hate to say it, but the problem exists between keyboard and chair. PHP is not inherently secure or insecure language. It may still have bugs, but those are a function of age and the serious ones have been taken care of. Rather, the problem is in the way people write software using PHP, without necessarily understanding the nature of the platform they are using.
It is not the job of the language to enforce security - it is the job of the programmer.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
See their explanation on why they use PHP
IMHO, PHP rocks. It's suitable for pretty much any and all web development. It can be used for quick hacks, or you can code it like a pro with objects and stuff.
.NET and others.
Yes, PHP is excellent for web development. Yes, PHP can scale to even some large web sites. But since the web is still all the rage, this is unfortunately all that many people think about. Where PHP stumbles is when you need to move off the web or when you need to write complex business logic that is not solely driven by a web tier. PHP also fails when you need to integrate diverse transactional resources in an efficient manner. Not all business applications can be suitably implemented in PHP. As examples:
- PHP, by its scripted execute-and-terminate nature, cannot schedule the execution of tasks on its own. So, for example, there is no way to schedule an email to be sent at a specified time. If you need this sort of functionality, you'll have to look beyond PHP to ugly hacks like cron jobs that call PHP. (and then PHP scripts that can automatically modify your cron scripts..) Alternatively, you could write your own scheduler in a different language.
- Somewhat related, PHP is incapable of asynchronous operation. Suppose, for example, that we have a flood of customers placing orders. Our inventory database is fully capable of keeping up with the demand, but credit card processing system is backlogged and this is out of our control. So we cannot give users an immediate response as to whether their payment was accepted upon placing the order. We also don't want to make them wait 5-10 minutes after hitting the "place order" button for a response. The proper business solution is to accept the order, but send the customer an email later if the payment was rejected. This process requires asychronous operation -- queueing of the payment validation requests and possible further action separate from user interaction. PHP has no solution for this scenario or the many others like it and thus we must look beyond the PHP domain.
- PHP is quite weak when it comes to writing a complex business logic layer. This is not to say that it is not possible, but there are no frameworks available comparable to those offered in the Java world (and I'm not just talking about EJB, btw). So this is not a question of languages, but of available tools to do the job efficiently. For example, PHP has no concept of application-level transaction management. (declarative transactions, isolation levels, etc.) Looking towards the cutting edge, it has no support for Aspect Oriented Programming, which is an enormous boon to business logic developers, available in Java, C++,
- PHP is weak on tools for developing the persistence layer. For example, it has nothing comparable to Hibernate, let alone tools for RAD employing UML.
- PHP has no pre-built solutions for caching persistent data, and certainly not objects. Once again, it is possible, but developers are left to roll their own solutions using shm extensions or writing out to the database backend. Using the database can be terribly slow and even the shm approach requires (de-)serialization on script load/terminate. While this sort of thing does not limit scalability, it does limit performance (response times).
- PHP has no means of replicating application state in a cluster other than using the backend database. While this is often of no consequence, some complex business software holds a fair amount of state which needs not be persistent.
- PHP itself cannot reasonably be used to develop non-web clients such as a GUI tool for efficient rapid data entry or greater interactivity, a PDA client, or an embedded device that interfaces with a campus security system. These sorts of clients can talk to PHP scripts via SOAP extensions, but it should be recognized that we have again left the PHP domain to meet these needs and the resulting solution may not be the most efficient.
So in closing, PHP is great for some thing