In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:
opcache_get($key);
opcache_set($key, $value);
Is planned in PHP 7.1?
S.A.N wrote on 25/04/2016 15:09:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
This was identified as a difference between APC and OpCache when the
latter was added to core several releases ago, and that's exactly why
APCu exists: http://php.net/apcu
There's not really a huge connection between opcode caching and
optimization (OpCache) and shared memory data caches (APCu, memcached,
etc), so I don't think there's any particular logic to calling such
functions "opcache".
So I guess the question becomes: "should APCu be made part of core?" I'm
not aware of anyone having proposed that, so don't know if there are
strong feelings for or against such a thing.
Regards,
Rowan Collins
[IMSoP]
S.A.N wrote on 25/04/2016 15:09:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
This was identified as a difference between APC and OpCache when the latter was added to core several releases ago, and that's exactly why APCu exists: http://php.net/apcu
There's not really a huge connection between opcode caching and optimization (OpCache) and shared memory data caches (APCu, memcached, etc), so I don't think there's any particular logic to calling such functions "opcache".
So I guess the question becomes: "should APCu be made part of core?" I'm not aware of anyone having proposed that, so don't know if there are strong feelings for or against such a thing.
As long as it’s cache is not shared among processes, rather not.
A user cache needs to be able to be shared between cli and web process to cover the main use cases imo.
André Rømcke wrote on 25/04/2016 18:00:
So I guess the question becomes: "should APCu be made part of core?" I'm not aware of anyone having proposed that, so don't know if there are strong feelings for or against such a thing.
As long as it’s cache is not shared among processes, rather not.
A user cache needs to be able to be shared between cli and web process to cover the main use cases imo.
Yeah, there are many key-value, document-based, and NoSQL stores these
days (memcached, redis, couchbase, mongo, etc), and while APCu might be
the best in some circumstances, I'm inclined to say it doesn't deserve
special privilege within default builds.
Regards,
Rowan Collins
[IMSoP]
2016-04-25 17:36 GMT+03:00 Rowan Collins rowan.collins@gmail.com:
S.A.N wrote on 25/04/2016 15:09:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
This was identified as a difference between APC and OpCache when the latter
was added to core several releases ago, and that's exactly why APCu exists:
http://php.net/apcuThere's not really a huge connection between opcode caching and optimization
(OpCache) and shared memory data caches (APCu, memcached, etc), so I don't
think there's any particular logic to calling such functions "opcache".So I guess the question becomes: "should APCu be made part of core?" I'm not
aware of anyone having proposed that, so don't know if there are strong
feelings for or against such a thing.
Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.
This seems to mix the concerns of an opcode cache (saves opcodes) with a
user-cache (saves mixed data).
You should just use APCu for that.
Marco Pivetta
2016-04-25 17:36 GMT+03:00 Rowan Collins rowan.collins@gmail.com:
S.A.N wrote on 25/04/2016 15:09:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
This was identified as a difference between APC and OpCache when the
latter
was added to core several releases ago, and that's exactly why APCu
exists:
http://php.net/apcuThere's not really a huge connection between opcode caching and
optimization
(OpCache) and shared memory data caches (APCu, memcached, etc), so I
don't
think there's any particular logic to calling such functions "opcache".So I guess the question becomes: "should APCu be made part of core?" I'm
not
aware of anyone having proposed that, so don't know if there are strong
feelings for or against such a thing.Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.
S.A.N wrote on 25/04/2016 18:49:
There's not really a huge connection between opcode caching and optimization
(OpCache) and shared memory data caches (APCu, memcached, etc), so I don't
think there's any particular logic to calling such functions "opcache".So I guess the question becomes: "should APCu be made part of core?" I'm not
aware of anyone having proposed that, so don't know if there are strong
feelings for or against such a thing.
Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.
Because different situations call for different functionality. If the
only reason not to use APCu was the need to install a PECL extension,
then nobody would have implemented a PECL extension for Memcache, or
Redis, etc.
Storing data in PHP's shared memory has several downsides - for
instance, inability to share with CLI / services built in other
languages, non-persistent across server restarts, not shareable across
instances, etc. For you, these may not be an issue, but to say that "if
APCu functionality was in core, nobody would need any other memory
cache" is somewhat naive.
Regards,
Rowan Collins
[IMSoP]
2016-04-25 20:56 GMT+03:00 Rowan Collins rowan.collins@gmail.com:
S.A.N wrote on 25/04/2016 18:49:
There's not really a huge connection between opcode caching and
optimization(OpCache) and shared memory data caches (APCu, memcached, etc), so I
don't
think there's any particular logic to calling such functions "opcache".So I guess the question becomes: "should APCu be made part of core?" I'm
not
aware of anyone having proposed that, so don't know if there are strong
feelings for or against such a thing.Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.Because different situations call for different functionality. If the only
reason not to use APCu was the need to install a PECL extension, then nobody
would have implemented a PECL extension for Memcache, or Redis, etc.Storing data in PHP's shared memory has several downsides - for instance,
inability to share with CLI / services built in other languages,
non-persistent across server restarts, not shareable across instances, etc.
For you, these may not be an issue, but to say that "if APCu functionality
was in core, nobody would need any other memory cache" is somewhat naive.
I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding Apcu to PHP core, IMHO...
2016-04-25 20:56 GMT+03:00 Rowan Collins rowan.collins@gmail.com:
S.A.N wrote on 25/04/2016 18:49:
There's not really a huge connection between opcode caching and
optimization(OpCache) and shared memory data caches (APCu, memcached, etc), so I
don't
think there's any particular logic to calling such functions
"opcache".So I guess the question becomes: "should APCu be made part of core?"
I'm
not
aware of anyone having proposed that, so don't know if there are
strong
feelings for or against such a thing.Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.Because different situations call for different functionality. If the
only
reason not to use APCu was the need to install a PECL extension, then
nobody
would have implemented a PECL extension for Memcache, or Redis, etc.Storing data in PHP's shared memory has several downsides - for instance,
inability to share with CLI / services built in other languages,
non-persistent across server restarts, not shareable across instances,
etc.
For you, these may not be an issue, but to say that "if APCu
functionality
was in core, nobody would need any other memory cache" is somewhat naive.I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding Apcu to PHP core, IMHO...
You are still asking for a tool that does a very precise and single thing
to be re-purposed into a completely different scope.
Use the right tool for the right job: including APCu would be much
clearer/simpler than making OpCache an all-purpose shared memory space for
userland.
Marco Pivetta
I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding Apcu to PHP core, IMHO...
So how do you then manage the data when the PHP servers are spread
across multiple machines? Shared data needs to exist across space as
well as time, and the increasing use of virtual services needs
persistent data that is not reliant on the same memory storing that
data? This is not something that can easily be added unless all the
restrictions are fully understood.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2016-04-25 20:56 GMT+03:00 Rowan Collins rowan.collins@gmail.com:
S.A.N wrote on 25/04/2016 18:49:
There's not really a huge connection between opcode caching and
optimization(OpCache) and shared memory data caches (APCu, memcached, etc), so I
don't
think there's any particular logic to calling such functions
"opcache".So I guess the question becomes: "should APCu be made part of core?"
I'm
not
aware of anyone having proposed that, so don't know if there are
strong
feelings for or against such a thing.Yes, there are a lot of libraries to work with shared memory, but why
should they if there OPcache in core PHP?
Functions get, set key values will be useful and in demand.Because different situations call for different functionality. If the
only
reason not to use APCu was the need to install a PECL extension, then
nobody
would have implemented a PECL extension for Memcache, or Redis, etc.Storing data in PHP's shared memory has several downsides - for instance,
inability to share with CLI / services built in other languages,
non-persistent across server restarts, not shareable across instances,
etc.
For you, these may not be an issue, but to say that "if APCu
functionality
was in core, nobody would need any other memory cache" is somewhat naive.I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding Apcu to PHP core, IMHO...
A little history lesson - combining an opcode cache and data storage is one
of the reasons APC died - it got too complex and too convoluted in the end.
Yes, there were other reasons too, but this one was one of the big one.
Getting that functionality into the core is not bad idea, but never ever
ever mix it with the opcode cache. Keep them separate.
I am not against third-party libraries, I want to have this
functionality out of the box, it seems to me correct to make these
functions in OPCache, instead of adding Apcu to PHP core, IMHO...
Literally the only difference between including APCu in core and adding
this to OpCache is the name of the resulting functions. The result
either way is that you would have the functionality out of the box, and
the PHP core devs would need to maintain it.
Meanwhile, you haven't addressed the point being made as a reason not to
bundle, which is that this is not a universally-useful solution, and
there needs to be some reason why this needs to be incorporated - under
whatever name - any more urgently than a memcache driver, or a redis
driver, or igbinary serialisation, or any one of dozens of other extensions.
Regards,
--
Rowan Collins
[IMSoP]
Meanwhile, you haven't addressed the point being made as a reason not to
bundle, which is that this is not a universally-useful solution, and there
needs to be some reason why this needs to be incorporated - under whatever
name - any more urgently than a memcache driver, or a redis driver, or
igbinary serialisation, or any one of dozens of other extensions.
Redis, Memcached - single threaded and network latency.
Hey:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
you could try https://github.com/laruence/yac
it's a "A fast shared memory user data cache for PHP "
thanks
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Morning,
To answer the question; No, there is no plan to add that.
The allocator in opcache is simply not suitable for that kind of use.
We could make it suitable, but the optimal allocator for a user cache, and
the optimal allocator for a code cache, are different things.
IMO they belong separately.
Cheers
Joe
Hey:
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Is planned in PHP 7.1?
you could try https://github.com/laruence/yac
it's a "A fast shared memory user data cache for PHP "
thanks
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Le 25/04/2016 à 16:09, S.A.N a écrit :
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);
Opcache is an opcode cache.
A user data cache is something really different.
We learn from the past, having both in the same extension (APC) was an
mistake.
So I really think, this doesn't have to be added in opache.
And various extensions already exist (apcu, yac, memcache(d), redis...)
each for different needs.
Remi.
Is planned in PHP 7.1?
2016-04-26 10:44 GMT+03:00 Remi Collet remi@fedoraproject.org:
Le 25/04/2016 à 16:09, S.A.N a écrit :
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Opcache is an opcode cache.
A user data cache is something really different.
We learn from the past, having both in the same extension (APC) was an
mistake.So I really think, this doesn't have to be added in opache.
And various extensions already exist (apcu, yac, memcache(d), redis...)
Ok, I agree.
Thank.
Hi all,
Le 25/04/2016 à 16:09, S.A.N a écrit :
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Opcache is an opcode cache.
A user data cache is something really different.
We learn from the past, having both in the same extension (APC) was an
mistake.So I really think, this doesn't have to be added in opache.
And various extensions already exist (apcu, yac, memcache(d), redis...)
each for different needs.
They are different thing. That said
Are we going to have race condition free shared memory API by default?
If yes, I'll use it for mm save handler (session save handler that
uses shared memory) storage. Mm save handler does not compile with ZTS
currently. Mm save handler would be nice for small web sites. It could
be default save handler and many apps/sites will have performance
boost.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Morning Yasuo,
Mm save handler does not compile with ZTS currently.
libmm is not intended for use in multi-threaded environments ... mostly
because threads don't need to map memory to share, they are already in the
same address space.
Another problem is processing models. PHP in NTS mode is highly likely to
be deployed in some prefork multi processing model, this is a suitable
environment for sharing with mapped memory.
In ZTS mode, multi processing models are different, they are not always
prefork, and so it's not always possible to share memory, nor is it always
possible to create the right kind of synchronization primitives, some
systems just lack that ability.
There's probably not much point in trying to do anything about the mm
handler, I doubt it is really used that much ...
Cheers
Joe
Hi all,
On Tue, Apr 26, 2016 at 4:44 PM, Remi Collet remi@fedoraproject.org
wrote:Le 25/04/2016 à 16:09, S.A.N a écrit :
In userland lacks the ability to store data in the shared memory
modules, do not use pecl modules, it would be very nice to have a
function:opcache_get($key);
opcache_set($key, $value);Opcache is an opcode cache.
A user data cache is something really different.
We learn from the past, having both in the same extension (APC) was an
mistake.So I really think, this doesn't have to be added in opache.
And various extensions already exist (apcu, yac, memcache(d), redis...)
each for different needs.They are different thing. That said
Are we going to have race condition free shared memory API by default?
If yes, I'll use it for mm save handler (session save handler that
uses shared memory) storage. Mm save handler does not compile with ZTS
currently. Mm save handler would be nice for small web sites. It could
be default save handler and many apps/sites will have performance
boost.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net