On 10/21/2011 4:42 PM, Lester Caine wrote:
> Stephen Zarkos wrote:
>> Yes, I do:) Although the tests we've done are a bit different from this
>> sort of
>> benchmark. We typically do more load testing, where we have one or more
>> load agent(s)
>> each creating multiple virtual clients accessi
Stephen Zarkos wrote:
Yes, I do:) Although the tests we've done are a bit different from this sort
of benchmark. We typically do more load testing, where we have one or more
load agent(s) each creating multiple virtual clients accessing one or more PHP
pages on another physical server.
I'
> -Original Message-
> From: Richard Riley [mailto:rile...@googlemail.com]
> Sent: Friday, October 21, 2011 1:04 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Benchmarking ...
>
> Stephen Zarkos writes:
>
> > Apache does tend to be slower
Stephen Zarkos wrote:
> Stas Malyshev wrote:
> >> So I suppose the question I have to ask is what the f**k am I doing
> >> wrong on the windows setup? I've always known that linux was faster,
> >> but 4 times faster on the same hardware? My main development
> machine
> >> is giving 2
Stephen Zarkos writes:
>> Stas Malyshev wrote:
>> >> So I suppose the question I have to ask is what the f**k am I doing
>> >> wrong on the windows setup? I've always known that linux was faster,
>> >> but 4 times faster on the same hardware? My main development
>> machine
>> >> is giving 27.750
> Stas Malyshev wrote:
> >> So I suppose the question I have to ask is what the f**k am I doing
> >> wrong on the windows setup? I've always known that linux was faster,
> >> but 4 times faster on the same hardware? My main development
> machine
> >> is giving 27.750 seconds which is even nicer,
>
Stas Malyshev wrote:
So I suppose the question I have to ask is what the f**k am I doing wrong on the
windows setup? I've always known that linux was faster, but 4 times faster on
the same hardware? My main development machine is giving 27.750 seconds which is
even nicer,
CPU-bound ops should b
Hi!
On 10/21/11 4:00 AM, Lester Caine wrote:
So I suppose the question I have to ask is what the f**k am I doing wrong on the
windows setup? I've always known that linux was faster, but 4 times faster on
the same hardware? My main development machine is giving 27.750 seconds which is
even nicer,
Am 21.10.2011 13:00, schrieb Lester Caine:
> So I suppose the question I have to ask is what the f**k am I doing wrong on
> the windows setup?
> I've always known that linux was faster, but 4 times faster on the same
> hardware? My main development
> machine is giving 27.750 seconds which is
Mario Brandt wrote:
I already made some benchmarking 5.3.8 and 5.4.0beta2
OK running it via Apache ;) ( '\n' -> '' )
Machine is a Dual Core AMD64 laptop (2.1GHz with 1.1GHz memory)
On 64bit Windows 7 Home
32bit Apache + 32bit PHP
http://pastebin.com/raw.php?i=MS6H4A5g
166.947 Seconds
64bit A
Hi Lester,
you can also run pure command line with the micro bench script
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/Zend/micro_bench.php?view=co
I already made some benchmarking 5.3.8 and 5.4.0beta2
results 5.3.8
http://pastebin.com/raw.php?i=52s1kzMa
results 5.4
http://pastebin.com
Lester Caine wrote:
So what are people currently using for benchmarking performance?
Anybody using the Phoronix Test Suite? Beibg PHP based, and running across all
platforms it looks like it should be useful, but it's not 'run out of the box'
on my suse system, and I'm not sure about sorting
Bostjan Skufca wrote:
Are you talking about general server benchmarks, HTTP server benchmarks or
PHP-only specific benchmarks (make test?)?
General full stack testing ... OS agnostic so we can compare OS's
The statement has been made that 32bit PHP is faster than 64bit on windows, and
that is
Are you talking about general server benchmarks, HTTP server benchmarks or
PHP-only specific benchmarks (make test?)?
b.
On 19 October 2011 13:35, Lester Caine wrote:
> OK ... I've pulled out all the old benchmarking stuff, but being several
> years old, they seem to be a little 'light' in wh
OK ... I've pulled out all the old benchmarking stuff, but being several years
old, they seem to be a little 'light' in what they are doing. I'm getting 34mS
test times on things that were probably a second or more when I first used them.
I've got two Linux machines running public accessible we
At 12:14 AM 6/12/2003 +, Thomas Seifert wrote:
On Wed, 11 Jun 2003 07:49:24 +0300 [EMAIL PROTECTED] (Andi Gutmans) wrote:
> It's really quite simple. Make a hash that holds a structure which has the
> realpath() and time of entry in it. If it's still relevant use it. If you
> want to limit the
On Wed, 11 Jun 2003 07:49:24 +0300 [EMAIL PROTECTED] (Andi Gutmans) wrote:
> It's really quite simple. Make a hash that holds a structure which has the
> realpath() and time of entry in it. If it's still relevant use it. If you
> want to limit the hash to X entries (no need IMO) the easy way is
At 12:52 AM 6/11/2003 -0400, Ilia A. wrote:
Well, judging from my own experience, most people do either a full path
include, or a relative path include from the current directory such as
a/b/c.php and similar. So for these cases we can bypass tokenizing the patch
at an fairly light cost of 2 memchr
Well, judging from my own experience, most people do either a full path
include, or a relative path include from the current directory such as
a/b/c.php and similar. So for these cases we can bypass tokenizing the patch
at an fairly light cost of 2 memchr() calls.
The realpath may alleviate the
At 07:15 AM 6/11/2003 +0300, Andi Gutmans wrote:
At 09:51 PM 6/10/2003 -0400, Ilia A. wrote:
There are a several things that could be done to speed file opening process
up. Attached is a fairly simple patch that in most cases optimizes
potentially expensive code that looks for ../ and ./ in the pat
At 06:55 PM 6/10/2003 -0700, Rasmus Lerdorf wrote:
On Tue, 10 Jun 2003, Ilia A. wrote:
> As far as realpath() goes beyond the _once() directives and php
installations
> where safe_mode or open_basedir are enabled it is not really needed. To
> handle safe_mode/open_basedir is fairly easy and mostly
At 09:51 PM 6/10/2003 -0400, Ilia A. wrote:
There are a several things that could be done to speed file opening process
up. Attached is a fairly simple patch that in most cases optimizes
potentially expensive code that looks for ../ and ./ in the path.
This sounds like a weird patch to me. How many
On Tue, 10 Jun 2003, Ilia A. wrote:
> As far as realpath() goes beyond the _once() directives and php installations
> where safe_mode or open_basedir are enabled it is not really needed. To
> handle safe_mode/open_basedir is fairly easy and mostly involves passing
> TSRMLS_CC to virtual_file_ex() a
On June 9, 2003 12:58 pm, Andi Gutmans wrote:
> At 01:27 PM 6/4/2003 -0400, Ilia A. wrote:
> >Here is an analysis of the situation as it stands with PHP 4.3.3. As far
> > as I can tell that even when opening files with the full path we do a lot
> > of completely unnecessary work.
> >
> >We start fr
There are a several things that could be done to speed file opening process
up. Attached is a fairly simple patch that in most cases optimizes
potentially expensive code that looks for ../ and ./ in the path.
Ilia
Index: TSRM/tsrm_virtual_cwd.c
=
On Monday, June 9, 2003, at 12:58 PM, Andi Gutmans wrote:
At 01:27 PM 6/4/2003 -0400, Ilia A. wrote:
Here is an analysis of the situation as it stands with PHP 4.3.3. As
far as I
can tell that even when opening files with the full path we do a lot
of
completely unnecessary work.
We start from
At 01:27 PM 6/4/2003 -0400, Ilia A. wrote:
Here is an analysis of the situation as it stands with PHP 4.3.3. As far as I
can tell that even when opening files with the full path we do a lot of
completely unnecessary work.
We start from expand_filepath() which, gets called when opening a file. This
Oh, this is on OSX? I guess realpath() does an open() on every component
of a path on OSX? That's nuts!
-Rasmus
On Wed, 4 Jun 2003, Jeff Moore wrote:
>
> On Wednesday, June 4, 2003, at 12:21 PM, Rasmus Lerdorf wrote:
>
> > Uh, the number of open() calls really shouldn't change. Are you sure
On Wednesday, June 4, 2003, at 12:21 PM, Rasmus Lerdorf wrote:
Uh, the number of open() calls really shouldn't change. Are you sure
you
are comparing the same code?
Yes. I am sure.
And how are you testing?
I attach fs_usage to the running httpd process and hit the script a
single time.
ht
On Wed, 4 Jun 2003, Ilia A. wrote:
> Here is an analysis of the situation as it stands with PHP 4.3.3. As far as I
> can tell that even when opening files with the full path we do a lot of
> completely unnecessary work.
>
> We start from expand_filepath() which, gets called when opening a file. Thi
I believe those are from the realpath call. It splits the path and stats each
part to make sure it is real:
1) /
2) /home
3) /home/rei
4) /home/rei/PHP_CVS
5) /home/rei/PHP_CVS/STABLE
6) /home/rei/PHP_CVS/STABLE/php4
Brian
On Wed, 4 Jun 2003 13:27:14 -0400, Ilia A. wrote:
> Now, the interestin
Here is an analysis of the situation as it stands with PHP 4.3.3. As far as I
can tell that even when opening files with the full path we do a lot of
completely unnecessary work.
We start from expand_filepath() which, gets called when opening a file. This
function does a getcwd() everytime it i
Uh, the number of open() calls really shouldn't change. Are you sure you
are comparing the same code? And how are you testing? Attach strace or
truss to your running httpd process and hit your script a single time.
Then look at the output and compare them. Some of the keys to reducing
syscalls:
I remember a discussion about system calls here earlier. What is the
status of that?
I've been doing some tests and have found that this code runs about 2.5
times slower under 4.3.2 than it did on 4.1.2 on the same machine
(running OS X):
I did some tests with fs_usage to check file system c
34 matches
Mail list logo
