[revServer] process timeout issue

[Richard Gaskin]

Andre Garzia wrote:

> oh that is *fast* :-O

Last year I had one of my fits of obsession about performance and began 
experimenting with Dreamhost's FastCGI interface for the Rev CGI.  It 
was complicated to set up, and for all the reasons you noted here at the 
time it was very complicated to write for.

So instead I decided to set it aside and go back to the straight CGI 
interface to see if I found any serious bottlenecks.  I found none, and 
the clarity of writing for a non-persistent process kept everything 
simple.  I added a reasonably simple token file+cookie scheme for 
persistent data when needed, but for most uses I don't even need that, 
and with or without that it's been quite speedy.

On the desktop the engine loads faster than most other apps, and on the 
server - without needing to initialize the GUI -- it loads about as fast 
as a server can pull its mere 2.5 MB executable up from the 7200 RPM disk.

I've not done much in the way of formal testing because I haven't yet 
found a good means of accounting for sever/transfer latency as distinct 
from the Rev process itself.  But the server-side testing I've done 
shows the CGI engine running at speeds better than on my Mac (not 
surprising; Dreamhost uses some good systems), and the subjective 
experience of the overall throughput has been quite satisfying for 
myself and my site's visitors.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv


> On Tue, Aug 3, 2010 at 1:52 PM, Mark Wieder <mwieder at ahsoftware.net> wrote:
>
>> hi-
>>
>> I'm late to the party, I know, but I wanted to post that my resultsat
>> were similar within the 99% range, with the longest taking just a
>> shade over two seconds and 75% of the requests coming in under 100
>> milliseconds. And that's *very* impressive considering the fact that
>> if I ping woooooooords.com I get an 86 millisecond response, so the
>> server overhead in processing my response accounts for some 14
>> milliseconds in most cases.
>>
>> I launched the two tests concurrently to stress things
>> out a bit more, but that didn't seem to affect the results.
>>
>> ---------------------------
>>
>> Benchmarking woooooooords.com (be patient)
>> Finished 2975 requests
>>
>>
>> Server Software:        Apache/2.0.63
>> Server Hostname:        woooooooords.com
>> Server Port:            80
>>
>> Document Path:          /index.html
>> Document Length:        417 bytes
>>
>> Concurrency Level:      10
>> Time taken for tests:   30.001 seconds
>> Complete requests:      2975
>> Failed requests:        0
>> Write errors:           0
>> Non-2xx responses:      2975
>> Keep-Alive requests:    2953
>> Total transferred:      2322450 bytes
>> HTML transferred:       1240575 bytes
>> Requests per second:    99.16 [#/sec] (mean)
>> Time per request:       100.844 [ms] (mean)
>> Time per request:       10.084 [ms] (mean, across all concurrent requests)
>> Transfer rate:          75.60 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>              min  mean[+/-sd] median   max
>> Connect:        0    1  10.7      0     124
>> Processing:    92  100  47.8     97    1845
>> Waiting:       92  100  47.8     97    1845
>> Total:         92  101  52.6     97    1964
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%     97
>>  66%     98
>>  75%     99
>>  80%    100
>>  90%    102
>>  95%    108
>>  98%    122
>>  99%    185
>>  100%   1964 (longest request)
>>
>> Benchmarking woooooooords.com (be patient)
>> Finished 2835 requests
>>
>>
>> Server Software:        Apache/2.0.63
>> Server Hostname:        woooooooords.com
>> Server Port:            80
>>
>> Document Path:          /index.irev
>> Document Length:        417 bytes
>>
>> Concurrency Level:      10
>> Time taken for tests:   30.002 seconds
>> Complete requests:      2835
>> Failed requests:        0
>> Write errors:           0
>> Non-2xx responses:      2835
>> Keep-Alive requests:    2815
>> Total transferred:      2213245 bytes
>> HTML transferred:       1182195 bytes
>> Requests per second:    94.49 [#/sec] (mean)
>> Time per request:       105.829 [ms] (mean)
>> Time per request:       10.583 [ms] (mean, across all concurrent requests)
>> Transfer rate:          72.04 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>              min  mean[+/-sd] median   max
>> Connect:        0    1  12.0      0     145
>> Processing:    92  104 106.2     97    2069
>> Waiting:       92  104 106.2     97    2069
>> Total:         92  106 113.3     97    2191
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%     97
>>  66%     98
>>  75%     99
>>  80%    100
>>  90%    103
>>  95%    110
>>  98%    117
>>  99%    197
>>  100%   2191 (longest request)
>>
>> --
>> -Mark Wieder
>>  mwieder at ahsoftware.net
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
>
>
> --
> http://www.andregarzia.com All We Do Is Code.