APC and others don't exist in PHP7 cause PHP7 be fast
Details
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Maniphest Tasks
- T9640: Make Phabricator compatible with PHP7
Before changes saw setup warnings in PHP7, after changes, no more warnings
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- hide-exts-7
- Lint
Lint Warnings Severity Location Code Message Warning src/applications/cache/spec/PhabricatorDataCacheSpec.php:64 TXT3 Line Too Long Warning src/applications/cache/spec/PhabricatorOpcodeCacheSpec.php:191 TXT3 Line Too Long - Unit
Tests Passed - Build Status
Buildable 9040 Build 10628: arc lint + arc unit
Event Timeline
Comment Actions
Drupal ran into a similar issue with APC not existing when they try to run APC unit tests.
https://www.drupal.org/node/2554065
Comment Actions
Instead, PhutilDataCacheSpec and PhutilOpcodeCacheSpec should return appropriate cache specs.
The Opcode spec might be a new spec like "builtin" or whatever the PHP7 engine is called formally.
We benefit significantly from a data cache, and should not ignore these warnings. If a data cache is not currently available in PHP7, we should raise a setup warning that performance in PHP7 will be poor and running under PHP7 is discouraged, and decline to support PHP7 formally until a data cache is available.
Comment Actions
When I have some time Ill implement a new DataCacheSpec, I chatted in ##php and asked about the OPCache, its enabled by default (like in PHP 5.5+) and there is currently no other available caching extensions.
Due to the perf improvements in PHP7, im not sure that Phabricator will actually be that slow without specific caching extensions.
Comment Actions
Among other things, the data cache stores the result of setup checks, which are mostly not PHP code and are largely not impacted by PHP's performance.
On the first request, we run a lot of commands like which which, git --version, hg --version, etc., and store the "yes, setup checks are good" result in the data cache. We can't store this result in a different cache because it's important to re-run these checks after a webserver restart (many depend on configuration -- for example, changing environment.append-paths can change the outcome of these checks).