![]() ![]() This is really good progress, but introduces a few things to keep in mind. In this test, include() was about 4x faster than file_get_contents(). The results for include() looked so much better this time: include() vs file_get_contents(), increased memory_consumption, max_accelerated_files The default WordPress installation ships with about 1k PHP files, many of which were likely in the opcache as well. The second option I spotted was opcache.max_accelerated_files and it defaulted to exactly 10,000 files. php files was closer to 400mb, and sure, they might somehow be optimized before storing in opcache, but probably not to 128 mb. The mory_consumption defaults to 128 megabytes. So I dug around the opcache runtime configuration settings and found a few relevant limits, which I might have been been hitting. During the run above, only about 8700 files were in cached by Zend Opcache, which means the remaining 1300 still had to be read from disk (memory), parsed, compiled, etc. I added the opcache_is_script_cached() function to my loop, and counted the total number of cached scripts, to make sure it was 10,000. Increased memory consumption and max accelerated files ![]() This didn’t look too great so I started playing around with the Opcache configuration. Much better this time, however still slower than file_get_contents(). We can see this from the second run: include() vs file_get_contents(), 10,000 files, second run So the next time the same file is requested, it does not need to be parsed or compiled, the result is already available in memory. However, after it has done so, the compiled PHP opcode is placed into a special opcode cache in shared memory, by the Zend Opcode extension, which is pretty standard nowadays across most hosts. ![]() Honestly I expected it to be slower, but not by this much.Īs opposed to file_get_contents(), which simply reads the file from disk (or the kernel’s page cache in this case), on a fresh run include() does the exact same thing, but in addition to that, it needs to parse the file as PHP code, and compile it. This first run showed include() to be over 7 times slower than file_get_contents(). include() vs file_get_contents() first run The first run wasn’t great for include(). php files were all in the kernel page cache, so we’re eliminating disk IO, reading the files directly from memory in both cases: $ fincore raw/* | wc -l $rounds = 10000 įile_put_contents( "cache/include/item.php" ) īefore running the benchmark.php file I made sure that both the. I made sure they’re all unique too, just to make sure there’s no cheeky plays on both sides (used str_shuffle too in some tests). I wrote a create.php script which simulated some cache files, strings with HTML. The tested PHP version was 7.4.3 with Zend Engine v3.4.0 and Opcache v7.4.3. I wanted to make sure my benchmark test data fit into memory. I provisioned a new 4-core 8GB server on DigitalOcean using Sail CLI. One of these options is whether the PHP include() might be a better alternative to the regular file_get_contents() or readfile/fpassthru functions. However, even with just the filesystem, there are quite a few different options to consider. I’ve already decided that the filesystem is going to be the primary storage method and ran some benchmarks against Redis and Memcached, the results were satisfying. I’m building a simple page caching plugin to ship with Sail CLI for WordPress. TLDR: include() can be significantly faster than file_get_contents(), if certain conditions are met. ![]() Hey there! I'm currently working on a CLI tool to deploy WordPress apps to DigitalOcean. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |