Re: Function caching...

Zeev Suraski wrote: > I think we've been through this before - what you describe is simply not > PHP. But it should be. Will you please accept that PHP has being used for large and complex projects for some years now, and that there is considerable demand for such solutions? Will your company please accept that it is catering to a market that demands scalability? > It's changing the whole approach PHP is based on. Yes it is, because it needs to. Just look at the problems PHP _has_ in scaling: - PHP can either run speedy, as a module, within the context of the web server, or run with appropriate user rights, when used as a CGI with suexec or other hacks. An application server would enable PHP code to run speedy, with approproate user rights and WITH NO SUID MAGIC AT ALL. Look at safe_mode. It is an abomination. It does duplicate functionality that should be and actually is in the operating systems, and it fails in doing this. safe_mode isn't. It fails systematically, because it requires properly written code to function correctly, and PHP cannot change the code of all external libraries incorporated into the PHP proper. Some of them come .o only (like Oracle). An application server will fix this problem and make safe_mode obsolete, making the code simpler and more secure at the same time. - PHP cannot make proper use of a limited number of database connections or other scarce ressources, because it is forced to use the web server process model. Apache will open MaxClients times (user, pass, host) tuples many MySQL pconnects worst case. A threaded application server could preopen a configureable number of database connections, mark the "useable" or "busy" and share them among the threads of this particular appserver instance. This will not only greatly reduce the absolute number of connections, but make them better controllable as well. Same goes will all other ressources as well. - PHP currently cannot keep alive variables in a session. Instead it archives some variables, and revives them in the next call to a page in the same session. This utterly fails to handle all kind of entities having external state, like about any resource variable. PHP currently cannot handle properly large networks of interconnected variables in sessions, since this consumes much setup time at the beginning of each page. Also, PHP has problems handling references properly in serialization. An application server does not have such problems, as it does not need to archive things in the first place. It can easily keep networks of objects around between calls, and it can keep ressources alive between calls, barring network timeouts on inactive sockets and the like. - Currently PHP does compile the same code over and over again. Zend is going to offer a propietary product to remedy this problem, presumabley the Zend cache. An application server can keep the precompiled code in memory natively, and share that code r/o between threads of that appserver instance. This will not only make the caching mechanism obsolete, but will also (compiled code size in bytes) times (number of threads - 1) bytes of memory. These problems, all of which are elegantly solved by an application server approach, are what makes currently the most abitious PHP projects slow, and lets them scale badly. Ulf Wendel of NetUSE and phpdoc, Bjoern Schotte of php-center.de, Andre Christ and Jens Ohlig of Twisd (www.twisd.de) all experience the same problems at the moment - the problems I discuss above. XML/XSLT integration, SOAP integration and Corba integration will only make it worse, as more state needs to be kept around between calls in these technologies as ever before. > In my opinion, what you want is exactly what made mod_perl > fail in comparison with PHP's success. I don't want a module running in the context of each webserver process, duplicating code, database handles, and running under the wrong user id. I want my own application context, independent from the webserver and I want my application threads to transparently share ressources. I am in no way talking about mod_perl at all. I am talking more along the lines of WebObjects and other application servers. > I completely disagree that the current implementation is a > result of bad design. If I were to rethink about the way to > implement PHP today, I'd do it in a very similar way to the > way it's implemented today. Sure, there are things I would > have changed (most notably, either nuking the OO subsystem > completely, or creating a more robust one). Go ahead and nuke the OO subsystem. Stay BASIC, cater the dummies. PHP at the moment is no longer running personal home pages. It is running large webshops, is doing SAP integration and strategic backend duties. It is running large content management systems. The users of PHP - YOUR CUSTOMERS, do you get that! - are planning to deploy it into the enterprise. They see PHP as a direct competitor to ASP+ and .NET. You have condemned yourself and your investors to provide the scalability and performance they need to do this. You won't cut a thing at this level without the exact architecture I described above for the reasons I described. You won't get a sniff of enterprise level business without an object framework properly done. > I'm not saying that your ideas are bad. They just have very > little to do with PHP, and most of the advantages PHP has will > be lost in such a setup (ease of use, mainly). Compile PHP as webserver module or CGI, and it does not change at all. Compile as application server and call stub module and it runs the architecture I describe. So what are you complaining about? > Remember, the primary concern for PHP is usability and ease of > use, and performance does come in second. Actually, the primary concern for PHP are - it integrates well into our deployment platform - it has reasonable ressource useage - it performs well - and it is easy to learn. Application servers done properly won't harm ease of use at all. In fact, if you want to, you can implement them in a fashing that CGI PHP and mod_php scripts are integrated into an application server setup without any changes at all. Learning curve for the user: About zero. Learning curve for the adminstrator: Just follow manual. From the end users standpoint it is just adding another deployment model - but one with unique performance characteristics! > It's very easy and much cheaper to add more hardware, Adding hardware does not solve the problem of wrong user ids, of to many database connections, and nonpersistent ressources in general. Not at all. > than to hire&train more people, and have longer development > times. In my opinion, the day performance becomes more > important than ease of use, would be the starting day of PHP's > downfall. That day was about 3 months ago. Chris Cartus spelled it out for you in http://www.php-congress.de/2000/slides/managemententscheidungen.ppt Hire him and have it explain to you, if you do not see it from the slides and from my mail. He is right on all counts. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/