Re: [PHP-DEV] Getting separate outputs with Date Functions
Hi!
> echo date_create('@1361240634')->format('Y-m-d');
> // output: 2013-02-19
>
> echo date('Y-m-d',1361240634);
> // output: 2013-02-18
timestamp dates are created with UTC TZ, date() assumes your configured TZ.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Getting separate outputs with Date Functions
Hello,
I'm getting two different values when I use a timestamp with the
date_create() and date() functions:
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19
echo date('Y-m-d',1361240634);
// output: 2013-02-18
Is this a known issue?
My timezone setting is set to America/Toronto. System time is set to
2013-02-18. Tested with PHP version 5.3.0 and 5.3.21
__
Raymond
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/18/2013 06:14 PM, Stas Malyshev wrote: > Hi! > >> Yeah, but NFS, especially without the realpath cache, which you lose if >> you turn on open_basedir, is deathly slow because of all the stats. >> >> Typically PHP scripts are not actually "writable files" and the way to >> keep them in synch across multiple machines is to use a deploy >> mechanism/rsynch to deploy them. You may very well have some writable > > rsync may be way too slow if you need the change appear more or less > "immediately" on all servers. Unless you run rsync each second if which > case you're probably better off with NFS :) > >> files that need to be shared at the app-level, but then we wouldn't be >> talking about PHP stat calls and the realpath cache. And most people > > You would still if the data is stored as php file. Which last time I > tested - given APC or something like - was the fastest way to get a > bunch of data into PHP (it was faster than loading and unserializing, > even with APC/memcache). > >> have moved to something like memcache for sharing writable data across >> machines. > > memcache is non-persistent. It's a cache, not a storage solution, so you > can not use it for anything that actually needs to be stored permanently. Sure, but then you can go with something like Redis. But, again, if you go back to the original question, this has nothing to do with often-changing data in a couple of PHP include files: We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving mostly PHP over NFS (we have separate servers for static content)." So they are serving up all their PHP over NFS for some reason. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Hi! > Yeah, but NFS, especially without the realpath cache, which you lose if > you turn on open_basedir, is deathly slow because of all the stats. > > Typically PHP scripts are not actually "writable files" and the way to > keep them in synch across multiple machines is to use a deploy > mechanism/rsynch to deploy them. You may very well have some writable rsync may be way too slow if you need the change appear more or less "immediately" on all servers. Unless you run rsync each second if which case you're probably better off with NFS :) > files that need to be shared at the app-level, but then we wouldn't be > talking about PHP stat calls and the realpath cache. And most people You would still if the data is stored as php file. Which last time I tested - given APC or something like - was the fastest way to get a bunch of data into PHP (it was faster than loading and unserializing, even with APC/memcache). > have moved to something like memcache for sharing writable data across > machines. memcache is non-persistent. It's a cache, not a storage solution, so you can not use it for anything that actually needs to be stored permanently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Hi!
> If no one objects, I'll merge this into 5.5 and master:
>
> https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be performance-sensitive...
Also, skip comments in tests seem to be wrong:
+if (PHP_INT_SIZE != 4)
6
+ die("skip for machines with 32-bit longs");
But actually it skips for longs NOT being 32-bit. Same with other test.
Also, I'm not sure I understand what 64-bit test is supposed to return
and why - why negative number is converted to positive one? What exactly
this change is supposed to improve?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/18/2013 05:50 PM, Stas Malyshev wrote: > Hi! > >> Wow, people are still serving web files over NFS? Sounds painful. > > Sometimes, there's not much (better) choices if you need to keep > writeable files in sync over a number of machines. There are other > shared FSes but they would lead to pretty much the same issues. Yeah, but NFS, especially without the realpath cache, which you lose if you turn on open_basedir, is deathly slow because of all the stats. Typically PHP scripts are not actually "writable files" and the way to keep them in synch across multiple machines is to use a deploy mechanism/rsynch to deploy them. You may very well have some writable files that need to be shared at the app-level, but then we wouldn't be talking about PHP stat calls and the realpath cache. And most people have moved to something like memcache for sharing writable data across machines. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Hi! > Wow, people are still serving web files over NFS? Sounds painful. Sometimes, there's not much (better) choices if you need to keep writeable files in sync over a number of machines. There are other shared FSes but they would lead to pretty much the same issues. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Hi Brendon, In our environment, we use NFS for shared storage, we are using APC as well with stat=0. In our setting, we also experiencing high number of stat() calls on our file system. My initial finding of this problem is we enabled the open_basedir setting. And there is already a bug report for this, https://bugs.php.net/bug.php?id=52312 We tested the issue in 5.2.x, 5.3.x and 5.4.x, all of them experiencing same issue. I m not sure if this is a same problem as yours. But I do hope the community can find out a good solutions to handle the balance of better security and good performance. Cheers On Tue, Feb 19, 2013 at 7:26 AM, Brendon Colby wrote: > Greetings, > > This seemed like the appropriate list to discuss this - let me know if it > isn't. > > We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving > mostly PHP over NFS (we have separate servers for static content). I > have been trying to figure out why we're seeing so many getattr > requests from our Apache/PHP servers. I think I've narrowed it down to > how PHP/APC gets information about a file to see if it has been > changed since it was last cached: > > https://bugs.php.net/bug.php?id=59372 > > Rasmus said: > > "Just because you see an open() syscall doesn't mean the cache isn't > used. The open() is there because PHP by default does open+fstat for > performance reasons. If you look carefully you will see there is just > an open() and no read() calls. So it opens the file, uses the stat > struct from the open fd to get the inode and fetches the op_array from > the opcode cache. This can be made more efficient, but this report is > incorrect in assuming the cache isn't being used." > > This is exactly what I'm seeing when I strace an httpd process - > mostly open() and fstat() calls w/o any read() calls. This makes sense > to me, however, the problem with this is as far as I understand it, > that an open() on an NFS file system causes an automatic gettattr() > call to the server. Doing this completely bypasses the NFS attribute > cache, which is why we're seeing so many getattr requests to our NFS > server despite having an attribute cache timeout of 60 seconds. For > those familiar with NFS, we could just as well disable our attribute > cache at this point, which is almost never recommended because of > performance reasons. > > I found a good explaination of why this happens in this Redhat document: > > > http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/5e75391d7f0110a97b91452f0cee/1/jcr:frozenNode/rh:pdfFile.pdf > > "Avoid unnecessarily opening and closing of files. If you access a > file frequently, opening and closing that file triggers the > opentoclose cache > consistency mechanism in the NFS file system. Triggering this > mechanism causes NFS getattr requests to be generated, which can slow > performance. By keeping the file open, traffic is kept to a minimum." > > I've tried doing apc.stat=0 and about every other combination of > options, but PHP still does an open()+3 fstat() commands on every > single page load no matter what I do. We have autoload set, so that > equates to several automatic open() (and subsequent NFS getattr()) > calls with every single PHP request. To give you an idea what kind of > load this is generating for us: > > -Out of 7,000 total NFS operations per second right now: > -About 45% are getattr calls > -Our Apache/PHP servers are generating 52% of all NFS calls > -An average of 82% of those calls are getattr requests > -As a comparison, our far busier content servers (many times the req/s > of the Apache/PHP servers) are generating half the number of NFS > requests our PHP servers are, and 98% or so of those requests are read > requests with just 1% getattr > > I am pretty proficient with patching/compiling/profiling, but sadly I > am no C coder. I've tried digging into this myself but I'm pretty out > of my element here. I'm curious if anyone on this list could give me > any pointers on what I can do to change this behavior and reduce the > load on our NFS server. If we can't change PHP behavior, we may have > to abandon NFS for our PHP files due to the load PHP appears to be > generating on our NFS server. I'd hate to do this, so please let me > know if any of you have any ideas as to what I can do to change this > behavior. > > Brendon > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Brendon, in our environment, we use NFS for shared storage, we are using APC as well with stat=0. In our setting, we are experiencing high number of stat() calls on the NFS. My initial finding of this problem is we enabled the open_basedir setting. And there is already a bug report for this, https://bugs.php.net/bug.php?id=52312 We tested the issue in 5.2.x, 5.3.x and 5.4.x, all of them experiencing same issue. I m not sure if this is a same problem as yours. But I do hope the community can find out a good solutions to handle the balance of better security and good performance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 18/02/13 21:47, Brendon Colby wrote: On Mon, Feb 18, 2013 at 4:32 PM, Damien Tournoud wrote: Assuming that those are relative includes, can you try with: apc.canonicalize=0 apc.stat=0 Paths are absolute. stat=0 (and canonicalize=0 just to try it) produced the same result. Brendon Brendon, are your scripts doing a log of include_once / require_once calls? In you look at ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() in Zend/zend_vm_execute.h then you will see that this Zend handler does zend_resolve_path() for any xxx_ONCE instructions and zend_stream_open() on the first request of the same. Yes APC rehooks this handler with a wrapper but this is only for lazy loading. When it honors the xxx_once instructions, it will still open the streams even if the code itself is fully cached in APC and the I/O is entirely nugatory. I suspect that this could generate the NFS traffic that you are discussing. This would be easy to avoid, but this would require replacing this handler entirely or doing dynamic code patching, nether of which APC currently does, I believe. Incidentally because this is Zend feature and nothing directly to with APC, O+ will also have this runtime characteristic. //Terry
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Feb 18, 2013, at 23:03 , Christopher Jones wrote: > > > On 02/18/2013 10:52 AM, Christopher Jones wrote: > >> I agree that unless we get Gopal-like inspiration (inclued, scream) for >> naming, "opcache" is best. > > In the "so bad I can't resist sending it" category is today's > semi-humorous name suggestion: "Cajun". It sounds roughly like the > English pronunciation of "caching" > > Sadly it's not as nicely self-documenting as "opcache". > opcache is fine, its better that it's self describing then exiting. Cause then you don't have to google it to figure out what it is every time, like T_PAAMAYIM_NEKUDOTAYIM :P So if you really have to make a name for it, keep it self describing, like: OpsiCache Other then already being a used name, ops(i) is the word you would say in some languages when you realize you have done a mistake :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/18/2013 10:52 AM, Christopher Jones wrote: I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, "opcache" is best. In the "so bad I can't resist sending it" category is today's semi-humorous name suggestion: "Cajun". It sounds roughly like the English pronunciation of "caching" Sadly it's not as nicely self-documenting as "opcache". Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On Mon, Feb 18, 2013 at 4:32 PM, Damien Tournoud wrote: > Assuming that those are relative includes, can you try with: > > apc.canonicalize=0 > apc.stat=0 Paths are absolute. stat=0 (and canonicalize=0 just to try it) produced the same result. Brendon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On Mon, Feb 18, 2013 at 10:03 PM, Brendon Colby wrote:
> I tried apc.include_once_override - no change. I set up Apache to one
> process and straced it. I clicked around on the site a few times and
> see the typical pattern:
>
> open("[PATH]/CacheFile.class.php", O_RDONLY) = 10
> fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
> fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
> fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
Assuming that those are relative includes, can you try with:
apc.canonicalize=0
apc.stat=0
Damien
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On Mon, Feb 18, 2013 at 3:35 PM, Rasmus Lerdorf wrote:
> On 02/18/2013 12:26 PM, Brendon Colby wrote:
>
>> Rasmus said:
> Wow, people are still serving web files over NFS? Sounds painful.
>
> But, this is what APC's apc.include_once_override setting tries to
> address. Try turning that on.
Yep - I think it would be a lot more painful if we didn't use a very
expensive NetApp Filer to serve NFS (the solution before the Filer
would lock up every few weeks). I'm really surprised more people
haven't complained about this. I've seen a few complaints about people
seeing poor PHP app performance on NFS, but they usually move to
gluster or something else before ever figuring it out. Maybe very few
people use NFS to serve web files - who knows.
I tried apc.include_once_override - no change. I set up Apache to one
process and straced it. I clicked around on the site a few times and
see the typical pattern:
open("[PATH]/CacheFile.class.php", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
fstat(10, {st_mode=S_IFREG|0664, st_size=2097, ...}) = 0
Out of 486 open() calls, 263 were for PHP files (54%). Here is my
current APC config:
extension=/usr/local/lib/php/extensions/apc.so
apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=256M
apc.ttl=1200
apc.user_ttl=1200
apc.num_files_hint=300
apc.mmap_file_mask=/apc.shm.XX
apc.slam_defense=0
apc.write_lock=1
apc.include_once_override=1
apc.stat=0 doesn't help. Every PHP request causes an open() and
subsequent getattr() to the Filer no matter what options I set.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/18/2013 12:26 PM, Brendon Colby wrote: > Rasmus said: > > "Just because you see an open() syscall doesn't mean the cache isn't > used. The open() is there because PHP by default does open+fstat for > performance reasons. If you look carefully you will see there is just > an open() and no read() calls. So it opens the file, uses the stat > struct from the open fd to get the inode and fetches the op_array from > the opcode cache. This can be made more efficient, but this report is > incorrect in assuming the cache isn't being used." > > This is exactly what I'm seeing when I strace an httpd process - > mostly open() and fstat() calls w/o any read() calls. This makes sense > to me, however, the problem with this is as far as I understand it, > that an open() on an NFS file system causes an automatic gettattr() > call to the server. Doing this completely bypasses the NFS attribute > cache, which is why we're seeing so many getattr requests to our NFS > server despite having an attribute cache timeout of 60 seconds. For > those familiar with NFS, we could just as well disable our attribute > cache at this point, which is almost never recommended because of > performance reasons. Wow, people are still serving web files over NFS? Sounds painful. But, this is what APC's apc.include_once_override setting tries to address. Try turning that on. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP causing high number of NFS getattr operations?
Greetings, This seemed like the appropriate list to discuss this - let me know if it isn't. We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving mostly PHP over NFS (we have separate servers for static content). I have been trying to figure out why we're seeing so many getattr requests from our Apache/PHP servers. I think I've narrowed it down to how PHP/APC gets information about a file to see if it has been changed since it was last cached: https://bugs.php.net/bug.php?id=59372 Rasmus said: "Just because you see an open() syscall doesn't mean the cache isn't used. The open() is there because PHP by default does open+fstat for performance reasons. If you look carefully you will see there is just an open() and no read() calls. So it opens the file, uses the stat struct from the open fd to get the inode and fetches the op_array from the opcode cache. This can be made more efficient, but this report is incorrect in assuming the cache isn't being used." This is exactly what I'm seeing when I strace an httpd process - mostly open() and fstat() calls w/o any read() calls. This makes sense to me, however, the problem with this is as far as I understand it, that an open() on an NFS file system causes an automatic gettattr() call to the server. Doing this completely bypasses the NFS attribute cache, which is why we're seeing so many getattr requests to our NFS server despite having an attribute cache timeout of 60 seconds. For those familiar with NFS, we could just as well disable our attribute cache at this point, which is almost never recommended because of performance reasons. I found a good explaination of why this happens in this Redhat document: http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/5e75391d7f0110a97b91452f0cee/1/jcr:frozenNode/rh:pdfFile.pdf "Avoid unnecessarily opening and closing of files. If you access a file frequently, opening and closing that file triggers the opentoclose cache consistency mechanism in the NFS file system. Triggering this mechanism causes NFS getattr requests to be generated, which can slow performance. By keeping the file open, traffic is kept to a minimum." I've tried doing apc.stat=0 and about every other combination of options, but PHP still does an open()+3 fstat() commands on every single page load no matter what I do. We have autoload set, so that equates to several automatic open() (and subsequent NFS getattr()) calls with every single PHP request. To give you an idea what kind of load this is generating for us: -Out of 7,000 total NFS operations per second right now: -About 45% are getattr calls -Our Apache/PHP servers are generating 52% of all NFS calls -An average of 82% of those calls are getattr requests -As a comparison, our far busier content servers (many times the req/s of the Apache/PHP servers) are generating half the number of NFS requests our PHP servers are, and 98% or so of those requests are read requests with just 1% getattr I am pretty proficient with patching/compiling/profiling, but sadly I am no C coder. I've tried digging into this myself but I'm pretty out of my element here. I'm curious if anyone on this list could give me any pointers on what I can do to change this behavior and reduce the load on our NFS server. If we can't change PHP behavior, we may have to abandon NFS for our PHP files due to the load PHP appears to be generating on our NFS server. I'd hate to do this, so please let me know if any of you have any ideas as to what I can do to change this behavior. Brendon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/16/2013 01:10 PM, Rasmus Lerdorf wrote: On 02/16/2013 11:16 AM, Zeev Suraski wrote: - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) I (mostly) pronounce cache the non-American way as "kaysh". Cachze would be like that with a bit of Z sound. I don't think I would ever get neither the spelling nor the pronunciation of Cachze right. I like the much simpler "opcache" name. I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, "opcache" is best. Chris -Rasmus -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] short syntax for construction/initialization, named arguments and (future) annotations
This is a not a feature request, just a note on something that occurred to
me.
Since there is talk of native support for annotations again, it occurred to
me that part of the problem that every userland implementation and proposed
syntax deals with, along with native implementations in other languages, is
that of convenient short-hand syntax for construction and initialization
(of annotation objects.)
A constructor is a method with arguments, so a single familiar syntax
really could (perhaps should) be applicable in all of those cases.
How about something like this?
class Foo
{
public $bling;
public function __construct($bar, $baz)
{
}
// (sample annotation)
public function setName($first, $last)
{
}
}
$test = new Foo({ bar='bar'; baz=123 }) { bling = 'wibble' };
// equivalent to:
// $test = new Foo('bar', 123);
// $test->bling = 'wibble';
$test->setName({ last='Kong'; first='Donkey' });
// equivalent to:
// $test->setBar('Donkey', 'Kong');
So in other words, a unified syntax for named (constructor and method)
arguments, and property-initialization with the "new" keyword - all of
which could be statically checked (in IDEs), as could the property-values
for an annotation instance.
This could mitigate a lot of crappy stuff you see in (even the leading)
frameworks right now, where far too frequently, initialization and
configuration, as well as "named arguments", are implemented as nested
arrays, to which you cannot apply any kind of static analysis.
Proposed annotation syntaxes (and some syntaxes in other languages)
typically address this issue by introducing special syntax for annotations,
which are a good example of where property-initialization is heavily used
and benefits greatly from static checking, auto-complete in IDEs, etc.
Just throwing that thought out there. Try not to get hung up on the syntax
in the example above, I just came up with something on the spot, just to
provide some context.
