On PHP and Scaling 245
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.)"
Author seems to live in a vacuum (Score:5, Insightful)
PHP scales down, too (Score:5, Insightful)
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.
Sorry buddy... (Score:1, Insightful)
Definition of Scalable (Score:5, Insightful)
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 a dead issue (Score:5, Insightful)
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.
Not always a good thing... (Score:2, Insightful)
Re:scalability is a dead issue (Score:3, Insightful)
Also, maintainability is not a feature of a language, it's the organization practices of the developer. Java developers are used to throwing files wherever, doing import statements wherever, and once its compiled, it's organized! Well, you have to organize your files a little bit better in PHP for higher performing code. But hey, if you're sloppy then that's your fault, not PHP's fault it's just one of the aspect of a scripting language just like waiting around for compiling is an aspect of a compiled language.
Re:A few things that could lead to scalability (Score:4, Insightful)
Scalability and Maintainability go hand in hand (Score:4, Insightful)
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.
Re:jsp is a bad idea, but Java is not (Score:2, Insightful)
Implementing a site in PHP... (Score:4, Insightful)
The reason (Score:2, Insightful)
Re:Scalability and Maintainability go hand in hand (Score:5, Insightful)
This is particularly funny coming from a perl developer. Perl can become unmaintainable on a small project.
I can summarize it all (Score:2, Insightful)
2. Java scales well.
3. Friendster couldn't devlop a scalable J2EE application, so they switched to PHP.
4. WHat will Friendster switch to when they can't develop a scalable PHP application?
Re:Sorry buddy... (Score:2, Insightful)
JavaBeans are great in that they're an architecture to communicate through multiple levels and allow for separate tiers. But to think that the same thing can't be done in PHP is foolish. PHP is about keeping the language simple only giving the developer the tools he needs to get work done; making easy things easy, and hard things easier.
I've written a system (propreitary, sorry) that has a complete separation among the 3 (or more) tiers, that allows retrieval of remote objects and combining that with local objects. It allows a user's session to be shared amongst a round-robin server farm, abstracted data access, and my very own templating system.
The language is the lesser issues: it's the developers working on a piece of software and the design of the system that's important.
Zef
Re:Not always a good thing... (Score:5, Insightful)
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.
Re:Author seems to live in a vacuum (Score:3, Insightful)
I always tend to think of *accessing data* as where the rubber hits the road in website scalability. Of course, PHP by itself is super-scalable (because each request processing is independant)... but what exactly are you *doing* in that PHP code? If you aren't accessing and displaying data (generally from a database), you've got a pretty unique website.
I don't see much point in discussing scalability if you're pretending these other layers don't exist... the scalability of a website based on PHP, Java, or whatever is only as good as the least scalable element... which is usually not the basic execution of the code, in the average website. That's the part that's easy to make scalable.
Code scalability also important (Score:3, Insightful)
While this does have more to do with how the code is written, programming languages to contribute to code scalability.
Does PHP promote scalable code?
PHP is not always good enough (was Re:Yahoo) (Score:5, Insightful)
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
Re:Author seems to live in a vacuum (Score:3, Insightful)
naw.
friendster's load characteristics have to be totally uncacheable, because of how many users they have, and the amount of disparate data sources needed for the pages. no other social networking site has even close to their load.
update a friend ? needs to be instantaneous. what happens then ? just about everyone on the entire system's friend count must change, real-time, with 1st, 2nd, and 3rd degrees. that means every addition/delete of a friend will effect hundreds of thousands of users to be correct.
JSP or PHP, it doesn't matter...like I said before, social networking sites have many different things happening than other high-volume database sites.