Kevin, Why all this benchmarking? Why not just put Jerry's script on the server, send Jerry's data to the script, and see what happens? If Jerry doesn't want you to see the data or the script then there isn't much you can do, I guess. But the technological solution doesn't seem that difficult.
Mike --- On Wed, 8/4/10, Kevin Miller <ke...@runrev.com> wrote: From: Kevin Miller <ke...@runrev.com> Subject: Re: [revServer] process timeout issue - basic benchmarking To: "How to use Revolution" <use-revolution@lists.runrev.com> Date: Wednesday, August 4, 2010, 6:04 PM 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 ~ ke...@runrev.com ~ http://www.runrev.com/ RunRev - Software construction for everyone _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
