Women in Technology

Hear us Roar



Article:
  The PHP Scalability Myth
Subject:   Performance NOT EQUALS to Scalable
Date:   2003-10-16 02:08:13
From:   anonymous2

Performance: time to finalize an user action


Scalable: time to finalize thousands of concurrent user actions not very different than serving one.


PHP-JSP : similar performance.


JSP only performs better than JSP-J2EE, obvious.


But:
JSP only NOT SCALE.
PHP only NOT SCALE.


JSP-J2EE scale => thanks to distributed and parallel programming.


Please rewrite the article.

Full Threads Newest First

Showing messages 1 through 27 of 27.

  • Performance NOT EQUALS to Scalable
    2003-10-16 04:38:39  anonymous2 [View]

    scalability is achieved either by having a "read-only" application, which can be easily deployed on multiple servers, or by having a way to distribute the changes on multiple copies of the database. It has a lot more to do with _how_ you write the application rather than which particular language, libraries or platform you choose.
    • Performance NOT EQUALS to Scalable
      2003-10-17 10:03:55  anonymous2 [View]

      YES! And, I think this is what Herrington's trying to get at -- the language differences don't matter as much as the application design. Both Java and PHP provide tools, albeit different ones, to solve a wide variety of design problems. So you can factor out the language itself, and you're left with *design* as the critical factor to scalability.
      • Jack Herrington photo Performance NOT EQUALS to Scalable
        2003-10-17 10:05:53  Jack Herrington | O'Reilly Author [View]

        Yes. This was exactly my point.
      • Performance NOT EQUALS to Scalable
        2003-10-17 12:47:13  anonymous2 [View]


        What are the *design* options relating to distributing operations in PHP ?

        PHP is going to be coupled with Java, because PHP is very popular in the presentation layer, but its API to develop business code and objets is very very ugly, and distribution capabilities of business code are... none.

        Serving millions of concurrent users has a price of performance because distribution is necessary, HTTP load balancing is not the solution when you must be able to manage sessions (usual), because the machine have be the same inside a session (except that you have distributed session capabilities in your JSP server), with EJB you can distribute the load of the each session to other(s) machines.

        PHP is good to amateur sites with simple web applications and few concurrent users. But not to professional sites well designed (without the crap of PHP API) and with heavy load requirements.









        • Performance NOT EQUALS to Scalable
          2003-10-17 18:17:51  anonymous2 [View]

          -- PHP is going to be coupled with Java, because PHP is very popular in the presentation layer

          PHP is popular in the presentation layer because it is very good at presenting. And it's not amateur hour.

          The right tool for the job people, the right tool for the job.
      • Performance NOT EQUALS to Scalable
        2003-10-17 12:47:32  anonymous2 [View]


        What are the *design* options relating to distributing operations in PHP ?

        PHP is going to be coupled with Java, because PHP is very popular in the presentation layer, but its API to develop business code and objets is very very ugly, and distribution capabilities of business code are... none.

        Serving millions of concurrent users has a price of performance because distribution is necessary, HTTP load balancing is not the solution when you must be able to manage sessions (usual), because the machine have be the same inside a session (except that you have distributed session capabilities in your JSP server), with EJB you can distribute the load of the each session to other(s) machines.

        PHP is good to amateur sites with simple web applications and few concurrent users. But not to professional sites well designed (without the crap of PHP API) and with heavy load requirements.

        J.M.A.









    • Performance NOT EQUALS to Scalable
      2003-10-17 12:14:39  anonymous2 [View]

      A lot of the 'heat' being generated here appears to stem from the absence
      of a good definition for "scalability" in the article. This is a common
      problem.

      Scalability is an abstact notion. So are terms like "reliability", and the
      word "performance" itself. One person's meat is another's poison. With
      regard to computer system performance, you might desire to optimize such
      metrics as, throughput, response time, or resource utilization; to name a
      few. The goal depends on the context. If you're printing reports at the end
      of the financial year, MAXIMUM throughput is likely to be your goal. In
      contrast, many web applications focus on MINIMIZING user response time.

      Simply put, 'scalability' is a relation among variables (performance
      metrics) that characterizes the rate of diminishing returns as the
      dimensions of the system are increased. This means that scalability can
      actually be expressed in a mathematical form. I've tried to illuminate this
      point elsewhere http://www.perfdynamics.com/papers.html. Specifially,
      http://www.teamquest.com/html/gunther/fitting.shtml and
      http://xxx.lanl.gov/abs/cs.DC/0210017 should be of interest.

      --Neil Gunther
  • Performance NOT EQUALS to Scalable
    2003-10-16 05:20:56  anonymous2 [View]

    I think the previous commenter is observing that
    *real* scalability is architectural, and explicitly
    provides for distribution and parallelization.

    That's apt, of course. Without providing details
    I can't afford (in time) just now, I'll counter-assert
    that, while Java certainly has plenty of distribution
    stories told about it, PHP and other scripting alternatives
    should feel no shame. I applaud author Jack Herrington
    for at least opening the debate with a proper focus on architecture.
    His is an article that needed to be written, and I
    hope it will be widely read.



    CL
  • Performance NOT EQUALS to Scalable
    2003-10-16 06:35:09  anonymous2 [View]

    In other words, with a thousand users accessing a single server, PHP may work as well as Java.

    For a million users, 10 servers using J2EE architecture can perform well.

    What do you do with PHP?
    • Performance NOT EQUALS to Scalable
      2003-10-16 06:42:25  anonymous2 [View]

      Head to http://www.sourceforge.net and see it in action.
      • Performance NOT EQUALS to Scalable
        2003-10-16 17:40:42  anonymous2 [View]

        I mean services with sessions.. like a web site with a shopping cart.. I'd like to see amazon.com run on PHP.
        • Jack Herrington photo Performance NOT EQUALS to Scalable
          2003-10-16 19:54:12  Jack Herrington | O'Reilly Author [View]

          Amazon cites Perl as a major source of it's success. HTML::Mason is a hiring skill at Amazon. They experiment in Perl and productize in C. Your saying that scripting languages can't handle shopping carts?
          • Performance NOT EQUALS to Scalable
            2003-10-16 21:18:22  anonymous2 [View]

            Amazon has a J2EE architecture. Scripting language is for the presentation layer, so you're question doesn't make sense.. J2EE has scripting language called JSP.
            Ok, a load balancer with several Apache web servers can provide scaling for http connections. And I'm sure you can do something with the rest of the layers too. That has nothing to do with PHP.
            J2EE specifies how scalability and fail-over can be provided at each layer.. PHP doesn't.. because PHP is not an architecture.
            The author is just mixing up performance with scalability.
            • Jack Herrington photo Performance NOT EQUALS to Scalable
              2003-10-16 23:17:56  Jack Herrington | O'Reilly Author [View]

              Can you point to a URL that says that Amazon is on J2EE? I'm sure parts of the service are, but from the hiring page:

              http://www.amazon.com/exec/obidos/tg/stores/static/-/jobs/department/Seattle-
              Headquarters/011/102-8866517-1623349#03-009324

              I would say that only fragments of the service are. Amazon has been around a lot longer than J2EE.

              Producer Note: I've broken the above URL into two lines because it was pushing the page out in some browsers.
              • Performance NOT EQUALS to Scalable
                2003-10-16 23:47:28  anonymous2 [View]

                Oooops my mistake, so sorry, it is Ebay, and one billion hits per day:
                http://www.sun.com/service/about/success/recent/ebay_5.html
              • Performance NOT EQUALS to Scalable
                2003-10-16 23:48:23  anonymous2 [View]

                Oooops my mistake, so sorry, it is Ebay, and one billion hits per day:
                http://www.sun.com/service/about/success/recent/ebay_5.html
            • Performance NOT EQUALS to Scalable
              2003-10-17 05:53:03  anonymous2 [View]

              maybe, but i think that amazon would be fairly easy to do with a technology like mason on fastcgi. The point is that it isn't so much about the technologies as the way in which they are applied. I'm sure that the J2EE frameworks do a lot of the work for you, but that isn't to say that you can't achieve the same results using other technologies. Thought the article was a bit stooopid ;-)
            • Performance NOT EQUALS to Scalable
              2003-10-17 09:15:00  anonymous2 [View]

              Amazon does not have a J2EE architecture. They use custom C++ stuff and Perl.

              The point of the article is that PHP can scale to handle large sites as well as Java can. The fact that an HTTP load-balancer is separate from PHP looks like a positive thing to many people. Fail-over is typically provided by the load-balancer as well, assuming you are using one of the many approaches for sharing session data with PHP.
              • Performance NOT EQUALS to Scalable
                2008-04-10 06:59:33  stefan.arentz [View]

                No doubt that parts of Amazon still run on Perl but I think they have mentioned several times on conferences that Perl was a dead end for them and that they switched to Java for all new development.

                Most, if not all, of their public web services are also written in Java.

                S.

        • Performance NOT EQUALS to Scalable
          2003-10-17 09:11:18  anonymous2 [View]

          Yahoo.com (the busiest site in the world, and yes they keeo track of user data) runs significant parts of the site on PHP.
    • Performance NOT EQUALS to Scalable
      2003-10-16 10:02:50  anonymous2 [View]

      Isn't it obvious? You use the same 10 servers, with a load balancer.
  • Jack Herrington photo Performance NOT EQUALS to Scalable
    2003-10-16 08:11:45  Jack Herrington | O'Reilly Author [View]

    What is your definition of J2EE, because if your definition of J2EE includes a JSP/POJO configuration then you have a logical three tier architecture which is exactly the same as PHP. How is it then that JSP-J2EE scale and PHP not scale?

    Without more concise information I cannot 'rewrite article'. I appreciate the please though.
    • Performance NOT EQUALS to Scalable
      2003-10-16 08:44:43  anonymous2 [View]


      Sorry I mean EJB (EJB is the core J2EE): JSP-EJB

      EJB = session bean (then use entity beans, JDO, JDBC, what ever you want to access databases), session beans allow load distribution. Most simple approach : JSP in a machine, EJBs in other.

      PHP has the same scalability problems as JSP. It performs well with a few concurrent users, but with tons ... more machines, distributed computing please => scalability.

      Making PHP scalable ... use PHP-EJB or similar when it is ready.


      • Performance NOT EQUALS to Scalable
        2003-10-16 09:36:39  anonymous2 [View]

        Both systems scale by distributing the load across multiple machines. With PHP, this is done with an HTTP load balancer. It's quite easy.

        Exactly what is it that makes you think EJB will be more scalable than a bunch of servers behind an HTTP load balancer running JSP? The additional overhead of EJB typically makes things less efficient, not more.
      • "EJB is the core J2EE"?
        2003-10-16 14:46:31  anonymous2 [View]

        I think you will find that "EJB is the core J2EE" is not a universally held belief. Especially because of the performance issues with EJB deployment even in the 2.0 standard. A good read on this is Manning's "Bitter EJB" which goes into detail on EJB performance problems and offers architectural alternatives.

        As for having EJBs on a different machine, that is a serious performance problem because of the RMI to do all of the data fetch to build the pages. It means that you are paying a penalty to transit the data to and from the web server to the EJB server and then another transit cost to get it in and out of the database. This is why EJB 2.0 added local interfaces.
        • "EJB is the core J2EE"?
          2003-10-17 10:30:02  anonymous2 [View]

          AGGHGHHGHGHGH!!!!!

          Local entities are entities that are local to the clients that are running in the same VM as the EJB container. By using local entities you are assuring that references are used and not remote objects. This doesn't help you with speeding up your servlet/JSPs. Value objects do that.

      • Performance NOT EQUALS to Scalable
        2003-10-17 09:21:50  anonymous2 [View]

        > PHP has the same scalability problems as JSP. It performs well with a few concurrent users, but with tons ... more machines, distributed computing please => scalability.

        Thats a bunch of crap. The JSP is compiled into servlets and the servlet is cached. Multiple threads make use of the Servlet at the same time. In addition, with JIT turned on, the Servlet is somewhat compiled and optimized. How the heck can you say PHP is even close to this? JSP can take the load with no problem. The servlet/JSP container was designed with this in mind.

        Be careful with what you say...because you are clearly incorrect.