Daniel Kolbo wrote:
Hello PHP-hipsters,
I am not sure how to phrase these questions so please bare with me.
I am thinking about performance of a single web server running Apache
(non-cluster) with php as a module.
I have a web app that requires the same php objects(classes) for each
http request.
First, I would like to have the web server keep these object/class
definition files (code) permanently in the memory so the php engine does
not have to keep loading and destroying these objects. Is this
possible? Maybe the php engine is already smart enough to handle this.
I imagine the engine is smart enough to not load the same class
definition into memory for the same http request, but I'm not sure if
the engine is smart enough to recognize that a class definition is
already in the memory from a different http request.
PHP maintains a "shared nothing" philosophy:
http://en.wikipedia.org/wiki/Shared-nothing_architecture
This means there are no application variables in PHP. To accomodate
something of this nature you will need to use a memory cache like APC or
whatnot.
Second, furthermore, say two different http requests actually
instantiate identical objects. Will both of these identical objects
require their own space in the memory, or is the php engine smart enough
to point both objects to the same memory (until something happens to one
of the objects making it different than the other)? If not, i guess this
is where the idea of caching comes in, and i have to be that smart one
to define the unique keys...
You would have two copies.. because PHP doesn't share like this. In
fact, I do believe shared memory would still require a copy of the
shared memory since I imagine marshalling the data back and forth
between shared memory and PHP native datatype would occur.
Third, when one caches php code using something like memcache, what is
actually being cached: the human readable php, the parsed php, the
serialized php (not really sure what this is), the raw cpu/assembly
instructions, etc...?
Usually the compiled bytecode is stored either in memory or on the
filesystem if memory is lacking (less used caches would get punted to
the filesystem). This saves the ocmpilation stage at the least which can
be quite onerous for large libraries. And if everything fits in memory
then you can really save on time.
Fourth, where does this cached data live - on the server's hard drive or
in the server's memory (assuming we have enough memory)?
One or the other or both. Depends on your settings and the current
memory needs.
I assume one of the ideas behind the cache is to by-pass the php parser
and instead just regurgitate the pre-chewed food and spit it out to
apache. Thus, the memcache would only be storing the php output. Is
this line of reasoning correct? And ideally it would be best to have
this prechewed code sitting in the memory, but can I control this?
It's a different kind of chache that stores the output... unless you
meant the output of the parse stage.
Just to be clear, I am familiar with the idea behind setting a unique
key for the cache and all that. Also, i am not referring to client side
caching.
Well thanks for sticking with me, as I'm trying to learn these concepts.
Any comments, answers, explanations would be most welcomed.
Hope I've been of help.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
