Re: Function caching...

Ron Chmara wrote: > > The current performance limitations in PHP come from multiple > > design limitations. > > Keep in mind that some limitations are apache, some are the > web, some are PHP. These limitations ARE. I do not care where they come from. There exists solutions around these limitations. Tried solutions. They usually work the way I described them in my previous mail to Zeev. They do work that way for a reason. I explained why, too. > If you want speed, abstractions are the wrong approach to take. > Scripting languages, creating abstractions, to serve over web > pages?... ouch. Write it in C, not as objects in PHP. That buys me what? I am still running under the wrong UID. I still lose my state variables at the end of the page, including all file and network (database) handles. I am still unable to have persistent ressources, and I am still unable to share ressources among control flows as long as these flows of control are in different processes as they are in the Apache model (The current Apache model is not broken, it is very resistant against failure. The brokenness comes from the attempt to run large amounts of code inside the Apache process model instead of creating dedicated persistent code execution processes called application servers). > > this network of objects is rebuilt from scratch in each > > instantation of your script, it will take significant amounts of > > time. > I can't think of a good reason to design a fast application in > this way. You have been doing small projects without much backoffice integration and much code reuse in the past, and these were not sensitive to security issues. I can think of many reasons to design applications that way, and so can Ulf, and so can the Twisd people (they worked around their setup time penalty by going to C++, but still they lose context at the end of each page). Going to C or C++ is not a solution, if there is a chance to have a PHP framework with a different execution model that can do the same. PHP code is much, much cheaper per line than C++ code. > Abstractions speeds up development, maintenance, and ease > of use, at the _cost of execution speed_. You are using abstactions wrongly, or in the wrong execution context (for example, you are throwing initalized execution contexts away at the end of each page when they are perfectly reuseable). > > Even if you just revive the dead object network from > > serialization this will slow you down. > > Right. So don't use the objects. And that does buy me what? Setup times from the serialization of the equivalent array network serialization and unserialization AND it adds namespace management problems. This is hardly a good design decision. > OO is simply slower in > execution because each object is loaded down with dead-weight, Done properly, an object is exact the same size as a hash, plus a single pointer to its class description. This is hardly dead-weight. Also, you need a class description listing all possible slots, and all object functions with their signatures and function pointers. You need such a class description exactly once, as it is shared between instances of that object. > with portions that are going unused. If you are loading up an > application with a massive abstraction layer, with functions > that are uncalled in the 1-2 seconds of the page load, it > won't work quickly.. Don't load. Have present. Don't duplicate load. Code is r/o and shareable between multiple control flows (threads, processes executing the same program). Simply design a scaleable and useful process model and execute within that process model, and not within the context of a CGI program or webserver. > Quite simply, designing applications for the web is completely > *unrelated* to design principles for desktop applications. Not at all. It is in fact exactly the same once you get the hang of it. That's what PHPLIB has tried to teach you for the past few years, and that's what you can learn von PHP4 sessions today, if you missed PHPLIB. Or go to Apple, have a look at WebObjects. Or go to Microsoft, have a look at ASP+ and .NET and their Visual Studio .NET if you still do not understand. There is no difference between traditional applications and web applications that cannot easily be hidden in an abstaction layer. A pretty small abstraction layer even. You only run into problems if you try to do stupid things, like the ones I listed previously (running under the wrong UID, not being able to share what should be shareable, and throwing away perfectly good code you are going to reuse in the next second anyway) and like the ones done by beginners (thinking that the terminal/browser is trustworthy and rely on state keeping or input validation in the terminal). Once you can keep state (using PHPLIB or PHP 4 sessions), web applications are just normal event driven applications like all others, executed in an awkward and inefficient fashion. Application servers are the means to end this awkwardness. > power the server, or change the design philosophy. On a > desktop, you can assume the next action will be from the same > user. I am not talking desktop. I am talking middleware servers and backoffice integration. 3000 concurrent users or open transactions are not really a problem unless you do it backwards and spend time compiling instead of comitting. > > The third problem is the indivisible user rights if you are > > running as a part of the web server, as Apache modules do. You > > always act as wwwrun. > > This is a security feature. The user can act as any given user, > but if you are accepting internet connections over port 80, you > have absolutely no way of determining who is, and isn't, actually > sending them. "Session" technology to supposedly handle this > is basically just a cookie at the client, passed through to > the logic in various fashions. No, it doesn't matter whose web > "sessions" you're using, they all pretty much work this way, > by passing a variable or two, and shutting down the connection > to the user. Why? Because maintaining hundred of active, open, > single, connections is just plain too resource-intensive for > the payoff. You are mixing several things up here. You are going nowhere as long as you do this. We have - user identities with in the application. - user identities used by the application to authenticate itself against a database. - user identities used by the application to identitfy and authenticate itself against the operating system (i.e. while performing file operations). In the Apache process model, running mod_php, your PHP code is using arbitrary identities and authentication mechanisms in the application. PHPLIB offers you any number of them. Additionally, you can use multiple identities when authenticating against the database at the expense of a largely increased number of connections to the database (-> common problem in transaction heavy environments with many users -> solution is middleware transaction monitors bundling transactions and reusing connections -> this is what can easily be done in PHP userland in threaded application servers, but is impossible in the current model). And finally, ALL your scripts are running under the identity wwwrun against the operating system and you cannot change that, because you are running in the wrong context (webserver instead of own). That's the reason for safe_mode, but safe_mode isn't. safe_mode is a lot of work, and any number of remaining holes. The job of safe_mode is already done by the operating system, or it would have been done, if you were running under a distinct UID. > How many > active cursors can your DBMS handle? 128? Okay, if 5,000 users > hit page one, and do nothing for the next 2 minutes, you now > have 5,000 active db sessions, 5,000 cursors. Care to imagine > the overhead of such a thing? Have you ever heard the words "transaction monitor" or "middleware"? Do you really think these are new problems which have never been handled by anyone before? > Might I recommend you investigate aolserver, which has *some* of > these features, or a commercial server product designed to > emulate this kind of workflow, and get some really burly hardware > (or rethink the design?) PHP/Zend is a commercial product. So are Java application servers. So are ASP+/.NET and Visual Studio .NET. So are Apple WebObjects. All of them, but one, address these problems and offer solutions. Can you spot the one missing? 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/