Re: [benchmarks] Server-side PHP

From: Date: Thu, 30 Apr 2009 20:38:42 +0000
Subject: Re: [benchmarks] Server-side PHP
References: 1  Groups: php.qa 
Request: Send a blank email to php-qa+get-64840@lists.php.net to get a copy of this message
Hi, Thanks for sharing your thoughts. Definitely the warming-up period makes sense. We all want to benchmark several implementations and combinations of caches, optimizers and VMs, so we need to warm up these things. Maybe we can coordinate our efforts. We have a SoC student assigned to work on benchmarks, so maybe he can work on this as well. Right now he's working on raw benchmarks to run on CLI. Regards, Nuno ----- Original Message -----
Hi, Let me just break some discussion towards better PHP benchmarks. For benchmarks considering server-side usage of PHP, we need to take following two issues into account: * Measureing per-request processing * Allowing warming-up for other types of implementation of PHP runtime PER-REQUEST PROCESSING When a server-side PHP application runs, it consumes significant amount of time for preparing constants and functions. For example, it needs to load all the application-specific libraries which are explicitly loaded through include/require instructions. We cannot measure these potions through a command-line benchmark as we cannot redefine constants and functions in a loop. WARMING-UP It is better if other PHP runtime implementation can benefit from the benchmark we are creating. For instance, APC (PECL) code caching, on-demand compilation by Phalanger (.Net), and Java JIT compilation for Quercus (Resin) and P8 (WebSphere sMash) needs some warming up before reaching their typical performance. Maybe it is a must-support feature. To do this, giving some flexibility for warming the measured runtime is mandatory. An idea in my mind is to develop "purified" version of realistic Web applications, like SPECweb, but provide load generating scenarios that never put overwhelming load on Web servers, by omitting static file requests. Thanks, Mich


« previous php.qa (#64840) next »