Just a follow up to my previous post with the test Mark Waddingham ran when investigating this issue:
> My hypothesis for the reason for the latency is that on a shared server the > churn of memory is very high - caches get overwritten quickly as the working > set is not just that of one use, but of all uses of all users at that time. > Thus, if the irev engine has happened not be used in the very near past, it > and its associated files will not be in a cache. Similar for PHP. > > To test this hypothesis I used: > echo 3 > /proc/sys/vm/drop_caches > This command flushes all inactive in-memory caches the kernel currently holds > (inactive meaning nothing using that entry at that time). > > I then did four sample runs. The first is just 12 fetches form the PHP page, > the second is 12 fetches from the irev path, the third alternating for 12 > fetches starting with php and the fourth 12 fetches alternating starting with > irev: > > -- DROP CACHES > PHP Latency: 1921ms > PHP Latency: 336ms > PHP Latency: 342ms > PHP Latency: 342ms > PHP Latency: 322ms > PHP Latency: 330ms > PHP Latency: 342ms > PHP Latency: 338ms > PHP Latency: 346ms > PHP Latency: 331ms > PHP Latency: 326ms > PHP Latency: 345ms > > -- DROP CACHES > Rev Latency: 1298ms > Rev Latency: 316ms > Rev Latency: 316ms > Rev Latency: 321ms > Rev Latency: 319ms > Rev Latency: 316ms > Rev Latency: 319ms > Rev Latency: 321ms > Rev Latency: 316ms > Rev Latency: 309ms > Rev Latency: 314ms > Rev Latency: 322ms > Rev Latency: 321ms > > -- DROP CACHES > PHP Latency: 1637ms > Rev Latency: 515ms > PHP Latency: 330ms > Rev Latency: 306ms > PHP Latency: 340ms > Rev Latency: 303ms > PHP Latency: 342ms > Rev Latency: 312ms > PHP Latency: 331ms > Rev Latency: 308ms > PHP Latency: 336ms > Rev Latency: 313ms > > -- DROP CACHES > Rev Latency: 1295ms > PHP Latency: 1247ms > Rev Latency: 312ms > PHP Latency: 334ms > Rev Latency: 332ms > PHP Latency: 345ms > Rev Latency: 311ms > PHP Latency: 341ms > Rev Latency: 321ms > PHP Latency: 341ms > Rev Latency: 315ms > PHP Latency: 356ms > > The resulting evidence supports my hypothesis. Immediately after the 'flush > caches' command, the first use of PHP or Rev takes significantly longer. > Indeed, rev (in general) performs a little better than PHP in this regard (and > generally latency wise). This is not all that surprising for such a simple > script - I think PHP's initial working set is larger than rev's (i.e. the > amount of stuff it needs in memory to actually get going) and thus this > startup completely dwarfs the script's execution. > > This isn't in anyway comprehensive, nor really a good way to compare the two > technologies in this regard. Also, these results are entirely down to PHP on > on-rev working the same as revserver - i.e. in a cgi 'suexec' type > environment. I'm sure if the timings were done in a dedicated environment the > latency would vanish for them both. Kind regards, Kevin Kevin Miller ~ [email protected] ~ http://www.runrev.com/ RunRev - Software construction for everyone _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
