Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 6 May 2004 16:16:46 +0200
Message-ID: <30884B45CCC6714B800F6F294BEC0A9901D98715@MSGEXS11.tf1.groupetf1.fr>
Thread-Topic: [PHP-DEV] [PATCH] suppressing realpath() with APC + tiny patches
Thread-Index: AcQzbyOAFXZ7QKjBQ6KEIsV2+36HbwABOZ1A
To: "Masaki Fujimoto" <fujimoto@php.net>,
	<internals@lists.php.net>
Subject: RE: [PHP-DEV] [PATCH] suppressing realpath() with APC + tiny patches
From: JFBUSTARRET@tf1.fr ("BUSTARRET, Jean-Francois")



I'm glad somebody is working on a patch for this performance problem.

I will test it !

Thanks.

Jean-Fran=E7ois Bustarret
eTF1 - Architect

> -----Message d'origine-----
> De : Masaki Fujimoto [mailto:fujimoto@php.net]
> Envoy=E9 : jeudi 6 mai 2004 15:36
> =C0 : internals@lists.php.net
> Objet : [PHP-DEV] [PATCH] suppressing realpath() with APC +=0D
> tiny patches
>=0D
>=0D
> Hello,
>=0D
> These days I've been working on some tasks to reduce I/O system calls=0D
> (lstat64, stat64, open and so on) of PHP for some reasons and=0D
> as the result of it, I noticed that with the APC + very small two=0D
> pathes we can suppress most of realpath() calls (although currently=0D
> I'm not sure this is the correct method or not...):
>=0D
> http://eth.jp/php-cvs-20040506-delayed-fopen.patch.txt
> (patch against current 4.3 tree, because APC is not yet fully=0D
> compatible with PHP 5)
> http://eth.jp/apc-2.0.3-delayed-fopen.patch.txt
> (patch against APC-2.0.3, current CVS-HEAD is somehow unstable...)
>=0D
> So please try and review if you're curious about suppressing=0D
> realpath() calls:)
>=0D
>=0D
> Usage:
> 1) apply patches to current 4.3 tree, and APC-2.0.3
> 2) buidconf and configure PHP as always with --enable-delayed-fopen=0D
>    option
> 3) build and install PHP and APC as always
> 4) add "delayed_fopen=3D1" entry to your php.ini
>=0D
>=0D
> And details are as follows:
>=0D
> As the recent thread and some other threads show (which=0D
> listed below),=0D
> PHP requires quite a few I/O system calls especially when=0D
> large number=0D
> of scripts are include_once()ed. And these are not ignorable=0D
> for the websites with more than 1 million hits per hour although it=0D
> has nothing to do with small sites.
>=0D
> [Performance Consideration of 1 class per file]
> http://marc.theaimsgroup.com/?l=3Dphp-dev&m=3D108279256414391&w=3D2
>=0D
> [Performance degradation]
> http://www.phpbuilder.com/lists/php-developer-list/2003022/0226.php
>=0D
> The main concern here is the lstat64() by realpath(), and open() by=0D
> searching for include_paths (when many include_paths are set).=0D
>=0D
> I think suppressing open() (which will result in ENOENT) is not so=0D
> easy (because we need some other new caching system for=0D
> include_paths), but perhaps we can easily reduce realpath() for=0D
> included scritpts with APC, because APC does not use an opned file=0D
> handle when cache hits.
>=0D
> So, my patch skips zend_open() until open_file_scanning() is called=0D
> inside zend_compile_file() when include_once() or require_once() is=0D
> called, so that zend_open() is not called when the target script is=0D
> cached in APC. As a result of this, we can reduce most of realpath()=0D
> calls by include_once() and required_once().
>=0D
>=0D
> These patches are not yet verified well so comments are welcome!
>=0D
> Best regards,
> Masaki Fujimoto
> fujimoto@php.net
>=0D

-------------------------------------
Le present message (y compris tous les elements attaches) est confidentiel=
 et est destine a ses seuls destinataires. Si vous
l'avez recu par erreur, merci de l'indiquer a son expediteur par retour et=
 de proceder a sa destruction dans vos systemes.=0D
Toute utilisation ou diffusion non autorisee de son contenu, en totalite ou=
 en partie, est strictement interdite. Les idees et=0D
opinions presentees dans ce message sont celles de son auteur, et ne=
 representent pas necessairement celles de TF1 (et/ou des=0D
entites membres du Groupe TF1).

This message (including any attachments) is confidential and may be=
 privileged. If you have received it by mistake please notify=0D
the sender by return email and delete this message from your system. Any=
 unauthorised use or dissemination of this message in=0D
whole or in part is strictly prohibited. Any views or opinions presented=
 are solely those of its author and do not necessarily=0D
represent those of TF1 (and/or its group companies).