. For example by passing a callback via tsrm_startup(}.
Andi
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 8:14 AM
To: Stas Malyshev
Cc: Rasmus Lerdorf; Uwe Schindler; 'PHP Internals'
Subject: Re: [PHP-DEV] TSRM changes broke windows
On Fri, 25 May 2007, Stanislav Malyshev wrote:
It's great to have a benchmark, thanks!
The standard of deviation was rather high though. Over 10 runs on each
the averages were:
time: 646 req/sec
sapi: 659 req/sec
So it's 2%, not that big a deal...
I think it is... as all the
I tried removing recently added include to SAPI.h and it compiles just
fine now. In general, I think linking TSRM to SAPI is not a good idea.
It means, among other things, that TSRM can never be used in a context
that not links it to PHP. This is something that wasn't before and I
don't think
An extra syscall on every file open isn't exactly miniscule.
It's a syscall not related to any filesystem or I/O so it can't be that
bad. And we managed to live with it so far.
Edin also just built Windows binaries without problems. Why did it work
for him?
I have no idea. But it is
Stanislav Malyshev wrote:
I tried removing recently added include to SAPI.h and it compiles just
fine now. In general, I think linking TSRM to SAPI is not a good idea.
It means, among other things, that TSRM can never be used in a context
that not links it to PHP. This is something that wasn't
An extra syscall on every file open isn't exactly miniscule.
It's a syscall not related to any filesystem or I/O so it can't be that
bad. And we managed to live with it so far.
Edin also just built Windows binaries without problems. Why did it work
for him?
I have no idea. But it
Uwe Schindler wrote:
An extra syscall on every file open isn't exactly miniscule.
It's a syscall not related to any filesystem or I/O so it can't be that
bad. And we managed to live with it so far.
Edin also just built Windows binaries without problems. Why did it work
for him?
I have no
quite expensive. And SAPI isn't only for web server interaction. SAPI
is a general-purpose abstraction API that sits between PHP and anything
PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven.
There is no way to use PHP without at least a stub SAPI layer.
There is, however, a
It would be perhaps OK to make TSRM dependent on some global PHP
functions,
but to make it depend on SAPI code that is only for webserver
interaction
(!) and not related to TSRM (yes SAPI uses TSRM but not the other way
round)
is not so good. And that only because of a not IO-related
Stanislav Malyshev wrote:
quite expensive. And SAPI isn't only for web server interaction. SAPI
is a general-purpose abstraction API that sits between PHP and anything
PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven.
There is no way to use PHP without at least a stub SAPI
Uwe Schindler wrote:
It would be perhaps OK to make TSRM dependent on some global PHP
functions,
but to make it depend on SAPI code that is only for webserver
interaction
(!) and not related to TSRM (yes SAPI uses TSRM but not the other way
round)
is not so good. And that only because of a
Hi Rasmus,
This is no longer the case. E.g. when compiling the module for the NSAPI
webserver (Sun Java System Webserver) there should be a global define
like
-DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
that all SAPIs do not have an effect on the thread
I did a bit of rather unscientific benchmarking using my old
bench_main.php script which tries to be a bit more than a
microbenchmark. The fastest run for each were:
time(0):
1 fetches, 5 max parallel, 2.73e+07 bytes, in 15.314 seconds
2730 mean bytes/connection
652.998 fetches/sec,
It's great to have a benchmark, thanks!
The standard of deviation was rather high though. Over 10 runs on each
the averages were:
time: 646 req/sec
sapi: 659 req/sec
So it's 2%, not that big a deal...
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
Stanislav Malyshev wrote:
Well, by that logic you would be fine with:
#define TIME_CALL sapi_get_request_time(TSRMLS_C)
and in tsrm_virtual_cwd.c
#ifndef TIME_CALL
define TIME_CALL time(0)
#endif
...
t = CWDG(realpath_cache_ttl)?TIME_CALL:0;
Theoretically yes, that could work, but:
But that doesn't fix the broken side-effects we already have in the
locking code depending on defines in the individuals SAPIs which Uwe
showed isn't working either. And if we exclude locking from TSRM as
Well, that's different problem which I can't really tell about because I
don't know
16 matches
Mail list logo
