tl;dr discussion start "How/whether MediaWiki could use ZendOptimizuerPlus"
Since a short time
* ZendOptimizerPlus (Opcode cache; source [4])
is under PHP license and planned to be integrated in PHP 5.5. The former restrictions of this program (closed-source etc.) appear to be gone, so I'd like to open discussions how MediaWIki could be adapted to make use of it.
Because APC does not work with PHP 5.4, (or APC is beta for PHP 5.4), I wanted to make use of the new ZendOptimizer with PHP 5.4 ...
* but MediaWiki apparently does not work with that. ( CACHE_ACCEL )
*Who knows more ?* and could help to get the Zend cache working and APC replaced ? Or is this not possible, because Zend is only for opcode caching ??
MediaWiki pages [1,2] should be /*revisited *//*and updated*/ according to current knowledge and version /*by cache experts*/
Tom
[1] https://www.mediawiki.org/wiki/Manual:Cache [2] https://meta.wikimedia.org/wiki/PHP_caching_and_optimization#PHPA_or_Zend_Op... [3] https://wiki.php.net/rfc/optimizerplus [4] https://github.com/zend-dev/ZendOptimizerPlus
[3}] says: "This RFC proposes integrating the Zend Optimizer+ component into the Open Source PHP distribution. Optimizer+ is the fastest opcode cache available for PHP, and presently supports PHP 5.2 through 5.5, with public builds available for PHP 5.2 through 5.4. It was originally developed in 1998 and was the first opcode cache available for PHP.
Presently, Optimizer+ is a closed-source, yet free-for-use component. As a part of implementing this RFC - Zend will make the source code of Optimizer+ available under the PHP License, so that it can become an integrated part of PHP with no strings attached. Once that happens, community contribution would be welcome exactly like it is with any other PHP component, and the component will be governed by the exact same processes (RFC et. al) that are employed by the PHP community."
On Thu, Mar 21, 2013 at 10:14 AM, Thomas Gries mail@tgries.de wrote:
tl;dr discussion start "How/whether MediaWiki could use ZendOptimizuerPlus"
Since a short time
- ZendOptimizerPlus (Opcode cache; source [4])
is under PHP license and planned to be integrated in PHP 5.5. The former restrictions of this program (closed-source etc.) appear to be gone, so I'd like to open discussions how MediaWIki could be adapted to make use of it.
Because APC does not work with PHP 5.4, (or APC is beta for PHP 5.4), I wanted to make use of the new ZendOptimizer with PHP 5.4 ...
- but MediaWiki apparently does not work with that. ( CACHE_ACCEL )
*Who knows more ?* and could help to get the Zend cache working and APC replaced ? Or is this not possible, because Zend is only for opcode caching ??
MediaWiki pages [1,2] should be /*revisited *//*and updated*/ according to current knowledge and version /*by cache experts*/
You're confusing opcode caching with shared memory caching. Having the Zend Optimizer doesn't prohibit you from using APC's shared memory caching. And since Zend Optimizer doesn't do shared memory functionality, there's no "support" that needs to be added anywhere (now, if they introduce such a feature, that's another story).
-Chad
Am 21.03.2013 15:23, schrieb Chad:
You're confusing opcode caching with shared memory caching.
thanks, as already mentioned, I anticipated that difference.
Having the Zend Optimizer doesn't prohibit you from using APC's shared memory caching.
But APC has issues with PHP 5.4 . What can we MediaWiki developers do to get this (APC) working with PHP 5.4+
@all Has someone PHP 5.4 and MediaWiki core/master */WITH APC/* working ?
And since Zend Optimizer doesn't do shared memory functionality, there's no "support" that needs to be added anywhere (now, if they introduce such a feature, that's another story).
+1 Wouldn't that be an improvement, can you contact these people ? I found, that APC is a "must have" for larger MediaWikis, and would like to see further methods supported in the core or by extensions.
Chad: thanks for your swift answer which confirms my view, even when I wasn't very clear in my original mail.
On Thu, Mar 21, 2013 at 10:42 AM, Thomas Gries mail@tgries.de wrote:
Am 21.03.2013 15:23, schrieb Chad:
You're confusing opcode caching with shared memory caching.
thanks, as already mentioned, I anticipated that difference.
Having the Zend Optimizer doesn't prohibit you from using APC's shared memory caching.
But APC has issues with PHP 5.4 . What can we MediaWiki developers do to get this (APC) working with PHP 5.4+
Nothing, unless someone wants to contribute upstream with patches or bug reports.
And since Zend Optimizer doesn't do shared memory functionality, there's no "support" that needs to be added anywhere (now, if they introduce such a feature, that's another story).
+1 Wouldn't that be an improvement, can you contact these people ? I found, that APC is a "must have" for larger MediaWikis, and would like to see further methods supported in the core or by extensions.
Sure, it'd be an improvement--go ahead and file a bug wherever it belongs upstream (github?). If and when they decide to implement it, *then* would be the time to make MW changes :)
-Chad
Am 21.03.2013 15:57, schrieb Chad:
Sure, it'd be an improvement--go ahead and file a bug wherever it belongs upstream (github?). If and when they decide to implement it, *then* would be the time to make MW changes :)
Where can I read more (and can then refer to it) about how MediaWiki uses the APC as memcache? I found some pages (see my other mail), but this wasn't detailed enough.
Do I have to look for the MediaWiki source module/memcache API? Where ?
On Thu, Mar 21, 2013 at 4:02 PM, Thomas Gries mail@tgries.de wrote:
Do I have to look for the MediaWiki source module/memcache API? Where ?
It's called BagOStuff.
Bryan
Just to be clear, APC will not work in PHP 5.5 at all. It actually conflicts with Zend Optimizer+, and you cannot use both at the same time.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Trying to clarify:
APC can do two things: 1) Keep the compiled php opcodes, so php execution is faster. 2) Allow the application to store values in the web server memory (kept accross requests).
ZendOptimizer only does 1.
MediaWiki only needs to be changed for 2, since 1 is done automatically by all php opcode cache.
You can't use 2 once you have several servers. An alternative for 2 is to use memcached or another cache that allows to be accessed from multiple servers.
The «APC is a "must have" for larger MediaWikis» is due to 1. In fact, wikimedia is not using APC for 2, but memcached.
Am 22.03.2013 12:16, schrieb Platonides:
Trying to clarify:
APC can do two things:
- Keep the compiled php opcodes, so php execution is faster.
- Allow the application to store values in the web server memory (kept
accross requests).
ZendOptimizer only does 1.
MediaWiki only needs to be changed for 2, since 1 is done automatically by all php opcode cache.
You can't use 2 once you have several servers. An alternative for 2 is to use memcached or another cache that allows to be accessed from multiple servers.
The «APC is a "must have" for larger MediaWikis» is due to 1. In fact, wikimedia is not using APC for 2, but memcached.
Hi,
thanks for your clarification (for me, this was almost clear, but it's often difficult for me to explain exactly what I want). Your last info is perfect, should also go the mentioned mediaWiki pages.
My user story:
As an admin, when I upgrade my PHP from 5.3.x to PHP 5.4.x, and when I cannot or do not want make use of APC because this is not working with PHP 5.4.x. and when I have successfully compiled the present ZendOptimizerPlus from github and when I have successfully compiled the present PHP 5.4.x from php.net and when I have successfully made the necessary changes in php.ini and php runs with it,
I have to change CACHE_ACCEL to CACHE_NONE in my LocalSettings.php, and will still enjoy opcode caching by ZendOptimizerPlus, but have no memory cache - currently.
Is this correct ? Can the setup be improved, and how ?
On Fri, Mar 22, 2013 at 7:39 AM, Thomas Gries mail@tgries.de wrote:
I have to change CACHE_ACCEL to CACHE_NONE in my LocalSettings.php, and will still enjoy opcode caching by ZendOptimizerPlus, but have no memory cache - currently.
Is this correct ? Can the setup be improved, and how ?
Yes, this is correct. It can be improved by setting up a memcached server (it's quick and easy, and in small wikis can even be run on the same server as the web server, though not recommended for larger setups) and then using that as your cache. As an alternative, you can also use CACHE_DB, which will use the database for caching, although that doesn't really help much since a cache miss usually means a DB query anyway.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On 2013-03-22 9:20 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
On Fri, Mar 22, 2013 at 7:39 AM, Thomas Gries mail@tgries.de wrote:
I have to change CACHE_ACCEL to CACHE_NONE in my LocalSettings.php, and will still enjoy opcode caching by ZendOptimizerPlus, but have no memory cache - currently.
Is this correct ? Can the setup be improved, and how ?
Yes, this is correct. It can be improved by setting up a memcached server (it's quick and easy, and in small wikis can even be run on the same
server
as the web server, though not recommended for larger setups) and then
using
that as your cache. As an alternative, you can also use CACHE_DB, which will use the database for caching, although that doesn't really help much since a cache miss usually means a DB query anyway.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Some people have claimed that CACHE_DB might even slow things down compared to CACHE_NONE when used as main cache type (cache db is still better than cache none for slow caches like the parser cache). Anyhow you should do profiling type things when messing with caching settings (or any performance settings) to see what is effective and what is not.
-bawolff
On Fri, Mar 22, 2013 at 9:38 AM, Brian Wolff bawolff@gmail.com wrote:
Some people have claimed that CACHE_DB might even slow things down compared to CACHE_NONE when used as main cache type (cache db is still better than cache none for slow caches like the parser cache). Anyhow you should do profiling type things when messing with caching settings (or any performance settings) to see what is effective and what is not.
-bawolff
Wouldn't be surprised. ;) The only problem is that with CACHE_NONE, many things (specifically, throttling mechanisms) won't work since the cache isn't persistent across requests.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
just one message, just arrived:
http://php.net/archive/2013.php#id2013-03-21-1
PHP 5.5.0 beta1 available 21-Mar-2013
The PHP development team announces the release of the first beta of PHP 5.5.0. This release is the first to include the Zend OPCache. Please help our efforts to provide a stable PHP version and test this version carefully against several different applications, with Zend OPCache enabled and report any bug in the bug tracking system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!
On 22.03.2013 18:10, Thomas Gries wrote:
just one message, just arrived:
http://php.net/archive/2013.php#id2013-03-21-1
PHP 5.5.0 beta1 available 21-Mar-2013
The PHP development team announces the release of the first beta of PHP 5.5.0. This release is the first to include the Zend OPCache. Please help our efforts to provide a stable PHP version and test this version carefully against several different applications, with Zend OPCache enabled and report any bug in the bug tracking system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!
Ubuntu 12.04 LTS still has 5.3 which is officially outdated by php.net and does not have traits and also no Closure::bindTo() which makes closures useless as mixin properties via __invoke(). Already had an ugly issue when local php 5.4 closure had access to instance $this while at server running 5.3 it produced an error. Quite strange that closures did not receive instance context in 5.3. And 5.2-style __get() based mixins are slower. And because 12.04 LTS is so much conservative I still cannot rely on 5.4 features in my projects (surely I can add ppa but it's not always a desirable thing). Also 5.4 had some Zend performance optimizations. But it seems they want to move to 5.5 even faster than 5.3 to 5.4 transition. Dmitriy
On 2013-03-22 10:45 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
On Fri, Mar 22, 2013 at 9:38 AM, Brian Wolff bawolff@gmail.com wrote:
Some people have claimed that CACHE_DB might even slow things down
compared
to CACHE_NONE when used as main cache type (cache db is still better
than
cache none for slow caches like the parser cache). Anyhow you should do profiling type things when messing with caching settings (or any performance settings) to see what is effective and what is not.
-bawolff
Wouldn't be surprised. ;) The only problem is that with CACHE_NONE, many things (specifically, throttling mechanisms) won't work since the cache isn't persistent across requests.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
That would be a mediawiki bug though. Does throtling actually work with cache_db now? I remember it used to only work with the memcached backend. Anyways if that's been fixed, throtling should be changed to use CACHE_ANY so it actually works in all configs.
-bawolff
On Fri, Mar 22, 2013 at 10:29 AM, Brian Wolff bawolff@gmail.com wrote:
That would be a mediawiki bug though. Does throtling actually work with cache_db now? I remember it used to only work with the memcached backend. Anyways if that's been fixed, throtling should be changed to use CACHE_ANY so it actually works in all configs.
Theoretically I'm thinking it should work with CACHE_DB. But yeah, the fact that the default main cache is CACHE_NONE is unsettling.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On 03/22/2013 07:16 AM, Platonides wrote:
APC can do two things:
- Keep the compiled php opcodes, so php execution is faster.
- Allow the application to store values in the web server memory (kept
accross requests).
ZendOptimizer only does 1. [...] The «APC is a "must have" for larger MediaWikis» is due to 1. In fact, wikimedia is not using APC for 2, but memcached.
With one exception: a [live hack][1] to use apc_inc() instead of rand() to generate a 32-bit TRANS-ID for HTCP cache purging.
Why is this hack in place? Is it particularly useful for [monitoring packet loss][2]?
[1]: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blobdiff;h=8973...
[2]: https://svn.wikimedia.org/viewvc/mediawiki/trunk/udpmcast/htcpseqcheck.py?vi...
wikitech-l@lists.wikimedia.org