Women in Technology

Hear us Roar



Article:
  The PHP Scalability Myth
Subject:   article bugs
Date:   2003-10-17 10:01:31
From:   anonymous2
Ok the article has bugs. As some noted scalability refers to THROUGHPUT not performance (ie. speed).


Actually, Java or JSP by themselves don't solve the prob. And neither does PHP. EJB solves the problem.. in PHP I'm sure the solution is possible but it isn't free. (w Java you have load balancers and connection pooling too.. but the problem w PHP is that you have to roll your own session management.. in EJB its free)


I'm sure I can whip up a solution in C too, but I'd need some time figure out some things.


PHP advantages:
- Rapid development
- little barrier to coding up a solution
- easy to learn


PHP disadvantages:
- Pear::DB sucks (sorry)
- Error handling is not standardized and requires more effort


Java advantages:
- Better for large scale design
- Robust error handling
- Lots of enterprise tools


Java disadvantages:
- Easy things are too troublesome to do
- Slower development



So does PHP scale? Depends on how you design your app. Is there a standard way to do it. I don't think so.



Does Java scale? It does if you use EJB properly.



Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • article bugs
    2005-07-29 11:32:41  revprez [View]

    As far as I can recall, we've never defined scalability != throughput but as the a function of throughput and availability change. When availability is stable and minimally impacted by large increases in throughput, throughput is the dominant term.
  • article bugs
    2003-10-17 11:58:39  anonymous2 [View]

    Pear::DB sucks? OK, what ever you do don't site reasons. Error handling has been addressed in part by PEAR and even better with the new PHP 5 that is in beta. Try that and you'll refute your own comment related to error handling.

    PHP disadvantages are:
    - No control over threading
    - Code not compiled

    Other than that the only real difference between Java and PHP in terms of scalability is in EJB's.

    Now what people should do is talk about cost of development. Most Java shops are using for-profit app servers (websphere, BEA, etc). Then you have the cost of Java developers and the relatively steep learning curve.

    Fact is, both have a place in your IT shop. The question is do you have the knowledge to know when one makes more sense than the other?