Re: Free PHP runtime Accelerator for Linux available

From: Date: Tue, 21 Aug 2001 16:55:44 +0000
Subject: Re: Free PHP runtime Accelerator for Linux available
Groups: php.general 
Request: Send a blank email to php-general+get-63737@lists.php.net to get a copy of this message
Hi Michael, Thanks a lot for your email! I must confess to, for once, not checking the web first and looking other products. I hadn't come across any others and was just aware of the Zend offering, hence putting together the accelerator. Now things are suddenly more interesting :-) I would be suprised if the accelerator didn't come bottom of the performance tables at the moment compared to the others to be honest. Seeing as I hadn't looked at a line of php-4.0.6/Zend code before last Monday, the first milestone was merely to get something that worked at all :-) 6 days later I reached the first version that ironed out all showstoppers that I'm aware of. Intellectual exercise? Of course, what else, but the reason was that I needed a cache. Had I looked at the others then... well I'd have probably still started anyway having seen Zend outstripping the others <g> Looking at the performance stats from John Lim back in January, it seems likely that all non-Zend caches are missing a fundamental trick or two. What do you think? For example, and this may be poor one because apc,bw,bez might all be doing this in one way or another, but when restoring a compiled file it can be that only a fraction of the functions/methods, and even entire classes are ever used. Loading the never used functions and classes and restoring unused static vars initialisers would quite literally be a waste of time. Another thing that comes to mind is that you probably want to ensure that the usual cleaning up of memory that Zend does actually *doesn't* happen quite as completely as it does by default. I actually ask myself - do I want to restore compiled code from shared memory? Do I event want to restore compiled code from web server memory? And the answer is ideally no to both. And of course I don't want to restore from files. Bottom line, I actually don't want to *restore anything* if it requires any memory copying. Ideally I'd like the same hashtables, same function pointers, same static_variables, etc. etc. that were used last time a page was loaded. Not *copies of* these things. My ultimate goal, if I were making this a full time project, would be to 'get' all the state I needed by a single lookup for the value of compiler/executor_globals using the i-number for the root source file in a devno specific structure. No copying of anything. Of course this might be unrealistic, but I'd want to know why, and focus not just how can I speed things up, but how can I eliminate what is slowing me down! Another part of the engine that seems 'fair game' is the executor. One might perhaps reduce the size of CG(class_table) and CG(function_table) for example by switching between tables that contain just the likely or reachable items from certain points in the code. It's also possible to hijack what would normally be fatal errors, regard them as faults rather like a page fault, patch up what caused the error on the fly, such as a function lookup failure, and carry on as though nothing happened. Again, perhaps other cache developers are getting mileage from this, or perhaps there is no mileage in this, or perhaps there is and they are not? And then there's a zend_op->C->nativecode.so optimiser that produces .so files of your scripts when there's nothing else better to be getting on with :-) Nick
From: Michael Kimsal <michael@tapinternet.com> To: PHP Accelerator <php_accelerator@hotmail.com> CC: php-general@lists.php.net Subject: Re: [PHP] Free PHP runtime Accelerator for Linux available Date: Tue, 21 Aug 2001 09:27:53 -0400 Hello Nick, First off, thanks for your contribution. We've not tested it as of yet, but it's always good to see more people getting involved at some level. :) Second, have you compared the mechanism(s) you use against APC or bware? Have you considered perhaps helping with one of those projects instead of starting from scratch? It sounds like this was primarily an intellectual exercise for you to begin with, so I can understand the DIY mindset. However, if you've got many ideas for improving things further (PHP code optimization, reduced CPU time, etc) perhaps helping out with a more established project would benefit everyone more in the long run. Just some thoughts. :) Thanks again Michael Kimsal http://www.tapinternet.com/php/ PHP Training Courses 734-480-9961 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net For additional commands, e-mail: php-general-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net
_________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

« previous php.general (#63737) next »