Thanks for taking the time for your comprehensive repsonse! > However, given your programming philosophy so far, and the fact that you > are worried about 7ms and that you specifically requested some kind of > shared memory space in PHP, you should Read This: > http://us4.php.net/manual/en/ref.sem.php > > That pretty much is exactly what you asked for. > > Be forewarned that few PHP scripters have needed this stuff, and it's not > anywhere near as hammered on (read: debugged) as the other options above. I had the thought of using shared memory but I've found a scarce supply of introductory material and examples on the subject. The documentation assumes a level of familiarity with shared memory that I don't have, so I'm struggling. Examples of how to store and retreive a set of large multidimensional arrays to/from shared memory would be wonderful to look at, if you have some pointers to articles/books/etc I am also curious if the the shared memory solution would be a significant performance improvement, since, AFAIK, the data is serialized/unserialized for storage/retreival. Since the Zend Accelerator already uses a shared memory cache for the intermediate code, would using my own shared memory be any different? Consider that my global variable definition scripts are nothing more than giant unserialize statements. (Incidentally, I've benchmarked the difference between big unserialize statements and big PHP code array definition statements and found almost no difference, only a marginal improvement in performance using PHP code instead of unserialize on long strings.) > > Additionally, there are > > a large number of function definitions (more than 13,000 lines of code > > in all just for these global definitions). > > You should look into breaking these up into groups of functionality -- I'm > willing to bet you could segment these and have many pages that only call > in a few functions. That is good practice, I know i've been a bit lazy in that respect :) However, it is the variable definitions (big arrays) that take the most significant time, executing all the function definition code is actually only a small fraction of the time taken to parse the arrays, so it's a secondary concern, though you are right I should sit down and rework my includes so I'm only bringing in what I need. I'll set aside a week for that :) > So if what your application mostly does is load in all this data and > respond to requests, you could write a *SINGLE* PHP application which > listened on port 12345 (or whatever port you like) and responded with the > data requested. Like writing your own web-server, only it's a > _________-server where you get to fill in the blank with whatever your > application does. Please see my repsonse to Manuel Lemos and his suggestion to run a SOAP server. Basically my concern is the lack of having a multi-process/forking server to handle concurrent incoming requests (which may or may not be a problem - not sure). We're talking about a persistent PHP server (SOAP or otherwise), and I'm having trouble groking how that would work in an environment with many concurrent requests. (Other than, of course, running a PHP SOAP server inside Apache which brings me back to square one :) > Actually, Zend and others could be interested in your comparisons of > "with" and "without" cache... If folks are interested in my benchmarks I could spend some time and put together a summary. Incidentally I did end up doing some comparison of cached code and uncached code because I unwittingly had the accelerator turned off for while until I realized it :) > Hope that helps... Almost feel like I ought to invoice you at this point :-) :) Thanks for the pro bono consulting, you have indeed helped! Regards, /josh w. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
