Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21760 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43028 invoked by uid 1010); 2 Feb 2006 01:46:10 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 43013 invoked from network); 2 Feb 2006 01:46:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2006 01:46:10 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:49848] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 79/BF-23224-16461E34 for ; Wed, 01 Feb 2006 20:46:09 -0500 Received: from [192.168.150.3] ([203.98.22.198]) (authenticated bits=0) by colo.lerdorf.com (8.13.5/8.13.5/Debian-3) with ESMTP id k121jYNG011775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Feb 2006 17:45:36 -0800 Message-ID: <43E1643F.3070502@lerdorf.com> Date: Thu, 02 Feb 2006 14:45:35 +1300 User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Sascha Schumann CC: jluedke@concentric.com, internals@lists.php.net References: <200602011939.OAA10156@alexander.concentric.com> <43E1143C.7080407@lerdorf.com> <43E13BF9.6030101@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1266/Wed Feb 1 14:21:42 2006 on colo X-Virus-Status: Clean Subject: Re: [PHP-DEV] reducing open calls in php From: rasmus@lerdorf.com (Rasmus Lerdorf) Sascha Schumann wrote: > On Thu, 2 Feb 2006, Rasmus Lerdorf wrote: > >> Sascha Schumann wrote: >>> Or simply use eAccelerator which does not cause those open >>> calls. >> Which doesn't support PHP 5.1 very well. > > Which is pretty fine for us PHP 4.4 users. > > The site where I reinstalled eAccelerator does not use > include_/require_once. Neither the invoked script nor a few > included files were cached at all, despite having lots of > free memory available. That looked like a bug to me. Well, tracing through and submitting a useful bug report would be the right approach then. Obviously if something is not being cached there is a problem somewhere. Current APC is serving up billions of pages a day on the world's most visited web site. It works pretty damn well. There are still some edge cases that aren't handled well, but the core is solid. -Rasmus