Wow thanks for the helpful breakdown.
> PHP's model is to be completely sandboxed such that every request is
> completely separate from every other. Having a persistent interpreter
> as you describe would break that rule and break the infinite horizontal
> scalability model of PHP.
Understood. A persistent interpreter is a whole different approach. I
appreciate your perspective on that, it helps me to reconsider overall
what I'm doing and why I want to do it :)
> Of course, there is nothing that prevents you from storing persistent
> data somewhere more permanent. If it is just simple read-only data you
> have a lot of options. For example, you could put them in a .ini file
> that is only loaded on Apache startup and use get_cfg_var() to fetch
> them. If you compile PHP with the --with-config-file-scan-dir switch to
> configure a configuration scan directory you can just drop your own ini
> file in that directory and it will be read on startup. This is just
> key=value pairs and not PHP code, of course.
I'm dealing with large multidimensional arrays, like this:
$categories = array (
1 => array (
'name' => 'Autos',
'depth' => 1,
...
:(
> If you need to do something fancier you can stick things in shared
> memory. Many of the accelerators give you access to their shared memory
> segments. For example, the CVS version of pecl/apc provides apc_store()
> and apc_fetch() which lets you store PHP datatypes in shared memory
> directly without needing to serialize/unserialize them.
That pecl/apc feature sounds like a great, cheap solution to my giant
global variable definition problem, which takes the biggest single chunk
of parsing time. The key AFAICS is avoiding the (un)serialization time.
I'd love to see an example if you have one, just to show me a target to
aim for. I'm unfamiliar with C / reading C source code and with shared
memory so I'm having a tough time figuring out how to use that feature.
(It doesn't solve the function definition problem but that is OK - the
functions take FAR less time to parse than the global variable
definitions.)
> And finally, the big hammer is to write your own PHP extension. This is
> a lot easier than people think and for people who are really looking for
> performance this is the only way to go. You can write whatever code you
> want in your MINIT hook which only gets called on server startup and in
> that hook you can create whatever persistent variables you need, pull
> stuff from a DB, etc. At the same time you will likely want to pull
> some of your heavier business logic identified by your profiling into
> the extension as well. This combination of C and PHP is extremely hard
> to beat performance-wise regardless of what you compare it to.
This is something I'm VERY interested in. It is encouraging to hear that
it is easier than I expect, and I will look into it further. Based on
the responses from the list I've gotten, this seems like the most
promising "total" solution. Any outstanding books/articles on the topic,
considering I'm not a C programmer?
Thanks again
/josh w.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
