There used to be a good caching environment out there called Squid and I seem to remember it was open-source.
Kind Regards - Mike Brunt, CTO Webapper http://www.webapper.com Downey CA Office 562.243.6255 AIM - webappermb "Webapper - Making the NET work" -----Original Message----- From: Ross [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 11:14 AM To: [EMAIL PROTECTED] Subject: RE: Performance cost of fusedoc (was: Fusedoc-ing Exceptions) I'm sure the (expensive) Zend cache would make a big difference. That's one thing that is a pity with PHP, it compiles on every hit which always has me asking the question of how big should I make a library of common functions before spliting it into multiple files. Your results suggest we should also not to be too long winded in the comments. I think there are some free alternatives to the Zend cache (APC is a name that comes to mind). Cheers Ross David Huyck wrote: > I did a similar test in PHP. I made two identical includes, except one > has a > big block (~20 lines) of Lorem Ipsum comments at the top before the > code. PHP > took a significant (and consistent, proportionally) amount of time to > process > the commented version of the include. Important note, however, is that > I do > not have the Zend cacheing engine in the PHP install I tested on. I > don't > know if that would make a difference. Another interesting note is that > I > installed the Zend Optimizer and it actually INCREASED execution time by > around 50-60 ms per test. Weird. > > quick numbers: > ~498 ms w/o comments (~50 bytes) on 1000 iterations > ~751 ms w/ comments (~2.2 KB) on 1000 iterations > > And it was fairly consistent proportionally as I increased or decreased > the > iterations. > > I am not sure if I was very scientific. Does anyone have any links that > talk > about how to do benchmarking in a consistent way? > > Thanks, > David Huyck > [EMAIL PROTECTED] > > ----- Original Message ----- > From: "BORKMAN Lee" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, May 01, 2002 7:33 PM > Subject: RE: Performance cost of fusedoc (was: Fusedoc-ing Exceptions) > > > | I think Lee F's question was about file access considerations. When a > CF > | template is first read, it is compiled and cached. When the compiled > code > | is run from the cache, the comments can have absolutely no effect. > But if > | you have trusted cache turned off, then the CFAS has to verify that > the file > | has not changed. So does it take any longer to verify this if the > file size > | is large? I don't believe so, but that would depend on exactly how > the > | AppServer/OS actually figures that out. I suspect that this decision > is > | simply made on the basis of looking at the date stamp and possibly the > file > | size, without having to actually read the file. > | > | Of course, surprise surprise, I could be wrong ;-) > | > | LeeBB > | > | > | -----Original Message----- > | From: Dray, Adam [mailto:[EMAIL PROTECTED]] > | > | > | Lee Foster said: > | > | "I have an opinion style question. I know and understand the purpose > of > | fusedocs and by no way I'm I against it. (Trying to dodge any > possible > | bullets). Ok here is the question. On a web server with a heavy load > is it > | possible that the increase file size could cause or aid in performance > | issues. In this case would it be better to create a separate file > with the > | fusedoc and make a single line reference in the template to it." > | > | My gut feeling was that CFAS munches through comments without skipping > a > | beat. I wrote a little test to verify this hunch. ... > | > | Both test pages run 50,000 iterations in 37 seconds on my development > | server. I see no real difference between them. The time spent in the > actual > | inc_* files is negligible compared to the time in the test_* files. > | > | > | > | IMPORTANT NOTICE: > | This e-mail and any attachment to it is intended only to be read or > used by > | the named addressee. It is confidential and may contain legally > privileged > | information. No confidentiality or privilege is waived or lost by any > | mistaken transmission to you. If you receive this e-mail in error, > please > | immediately delete it from your system and notify the sender. You > must not > | disclose, copy or use any part of this e-mail if you are not the > intended > | recipient. The RTA is not responsible for any unauthorised > alterations to > | this e-mail or attachment to it. > | > | > | > | > > > > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
