Re: [PHP] How does the Zend engine behave?
Sean Pringle wrote: The Caching systems such as Zend Cache (not the Optimizer), MMCache, APC, etc are expressly designed to store the tokenized version of the PHP script to be executed. Note that their REAL performance savings is actually in loading from the hard drive into RAM, not actually the PHP tokenization. Skipping a hard drive seek and read is probably at least 95% of the savings, even in the longest real-world scripts. Interesting. If PHP tokenization is such a small cost, what makes a special caching system better than the OS for caching files in memory after the first disk read? APC actually executes the opcodes directly in shared memory, so unlike a disk cache, you are not copying lots of stuff around. APC does need to copy some things down into process-local memory, but most can be left where it is. Disk caches also tend to expire pretty fast because everything your OS does tends to touch the disk and when you application starts eating memory your disk cache is the first to go when things get tight. With a dedicated shared memory segment that won't happen. Things will stay put. It is also possible to run APC in no-stat mode which means it will never touch the disk at all. If you are on an Intel cpu with an older OS like freebsd4, disk-touching syscalls are massively slow and you can gain a lot by skipping the up-to-date stat check on each request and include file. Finally the compiler does more than just tokenize your script. It will cache functions and classes when it can and rewrite the opcodes so these functions and classes won't have to be created at execution time. Of course, that assumes you haven't gone all framework-crazy and made everything dynamic with autoload or weird conditional function and class declarations. If it becomes a runtime decision whether class or a function is declared, or heaven forbid, the same class takes on different signatures based on some runtime condition, then there isn't much the compiler can do to speed that up. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
On Fri, October 27, 2006 12:11 am, Sean Pringle wrote: The Caching systems such as Zend Cache (not the Optimizer), MMCache, APC, etc are expressly designed to store the tokenized version of the PHP script to be executed. Note that their REAL performance savings is actually in loading from the hard drive into RAM, not actually the PHP tokenization. Skipping a hard drive seek and read is probably at least 95% of the savings, even in the longest real-world scripts. Interesting. If PHP tokenization is such a small cost, what makes a special caching system better than the OS for caching files in memory after the first disk read? Your OS caching system doesn't know the difference between data files that may or may not get re-used, and PHP scripts, like your homepage, that are getting the crap beat out of them when you get slash-dotted. The OS caching can build up a history of oft-used files and if you have, say, a hit-song MP3 that's getting downloaded 1000 X a second, is probably the way to go. But if your goal is to get your codebase into RAM so that it can load up what seems like a random distribution of data, a code cache is the way to go. If you're not sure what the hell you're doing, use both and play with the parameters until it's fast enough, then focus on something else. Disclaimer: I am making this answer up with zero real-world experience, no benchmarks, and little theoretical proof. Test it yourself if you want to be certain. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
On Thu, October 26, 2006 8:28 pm, [EMAIL PROTECTED] wrote: Richard Lynch wrote: On Wed, October 25, 2006 11:58 am, [EMAIL PROTECTED] wrote: Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. I doubt that the code is unloaded -- What if you called a function from the first file while you were in the second? I agree it's unlikely, but it's feasible if coded is loaded whenever required. Especially if data and code are separated by the engine, and that's quite likely because of the garbage collection. It's really not that practical to do that separation and unload code objects, when the user could call any function at any time. Particularly with: http://php.net/eval $function = 'myprint'; function myprint ($foo) { print $foo; } $function('Hello World'); Thanks - that's really useful - I didn't realise that the bulk of the saving wasn't in tokenising. It is a very common misconception. I think MOST people actually get this wrong on their first encounter of a code cache. Yes, without a cache, each HTTP request will load a different script. Do you know if, when a cache is used, whether requests in the same thread use the same in-memory object. I.e. Is the script persistent in the thread? Almost for sure, the in-memory tokenized version is not only shared within a thread, but across all threads. Otherwise, your cache would be loading hundreds of copies of each script for all the Apache children. The dispatcher may copy the tokenized script in order to run it with a clean slate, but the source it uses is probably shared RAM. At least, so I presume... Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? If you have a PHP script that is 4M in length, you've done something horribly wrong. :-) Sort of. I'm using Drupal with lots of modules loaded. PHP memory_limit is set to 20MB, and at times 20MB is used. I think that works per request. All the evidence points to that. So 10 concurrent requests, which is not unrealistic, it could use 400MB + webserver overhead. And I still want to combine it with another bit of software that will use 10 to 15MB per request. It's time to think about memory usage and whether there are any strategies to disengage memory usage from request rate. Almost for sure, that 20MB is never actually about the Drupal code itself. Loading in and manipulating an IMAGE using GD, or sucking down a monster record-center from a database, or slurping down a bloated web-page for web-scraping and converting that to XML nodes and ... It's not the CODE that is chewing up the bulk of your 20MB. It's the data. I may rant about OOP code-bloat, but I don't think it's THAT bad :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
Jon Anderson wrote: Take this with a grain of salt. I develop with PHP, but I am not an internals guy... [EMAIL PROTECTED] wrote: Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. Compiled when execution hits them. You can prove this by trying to conditionally include a file with a syntax error: if (false) include('script_with_syntax_error.php'); won't cause an error. Good idea. Secondly, are include files that are referenced, but not used, loaded into memory? I.e Are statically included files automatically loaded into memory at the start of a request? (Of course those where the name is variable can only be loaded once the name has been determined.) And when are they loaded into memory? When the instruction pointer hits the include? Or when the script is initially loaded? If your include file is actually included, it will use memory. If it is not included because of some condition, then it won't use memory. I wonder if that's the same when a cache/optimiser is used. Probably. Maybe I'll check. Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. If you define a global variable in an included file and don't unset it anywhere, then it isn't automatically unloaded, nor are function/class definitions unloaded when execution is finished. Once you include a file, it isn't unloaded later though - even included files that have just executed statements (no definitions saved for later) seem to eat a little memory once, but it's so minimal that you wouldn't run into problems unless you were including many thousand files. Including the same file again doesn't eat further memory. I assume the eaten memory is for something to do with compilation or caching in the ZE. Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. I think that's correct. If you don't have an opcode cache, the script is compiled again for every request, regardless of who requests it. IMO, you're probably better off with PECL/APC or eAccelerator rather than MMCache or Zend Optimizer. I use APC personally, and find it exceptional - rock solid + fast. (eAccelerator had a slight performance edge for my app up until APC's most recent release, where APC now has a significant edge.) Thanks - that's useful to know. Fourthly, am I right in understanding that scripts do NOT share memory, even for the portions that are simply instructions? That is, when the second request arrives, the script is loaded again in full. (As opposed to each request sharing the executed/compiled code, but holding data separately.) Yep, I think that's also correct. Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? Yep. More usually with webserver/PHP overhead. Lastly, are there differences in these behaviors for PHP4 and PHP5? Significant differences between 4 and 5, but with regards to the above, I think they're more or less the same. Thanks Jon. So in summary: use a cache if possible. Late load files to save memory. Buy more memory to handle more sessions. And it's conceivable that when caches are used, different rules may apply. Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
On Wed, October 25, 2006 11:58 am, [EMAIL PROTECTED] wrote: Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. As far as I know, the files are only loaded as execution hits them. If your code contains: ?php if (0){ require 'foo.inc'; } ? Then foo.inc will never ever be read from the hard drive. You realize you could have tested this in less time than it took you to post, right?. :-) Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. I doubt that the code is unloaded -- What if you called a function from the first file while you were in the second? Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. You are correct. The Caching systems such as Zend Cache (not the Optimizer), MMCache, APC, etc are expressly designed to store the tokenized version of the PHP script to be executed. Note that their REAL performance savings is actually in loading from the hard drive into RAM, not actually the PHP tokenization. Skipping a hard drive seek and read is probably at least 95% of the savings, even in the longest real-world scripts. The tokenizer/compiler thingie is basically easy chump change they didn't want to leave on the table, rather than the bulk of the performance win. I'm sure somebody out there has perfectly reasonable million-line PHP script for a valid reason that the tokenization is more than 5% of the savings, but that's going to be a real rarity. Fourthly, am I right in understanding that scripts do NOT share memory, even for the portions that are simply instructions? That is, when the second request arrives, the script is loaded again in full. (As opposed to each request sharing the executed/compiled code, but holding data separately.) Yes, without a cache, each HTTP request will load a different script. Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? If you have a PHP script that is 4M in length, you've done something horribly wrong. :-) Of course, if it loads a 4M image file, then, yes, 2 at once needs 8M etc. Lastly, are there differences in these behaviors for PHP4 and PHP5? I doubt it. I think APC is maybe going to be installed by default in PHP6 or something like that, but I dunno if it will be on by default or not... At any rate, not from 4 to 5. Note that if you NEED a monster body of code to be resident, you can prototype it in simple PHP, port it to C, and have it be a PHP extension. This should be relatively easy to do, if you plan fairly carefully. If a village idiot like me can write a PHP extension (albeit a dirt-simple one) then anybody can. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
On Thu, October 26, 2006 9:33 am, [EMAIL PROTECTED] wrote: If your include file is actually included, it will use memory. If it is not included because of some condition, then it won't use memory. I wonder if that's the same when a cache/optimiser is used. Probably. Maybe I'll check. Almost for sure no PHP opcode cache attempts to load files that *might* be included later. That would be daft. :-) They load the file, tokenize it, and store the opcode output of the tokenizer for later re-execution. Thanks Jon. So in summary: use a cache if possible. Late load files to save memory. Buy more memory to handle more sessions. And it's conceivable that when caches are used, different rules may apply. If your PHP source scripts themselves are chewing up large chunks of RAM, that's pretty unusual... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
Richard Lynch wrote: On Wed, October 25, 2006 11:58 am, [EMAIL PROTECTED] wrote: Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. As far as I know, the files are only loaded as execution hits them. If your code contains: ?php if (0){ require 'foo.inc'; } ? Then foo.inc will never ever be read from the hard drive. You realize you could have tested this in less time than it took you to post, right?. :-) I don't know the extent to which the engine optimises performance, and I know very little about how different versions of the engine deal with the issue, but I guessed it depended on the behaviour of the engine, cache and maybe optimiser, and know/knew I don't know enough... My thinking: for dynamically linked files, one speed optimisation is to load the file before it's needed, at the expense of memory, while continuing execution of the loaded portions. It's easy to do if the filename is static. The code may never be executed, but still takes up space. Some data structures can also be pre-loaded in this way. Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. I doubt that the code is unloaded -- What if you called a function from the first file while you were in the second? I agree it's unlikely, but it's feasible if coded is loaded whenever required. Especially if data and code are separated by the engine, and that's quite likely because of the garbage collection. Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. You are correct. The Caching systems such as Zend Cache (not the Optimizer), MMCache, APC, etc are expressly designed to store the tokenized version of the PHP script to be executed. Note that their REAL performance savings is actually in loading from the hard drive into RAM, not actually the PHP tokenization. Skipping a hard drive seek and read is probably at least 95% of the savings, even in the longest real-world scripts. The tokenizer/compiler thingie is basically easy chump change they didn't want to leave on the table, rather than the bulk of the performance win. I'm sure somebody out there has perfectly reasonable million-line PHP script for a valid reason that the tokenization is more than 5% of the savings, but that's going to be a real rarity. Thanks - that's really useful - I didn't realise that the bulk of the saving wasn't in tokenising. Fourthly, am I right in understanding that scripts do NOT share memory, even for the portions that are simply instructions? That is, when the second request arrives, the script is loaded again in full. (As opposed to each request sharing the executed/compiled code, but holding data separately.) Yes, without a cache, each HTTP request will load a different script. Do you know if, when a cache is used, whether requests in the same thread use the same in-memory object. I.e. Is the script persistent in the thread? Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? If you have a PHP script that is 4M in length, you've done something horribly wrong. :-) Sort of. I'm using Drupal with lots of modules loaded. PHP memory_limit is set to 20MB, and at times 20MB is used. I think that works per request. All the evidence points to that. So 10 concurrent requests, which is not unrealistic, it could use 400MB + webserver overhead. And I still want to combine it with another bit of software that will use 10 to 15MB per request. It's time to think about memory usage and whether there are any strategies to disengage memory usage from request rate. Of course, if it loads a 4M image file, then, yes, 2 at once needs 8M etc. Lastly, are there differences in these behaviors for PHP4 and PHP5? I doubt it. I think APC is maybe going to be installed by default in PHP6 or something like that, but I dunno if it will be on by default or not... At any rate, not from 4 to 5. Thanks. Note that if you NEED a monster body of code to be resident, you can prototype it in simple PHP, port it to C, and have it be a PHP extension. A good idea, but not feasible in this
Re: [PHP] How does the Zend engine behave?
On Thursday 26 October 2006 20:28, [EMAIL PROTECTED] wrote: If you have a PHP script that is 4M in length, you've done something horribly wrong. :-) Sort of. I'm using Drupal with lots of modules loaded. PHP memory_limit is set to 20MB, and at times 20MB is used. I think that works per request. All the evidence points to that. So 10 concurrent requests, which is not unrealistic, it could use 400MB + webserver overhead. And I still want to combine it with another bit of software that will use 10 to 15MB per request. It's time to think about memory usage and whether there are any strategies to disengage memory usage from request rate. Drupal tends to use about 10 MB of memory in normal usage for a reasonable set of modules in my experience, but a crapload more on the admin/modules page because it has to load everything in order to do so. Normally you won't hit that page very often. :-) However, Drupal is deliberately friendly toward APC. I don't recall the stats (I know someone made some pretty graphs at one point, but I can't find them), but simply throwing APC at Drupal should give you a hefty hefty performance boost. I believe APC does cache-one-run-many, so the code, at least, will only be stored in RAM once rather than n times. (Richard is correct, though, that data is generally larger than code in most apps.) Also, search the Drupal forums for something called Split mode. It was something chx was putting together a while back. I don't know what it's status is, but he claimed to get a nice performance boost out of it. Cheers. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
The Caching systems such as Zend Cache (not the Optimizer), MMCache, APC, etc are expressly designed to store the tokenized version of the PHP script to be executed. Note that their REAL performance savings is actually in loading from the hard drive into RAM, not actually the PHP tokenization. Skipping a hard drive seek and read is probably at least 95% of the savings, even in the longest real-world scripts. Interesting. If PHP tokenization is such a small cost, what makes a special caching system better than the OS for caching files in memory after the first disk read? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] How does the Zend engine behave?
Hi, I'm using PHP 4.x and I'm trying to understand a bit about memory usage... Firstly, when I say 'include files' below, I mean all forms, include, require and the _once versions. That said, when a script runs and it's made of several include files, what happens? Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. Secondly, are include files that are referenced, but not used, loaded into memory? I.e Are statically included files automatically loaded into memory at the start of a request? (Of course those where the name is variable can only be loaded once the name has been determined.) And when are they loaded into memory? When the instruction pointer hits the include? Or when the script is initially loaded? Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. Fourthly, am I right in understanding that scripts do NOT share memory, even for the portions that are simply instructions? That is, when the second request arrives, the script is loaded again in full. (As opposed to each request sharing the executed/compiled code, but holding data separately.) Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? Lastly, are there differences in these behaviors for PHP4 and PHP5? Many thanks, Jeff -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
Take this with a grain of salt. I develop with PHP, but I am not an internals guy... [EMAIL PROTECTED] wrote: Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. Compiled when execution hits them. You can prove this by trying to conditionally include a file with a syntax error: if (false) include('script_with_syntax_error.php'); won't cause an error. Secondly, are include files that are referenced, but not used, loaded into memory? I.e Are statically included files automatically loaded into memory at the start of a request? (Of course those where the name is variable can only be loaded once the name has been determined.) And when are they loaded into memory? When the instruction pointer hits the include? Or when the script is initially loaded? If your include file is actually included, it will use memory. If it is not included because of some condition, then it won't use memory. Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. If you define a global variable in an included file and don't unset it anywhere, then it isn't automatically unloaded, nor are function/class definitions unloaded when execution is finished. Once you include a file, it isn't unloaded later though - even included files that have just executed statements (no definitions saved for later) seem to eat a little memory once, but it's so minimal that you wouldn't run into problems unless you were including many thousand files. Including the same file again doesn't eat further memory. I assume the eaten memory is for something to do with compilation or caching in the ZE. Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. I think that's correct. If you don't have an opcode cache, the script is compiled again for every request, regardless of who requests it. IMO, you're probably better off with PECL/APC or eAccelerator rather than MMCache or Zend Optimizer. I use APC personally, and find it exceptional - rock solid + fast. (eAccelerator had a slight performance edge for my app up until APC's most recent release, where APC now has a significant edge.) Fourthly, am I right in understanding that scripts do NOT share memory, even for the portions that are simply instructions? That is, when the second request arrives, the script is loaded again in full. (As opposed to each request sharing the executed/compiled code, but holding data separately.) Yep, I think that's also correct. Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? Yep. More usually with webserver/PHP overhead. Lastly, are there differences in these behaviors for PHP4 and PHP5? Significant differences between 4 and 5, but with regards to the above, I think they're more or less the same. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How does the Zend engine behave?
On Wednesday 25 October 2006 14:48, Jon Anderson wrote: Take this with a grain of salt. I develop with PHP, but I am not an internals guy... [EMAIL PROTECTED] wrote: Are the include files only compiled when execution hits them, or are all include files compiled when the script is first compiled, which would mean a cascade through all statically linked include files. By statically linked files I mean ones like include ('bob.php') - i.e the filename isn't in a variable. Compiled when execution hits them. You can prove this by trying to conditionally include a file with a syntax error: if (false) include('script_with_syntax_error.php'); won't cause an error. Secondly, are include files that are referenced, but not used, loaded into memory? I.e Are statically included files automatically loaded into memory at the start of a request? (Of course those where the name is variable can only be loaded once the name has been determined.) And when are they loaded into memory? When the instruction pointer hits the include? Or when the script is initially loaded? If your include file is actually included, it will use memory. If it is not included because of some condition, then it won't use memory. Are included files ever unloaded? For instance if I had 3 include files and no loops, once execution had passed from the first include file to the second, the engine might be able to unload the first file. Or at least the code, if not the data. If you define a global variable in an included file and don't unset it anywhere, then it isn't automatically unloaded, nor are function/class definitions unloaded when execution is finished. Once you include a file, it isn't unloaded later though - even included files that have just executed statements (no definitions saved for later) seem to eat a little memory once, but it's so minimal that you wouldn't run into problems unless you were including many thousand files. Including the same file again doesn't eat further memory. I assume the eaten memory is for something to do with compilation or caching in the ZE. Thirdly, I understand that when a request arrives, the script it requests is compiled before execution. Now suppose a second request arrives for the same script, from a different requester, am I right in assuming that the uncompiled form is loaded? I.e the script is tokenized for each request, and the compiled version is not loaded unless you have engine level caching installed - e.g. MMCache or Zend Optimiser. I think that's correct. If you don't have an opcode cache, the script is compiled again for every request, regardless of who requests it. IMO, you're probably better off with PECL/APC or eAccelerator rather than MMCache or Zend Optimizer. I use APC personally, and find it exceptional - rock solid + fast. (eAccelerator had a slight performance edge for my app up until APC's most recent release, where APC now has a significant edge.) Fourthly, am I right in understanding that scripts do NOT share Fifthly, if a script takes 4MB, given point 4, does the webserver demand 8MB if it is simultaneously servicing 2 requests? Yep. More usually with webserver/PHP overhead. Unless you're using an opcode cache, as I believe some of the are smarter about that. Which and how, I don't know. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php