Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Java

PHP Scales As Well As Java 627

Posted by michael from the emperor-has-no-clothes dept.
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."
This discussion has been archived. No new comments can be posted.

PHP Scales As Well As Java More

PHP Scales As Well As Java

Comments Filter:

  • What's the PHP equivalent to Java NIO? (Score:2, Insightful)

    by Anonymous Coward
    And the other recent additions that add to the scalability of Java?

    • Re:What's the PHP equivalent to Java NIO? (Score:4, Insightful)

      by bigjocker ( 113512 ) * on Friday October 17, 2003 @12:13PM (#7240508) Homepage
      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 requerements and a ton of lines to mantain, that's when the real scalability shows off. You can build a 1,000,000+ lines project in PHP and run it on a distrubuted server and whatnot. But who the hell is going to mantain it??
      • 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.

        Maybe with dynamic typing, that would only be a 30,000 line project.

        • 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.

      • 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.

      • 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 scriptin
      • What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers.

        find . -name "*.p" -o -name "*.htmp" -o -name "*.html" -o -name "*.php" | xargs wc -l
        91564 total

        current staff: two php developers. two flash developers.

        close enough?

        (nb: .p and .htmp are php pages... it's a legacy requirement.)

      • The scalability and maintainability of a project ove r a period of time most importantly depends on the quality of code and documentation within code (Comments).

        I have seen so much java code, so badly written that the developer who wrote it 6 months ago, was also hesitant to touch it.

        While on the other hand, I have seen hugh shell scripts being maintained over a period of 10 years.

        If the code to be maintained is poorly written and ill documented , then no matter wheather you use strict type checking or n

  • Scaling (Score:2, Insightful)

    by stanmann ( 602645 )
    Java and PHP Scale equally well... Well that isn't a big surprise since Java as I understand it doesn't scale very well..

    • Re:Scaling (Score:3, Insightful)

      by Frymaster ( 171343 )
      Java and PHP Scale equally well.

      as a corollory, it is much easier in php to write code that itself does not scale well. contrary to popular belief, php is not a language for sloppy or new programmers - to write a robust, secure, scalable app in it you have to know what you are doing!

    • 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.
  • pudding is as good of a building material as tofu..

  • of course it does... (Score:3, Interesting)

    by joeldg ( 518249 ) on Friday October 17, 2003 @12:04PM (#7240386) Homepage
    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 [intercosmos.net] 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

    • The same system in java probably would not work, and if so would take up so many resources as to be no efficient.

      Um, why not? A JIT compiled Java application server with the ability to perform object pooling and the like should outscale PHP in it's sleep, and probably be significantly faster at all levels to boot. If it does anything else, you did something wrong.

      (Personally, however, I'm really favouring Ruby/FastCGI over both at the moment)
      • our one java server at present that is running jacarta and tomcat is a huge resource hog and is slow on top of that, we are actually porting java code to PHP left and right because of issues with it being slow.

        saying that it is actually a much faster box than the php boxes we have, and that those php boxes can outperform the java ones (at every turn, the benchmarks are ridiculous) we are not considering java at all.

        • Re:of course it does... (Score:4, Informative)

          by FattMattP ( 86246 ) on Friday October 17, 2003 @12:25PM (#7240650) Homepage
          Tomcat is pretty slow in general. Why don't you try Resin [caucho.com]?

          • Re:of course it does... (Score:2, Insightful)

            by stesch ( 12896 )
            Why don't you try Resin?

            Maybe he doesn't want to spend lots of hours to change his code every time a minor release of Resin comes out. And then discovering new problems many weeks later.

            • I've never had that problem with Resin before and I've been using it for over two years. Then again, I have enough self control not to upgrade ever time a minor release comes out.
        • Well, that fits in to the "doing something wrong" category :)

          Have you looked at Ruby? It's great for application server stuff, pretty fast, is far more elegant a language than PHP, and is much easier to extend in C/++ if you need to optimize a performance-critical hotspot.
        • Tomcat is a reference implementation of a servlet engine....

          If you want performance, use something like Resin (free). It will blow the socks off Tomcat.

          People who complain that their java server app is too slow and then go on to mention that it's running on tomcat have no clue what they're doing.
    • I think you are confusing Java with applets. JSP (especially under Resin) is so fast and so efficient that I still have a hard time believing that some of the servers I work with can keep up. One is running a data-driven applicatino on a PPRO180 handling 8-10000 sessions a day, thats just crazy.

      PHP has it's place, its great for multi-user web hosting companies where Java's architecture is a poor choice. It's not great for enterprise development, and every time someone who is fresh off writing their foru

  • yeah whatever (Score:2, Informative)

    by TedCheshireAcad ( 311748 )
    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.
    • Yeah... I LOVE PHP but I have to agree. Without a web server, PHP is still pretty good but it just doesn't scale. Now if he said PERL was as scaleable, Id say he was a bit closer.
      • Agreed. We use mod_perl, and all our logic is implemented as Perl Modules. Web sites are just wrappers around the logic.

        We chose this because it eliminated the requirement for the web site. We could quite easily interface in Perl/Tk, command line, or curses etc...and because Perl is just cool.

        Obviously Java can be used standalone, not sure about PHP. Can it operate with the presence of a web server?

        • ooops

          s/with/without/
          • Yeah I get you. Yes it can (though few people realize this). You simply install it as a CGI and call the binary as such: /usr/bin/php your_script.php

            and POOF! your_script.php executes :)

            Though few people install PHP as a binary; most install it as a PHP module.
            • Hmmm... testing this out but so far it seems with some minor adjustments, I can run php scripts with it installed as an apache module too. I just have to make sure the system knows where to find the necessary files :)

              Learn something new every day. :)
    • See? This is the kind of FUD people have been complaining about. You have zero information here about what would make Java scale better, but you still insist that it does.

  • I thought the shocking revelation would have been "Java scales as well as PHP" under pathologically slanted circumstances.

  • No.. (Score:2)

    by sporty ( 27564 )
    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..
    • Bingo....

      Until PHP has some sort of pooling built in (does it? Last I used was PHP4), it's not going to be as robust or scalable as Java for enterprise server applications. Period.
  • I'll stick with mod_perl and HTML::Embperl, thanks.

  • Could someone explain instead of just flaming? (Score:3, Interesting)

    by Faramir ( 61801 ) on Friday October 17, 2003 @12:09PM (#7240458) Homepage Journal
    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?
    • I'll try.

      Performance-wise, J2EE decouples major components which would otherwise become bottleneck of overall performance. E.g. most popular architecture decouples frontend(e.g. load-balancer, apache), business logics(e.g. servlets, EJB-containers) and database(e.g. Oracle, Sybase) such that optimization could be done on individual components. Optimization can be ranged from adding CPU/RAM, disk stripping to clustering. Experience told us that this architecture can be very sucessful in improving performan
    • I think you're mixing two concepts here. First, there's Java/J2EE. You can do Java without doing J2EE. J2EE is a whole set of additional tools and ideas which are java-based. My impression of it is that it's more useful to huge organizations like banks, where you've got different servers in different buildings which have to interoperate (hence things like javabeans and servlets). It's not a scalability thing, it's a distributed application thing, you know? Although I'm sure J2EE has scalability features bui

  • Yahoo! (Score:4, Interesting)

    by nocomment ( 239368 ) on Friday October 17, 2003 @12:09PM (#7240464) Homepage Journal
    Well seeing as Yahoo is switching [yahoo.com]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).
    • If you read the article, they mention the only reason they arent using Java is because FreeBSD doesnt have decent threads support. Perhaps if the major bulk of their systems ran a different OS, they might use j2ee?
      • I read that, it doesn't _exactly_ say they aren't using it because of the threads but more like, they aren't considering it because of threads. It wasn't even an option to be included in the benchmark tests. Although if they weren't so stuck on FreeBSD they _might_ choose j2ee. That would be a big boon for Sun if they did :-)

  • Perl (Score:3, Interesting)

    by rmohr02 ( 208447 ) <mohr.42NO@SPAMosu.edu> on Friday October 17, 2003 @12:10PM (#7240468)
    Perl seems to scale as well--it runs a very busy site [slashdot.org] I frequent with few problems.

    • Re:Perl (Score:3, Insightful)

      by pHDNgell ( 410691 )
      Perl seems to scale as well--it runs a very busy site [slashdot] I frequent with few problems.

      I've been having a great deal of broken pages lately.

      I also have been having a lot of problems with the RSS feeds lately.

      Overall, I like using slashdot as an example of why mySQL and perl are bad ideas for busy sites.

      Any language can be used to write bad code, but I've rewritten really perl projects (2M line range) that were impossible to maintain into java (for example) applications that were not only easier

  • Some facts (Score:5, Informative)

    by vlad_petric ( 94134 ) on Friday October 17, 2003 @12:10PM (#7240477) Homepage
    1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

    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 ?

    • Re:Some facts (Score:3, Informative)

      by consumer ( 9588 )
      PHP provides persistent connections, so the system does not need to reconnect to the database on each hit. It also provides various caching tools, like memcached [danga.com]. Charts and graphs are typically handled with third-party libraries. It's not exactly hard.

      • Re:Some facts (Score:5, Insightful)

        by vlad_petric ( 94134 ) on Friday October 17, 2003 @12:28PM (#7240682) Homepage
        But connection pooling scales much, much better than persistent connections ... Especially when each user makes only a couple of requests.

        • Re:Some facts (Score:3, Informative)

          by consumer ( 9588 )
          Connection pooling only scales better if most of the time in your application is spent doing calculations or something without the database. If your app mostly is about accessing a database, then the connection will be constantly in use and there will be no benefit from pooling.
          • Connection pooling only scales better if most of the time in your application is spent doing calculations

            In the majority of applications, most of the time is spent idle waiting for the user to do something. If you are holding a DB connection during this period, that is extremely wasteful.
    • Besides the ability to inline PHP in static text, PHP isn't particularly bound to HTML output. It's not a specialized language -- ironically, it's a rather crappy language for generating HTML. It's quoting and substitution rules suck, it's regular expressions are a pain to work with (more quoting problems), and stuff like magic quotes are both insecure and unpredictable. PHP as a language sucks in lots of other ways, it was designed by people for which it was their first programming language implementati
    • 1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

      Isn't this just the same as saying "scaling" means that the software uses the hardware efficiently -- which would then be true for both PHP and Java to similar degrees?

      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.

      You kno

      • Re:Some facts (Score:3, Informative)

        by crazyphilman ( 609923 )
        Connection pooling means, basically, that the server sets up a pool of already open connections to a database, and your app can borrow a connection from the pool when it needs to interact with the database, then release the connection back to the pool. It's a performance trick, because opening a connection and closing it eats up resources, so you open up all the connections at once and leave them open, and they just handle requests which is less resource-intensive. I haven't had much need for it myself, but

  • They scale differently (Score:5, Insightful)

    by digidave ( 259925 ) on Friday October 17, 2003 @12:15PM (#7240536)
    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.

  • IF you accept the underlying assumptions... (Score:5, Insightful)

    by Dr. Bent ( 533421 ) <ben&int,com> on Friday October 17, 2003 @12:17PM (#7240560) Homepage
    ...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 [jboss.org] 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.
    • All of the Java "best practices" stuff is full of warnings about how storing anything significant in the session will kill your performance. It's a huge mistake. Only truly transient data belongs in the session, regardless of language. And yes, PHP has various ways of doing distributed sessions, but frankly this sort of thing is overrated. It's VERY hard to go faster than MySQL with MyISAM tables for this kind of simple shared data.

    • Session state (Score:3, Interesting)

      by JMZero ( 449047 )
      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 application

  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Friday October 17, 2003 @12:18PM (#7240573)
    Comment removed based on user account deletion

  • where I stopped reading (Score:5, Insightful)

    by BigGerman ( 541312 ) on Friday October 17, 2003 @12:19PM (#7240584)
    "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.
    • Sure if it was coded by former vb guy w/o a clue.

      Welcome to the Real World.
    • 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...)
    • 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.

      Doesn't this just illustrate how absurd it is to use RMI for this kind of thing in the first place? It forces you into workarounds likes this, and makes you use ugly coarse-grained interfaces instead of standard OO practices.

  • From the article: "Yet another area of efficiency concern is in the connection between the language and the web server. "

    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

  • Hrm (Score:5, Insightful)

    by Etriaph ( 16235 ) on Friday October 17, 2003 @12:29PM (#7240689)
    The issue with PHP is not whether or not it scales as well as Java, but whether or not it's useful in a real-world application. In my opinion, it isn't that useful.

    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.

  • Back when I was concerned about whether BRL [codesimply.net] 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

  • horizontal scaling (Score:4, Funny)

    by BubbaFett ( 47115 ) on Friday October 17, 2003 @12:31PM (#7240714)
    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 ch
    • 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.

      This is a Bad Thing.

      Shitty code doesn't belong in your application. If something fails because it's designed poorly, you NEED TO KNOW about it even if it results in
      an ugly fault message to your users.

      It's one of the fundamental tenets of programming: if you allow error conditions to go untrapped, things start getting secretly corrupted and you won't even notic
  • 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: perfor
  • apparently, the folks at JBOSS do think php scales as well as java [onjava.com]. of course they have a product to push, but they did use php and found it wouldn't hold up.
  • 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 a
  • 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.

  • J2EE != EJB (Score:4, Informative)

    by shaper ( 88544 ) on Friday October 17, 2003 @12:46PM (#7240883) Homepage

    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.

  • 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
  • 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.
  • The PHP Scalability Myth
    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 ... two only slightly related topics.

    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 r

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close