Re: Function caching...

Kristian Koehntopp wrote: > Jacob Verhoeks wrote: > > The performance problem is not with executing but with the loading of the > > code. We are currently developing a application server in php. That will be > > loaded only once. > 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. > Another problem is the setup time for large data structures, for > example a large network of objects representing an entity > relationship model by proxy or similar abstraction layers. PHP is absolutely, positively, the wrong place to do this. 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. > If > 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. Certainly, cases can be made to induce the load time of any application to a painfully slow speed, but that's part of the design goals. I can't, offhand, think of any reason to use abstraction if *execution speed* is the goal. Abstractions speeds up development, maintenance, and ease of use, at the _cost of execution speed_. > Even if you just revive the dead object network from > serialization this will slow you down. Right. So don't use the objects. This has nothing to do with PHP, it has to do with design philosophy. OO is simply slower in execution because each object is loaded down with dead-weight, 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.....and this is on _top_ of the abstraction layer provided by using PHP scripting. Quite simply, designing applications for the web is completely *unrelated* to design principles for desktop applications. If you are trying to combine the two, you'll likely wind up with the ASP problem: Unweildy workarounds to simulate the design of a desktop application. On a desktop, where it's considered OK to use 100% of the CPU for a program load, your object overhead will be less costly to the user. But on a server, with multiple users, you need to either massively power the server, or change the design philosophy. On a desktop, you can assume the next action will be from the same user. On a web server, your user may not come back over the next 3,000 transactions, so you're tracking *thousands* of inactive variables and sessions.... > 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. > On the other hand, you are running in a > different Apache module each time you are being called, making > it impossible for you to reuse database connections, keeping > cursors between calls and the like. That is, the process split > of your web application is along the wrong lines. > Some people in #php.de are coding at > application servers written in PHP. These beasts communicate > with the web server using shared memory. They aren't > multithreaded which is why they need to prefork themselves, > turning them into memory hogs. A proper native implementation is > needed instead. Uh, I would say that your design is on the "wrong lines". A web language has a run life of *one page*. There are ways of quickly reusing the database connections, but the idea of passing a cursor from page to page is just plain unfortunate design. 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? Now add connection abstraction to 5,000 users, with 20 objects loaded per users... it becomes a massive memory hog. This is what you're *already discovering* in using a shared memory space, that this approach turns a formely efficient server into a massive beast. Without threads, it's bigger, but with threads, it's still a hog. Sure, you can do this with 8 CPU servers, loaded with 8GB of RAM. But that's not what PHP, or apache, or the web, is good for. 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?) -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.