I am new to Ruby and Ruby On Rails and would like to see if someone can clairyf this: If I have an apache server with one fastcgi process, how many concurrent requests can my app handle? Is it just one? Or can one fastcgi process handle myltiplle requests at the same time in separate threads? If a single fastcgi process can handle multiple requests, how many? From what I understand rails will associate 1 database connection per fastcgi process is this true? thanks, scott. -- Scott F. Walter Scott F. Walter Principal Consultant Vivare, Inc. E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore!
scott, 1 process per process == 1 request at a time. rails does NOT use threading what so ever. and yes 1 connection per process On 8/14/05, Scott F. Walter <scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org> wrote:> I am new to Ruby and Ruby On Rails and would like to see if someone can > clairyf this: > > If I have an apache server with one fastcgi process, how many concurrent > requests can my app handle? Is it just one? Or can one fastcgi > process handle myltiplle requests at the same time in separate > threads? If a single fastcgi process can handle multiple requests, > how many? > > From what I understand rails will associate 1 database connection per > fastcgi process is this true? > > thanks, > > scott. > > -- > > Scott F. Walter Scott F. Walter > Principal Consultant > Vivare, Inc. > > E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org > E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org > Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore! > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Zachery Hostens wrote:>scott, > >1 process per process == 1 request at a time. > >rails does NOT use threading what so ever. > >and yes 1 connection per process > >On 8/14/05, Scott F. Walter <scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org> wrote: > > >>I am new to Ruby and Ruby On Rails and would like to see if someone can >>clairyf this: >> >>If I have an apache server with one fastcgi process, how many concurrent >>requests can my app handle? Is it just one? Or can one fastcgi >>process handle myltiplle requests at the same time in separate >>threads? If a single fastcgi process can handle multiple requests, >>how many? >> >> From what I understand rails will associate 1 database connection per >>fastcgi process is this true? >> >>thanks, >> >>scott. >> >>-- >> >>Scott F. Walter Scott F. Walter >>Principal Consultant >>Vivare, Inc. >> >>E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org >>E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org >>Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore! >> >> >> >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> > > > >so if my application needs to support 300 users inserting data in the database at the same time (I know ridiciulous) then I need to have 300 fastcgi processes? thanks, scott. -- Scott F. Walter Scott F. Walter Principal Consultant Vivare, Inc. E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore!
no you do not. it doesnt take a request 1second+ for each request (for the majority of requests)... and apache/lighttpd will queue connections waiting for a fastcgi process to become free to process the request. generally you see people running 5 fastcgi processes, or less for a common site. running to many on one cpu could actually probably slow your site down. lighttpd can set min/max fastcgi processes and you can set thresholds for when to start new processes/kill unused processes. On 8/14/05, Scott F. Walter <scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org> wrote:> Zachery Hostens wrote: > > >scott, > > > >1 process per process == 1 request at a time. > > > >rails does NOT use threading what so ever. > > > >and yes 1 connection per process > > > >On 8/14/05, Scott F. Walter <scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org> wrote: > > > > > >>I am new to Ruby and Ruby On Rails and would like to see if someone can > >>clairyf this: > >> > >>If I have an apache server with one fastcgi process, how many concurrent > >>requests can my app handle? Is it just one? Or can one fastcgi > >>process handle myltiplle requests at the same time in separate > >>threads? If a single fastcgi process can handle multiple requests, > >>how many? > >> > >> From what I understand rails will associate 1 database connection per > >>fastcgi process is this true? > >> > >>thanks, > >> > >>scott. > >> > >>-- > >> > >>Scott F. Walter Scott F. Walter > >>Principal Consultant > >>Vivare, Inc. > >> > >>E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org > >>E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org > >>Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore! > >> > >> > >> > >>_______________________________________________ > >>Rails mailing list > >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > >> > > > > > > > > > so if my application needs to support 300 users inserting data in the > database at the same time (I know ridiciulous) then I need to have 300 > fastcgi processes? > > thanks, > > scott. > > -- > > Scott F. Walter Scott F. Walter > Principal Consultant > Vivare, Inc. > > E: scott.walter-uosFFu51klvQT0dZR+AlfA@public.gmane.org > E: scott-APWf0AbNa2kIjDr1QQGPvw@public.gmane.org > Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore! > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi, Just wanted to add that if you check the relevant log files (development.log or production.log etc) you can see some stats about how many requests/sec you can expect to see for each action. This can give you a good idea about how many FastCGI processes you need to run. I''ve found that even just one FastCGI process does very well, and you should only really increase it if you need to. Keep in mind that each FastCGI process can eat up a lot of memory too - anywhere from about 20MB to over 100MB. -- Ben Myles railsapphosting.com
Ben Myles wrote:> Hi, > > Just wanted to add that if you check the relevant log files > (development.log or production.log etc) you can see some stats about > how many requests/sec you can expect to see for each action. This can > give you a good idea about how many FastCGI processes you need to run. > > I''ve found that even just one FastCGI process does very well, and you > should only really increase it if you need to. Keep in mind that each > FastCGI process can eat up a lot of memory too - anywhere from about > 20MB to over 100MB. >I assume that the FastCGI process is not free to process a new request until the response has been completely sent to the client. Is that right? If so, it would be dangerous to assume that the requests/sec on a LAN would be representative of performance over the Internet. regards Justin
Good point, but I don''t think that''s how it works. I''m pretty sure once the ruby code has been processed FastCGI hands over the output to the web server and is ready to process another request. But I may be wrong - anyone know for sure?> I assume that the FastCGI process is not free to process a new request > until the response has been completely sent to the client. Is that > right? If so, it would be dangerous to assume that the requests/sec on a > LAN would be representative of performance over the Internet.
Ben Myles wrote: > [Justin Forder wrote]>>I assume that the FastCGI process is not free to process a new request >>until the response has been completely sent to the client. Is that >>right? If so, it would be dangerous to assume that the requests/sec on a >>LAN would be representative of performance over the Internet.> Good point, but I don''t think that''s how it works. I''m pretty sure > once the ruby code has been processed FastCGI hands over the output to > the web server and is ready to process another request. But I may be > wrong - anyone know for sure?See the FastCGI white paper: http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm and the FastCGI specification: http://www.fastcgi.com/devkit/doc/fcgi-spec.html The request content, response content, and error information are passed over a single full-duplex pipe or TCP connection between the Web server and the FastCGI process. The FastCGI process sees them as stdin, stdout, and stderr. I wouldn''t expect the Web server to be able to buffer an arbitrarily large request or response. Some web applications deliberately hold the connection open and deliver the response incrementally, to achieve a pseudo-push effect. I would be surprised if CGI or FastCGI was implemented in a way that prevented this from happening. regards Justin
Thanks for the links, I''ll go over them in detail at some point today. If you''re right, in your scenario even half a dozen modem users could tie up a bunch of FastCGI processes for a long period of time effectively slowing the whole feel of the app significantly.>From experience, I''ve done a pseudo stress-test of a RoR site runningon 1 FastCGI process by running half a dozen wget''s simultaneously (from Australia, when the server''s in the US). It seemed to handle it fine and I didn''t see any delays. Ben On 8/18/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote:> Ben Myles wrote: > > > [Justin Forder wrote] > >>I assume that the FastCGI process is not free to process a new request > >>until the response has been completely sent to the client. Is that > >>right? If so, it would be dangerous to assume that the requests/sec on a > >>LAN would be representative of performance over the Internet. > > > Good point, but I don''t think that''s how it works. I''m pretty sure > > once the ruby code has been processed FastCGI hands over the output to > > the web server and is ready to process another request. But I may be > > wrong - anyone know for sure? > > See the FastCGI white paper: > > http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm > > and the FastCGI specification: > > http://www.fastcgi.com/devkit/doc/fcgi-spec.html > > The request content, response content, and error information are passed > over a single full-duplex pipe or TCP connection between the Web server > and the FastCGI process. The FastCGI process sees them as stdin, stdout, > and stderr. I wouldn''t expect the Web server to be able to buffer an > arbitrarily large request or response. Some web applications > deliberately hold the connection open and deliver the response > incrementally, to achieve a pseudo-push effect. I would be surprised if > CGI or FastCGI was implemented in a way that prevented this from happening. > > regards > > Justin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ben Myles railsapphosting.com
Ben Myles wrote:> Thanks for the links, I''ll go over them in detail at some point today. > > If you''re right, in your scenario even half a dozen modem users could > tie up a bunch of FastCGI processes for a long period of time > effectively slowing the whole feel of the app significantly. > >>From experience, I''ve done a pseudo stress-test of a RoR site running > on 1 FastCGI process by running half a dozen wget''s simultaneously > (from Australia, when the server''s in the US). It seemed to handle it > fine and I didn''t see any delays. > > BenBen, I see in the Apache mod_fcgi documentation http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html a statement that: "FastCGI application output is buffered by default. This is not the case for CGI scripts (under Apache 1.3). To override the default behavior, use the -flush option (not available for dynamic applications)." So I think you were right. This would enable mod_fcgi to determine the content size and set the HTTP header accordingly, and would prevent the use of mod_fcgi for "pseudo push" applications. If you want to do another experiment, you could try using a deliberately slowed-down client instead of wget. Code of this form could do as a starting point: require ''net/http'' host = ''www.fastcgi.com'' path = ''/devkit/doc/fastcgi-whitepaper/fastcgi.htm'' delay = 1.0 Net::HTTP.start(host) do |http| http.request_get(path) do |response| response.read_body do |segment| print segment sleep delay end end end With Ruby 1.8.2 on Windows, the segments of HTTP response content being read from the socket are limited to 1024 bytes in size, so a long response (like the FastCGI white paper I used here) gets broken into many pieces, with plenty of delay. regards Justin> > On 8/18/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: > >>Ben Myles wrote: >> >> > [Justin Forder wrote] >> >>>>I assume that the FastCGI process is not free to process a new request >>>>until the response has been completely sent to the client. Is that >>>>right? If so, it would be dangerous to assume that the requests/sec on a >>>>LAN would be representative of performance over the Internet. >> >>>Good point, but I don''t think that''s how it works. I''m pretty sure >>>once the ruby code has been processed FastCGI hands over the output to >>>the web server and is ready to process another request. But I may be >>>wrong - anyone know for sure? >> >>See the FastCGI white paper: >> >> http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm >> >>and the FastCGI specification: >> >> http://www.fastcgi.com/devkit/doc/fcgi-spec.html >> >>The request content, response content, and error information are passed >>over a single full-duplex pipe or TCP connection between the Web server >>and the FastCGI process. The FastCGI process sees them as stdin, stdout, >>and stderr. I wouldn''t expect the Web server to be able to buffer an >>arbitrarily large request or response. Some web applications >>deliberately hold the connection open and deliver the response >>incrementally, to achieve a pseudo-push effect. I would be surprised if >>CGI or FastCGI was implemented in a way that prevented this from happening. >> >>regards >> >> Justin >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> > > >
Just in case it interests anyone, using Justin''s code I came up with the results below for fetching the page: http://forum.railsapphosting.com/topic/show/5 . That''s running on just one FastCGI process. It seems that the FastCGI output is cached by default in Lighttpd too, as the 10 downloads which were started at the same time all received the data in about the same timeframe. BASELINE: time ./fetchdata.rb Done! real 0m13.228s user 0m0.350s sys 0m0.083s 10 RUNNING SIMULTANEOUSLY: real 0m15.341s user 0m0.383s sys 0m0.089s real 0m15.351s user 0m0.400s sys 0m0.089s real 0m15.406s user 0m0.390s sys 0m0.090s real 0m15.549s user 0m0.399s sys 0m0.089s real 0m15.489s user 0m0.379s sys 0m0.091s real 0m16.620s user 0m0.352s sys 0m0.086s real 0m16.625s user 0m0.389s sys 0m0.094s real 0m16.768s user 0m0.376s sys 0m0.089s real 0m16.832s user 0m0.398s sys 0m0.090s real 0m16.856s user 0m0.377s sys 0m0.092s
^^^ not cached, buffered. late night :-\ Ben
Ben Myles wrote:> Just in case it interests anyone, using Justin''s code I came up with > the results below for fetching the page: > http://forum.railsapphosting.com/topic/show/5 . That''s running on just > one FastCGI process. > > It seems that the FastCGI output is cached by default in Lighttpd too,^^^^^^ buffered, as you pointed out in your next post> as the 10 downloads which were started at the same time all received > the data in about the same timeframe.Thanks, Ben - that removes some concerns I was getting about possible (easy) denial of service attacks on FCGI Rails apps. regards Justin (PS - whereabouts in Australia?)
On 8/19/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote:> (PS - whereabouts in Australia?)Brisbane. Not over here yourself are you? Speaking of which, any other aussies on this list? Ben
Ben Myles wrote:> On 8/19/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: > >>(PS - whereabouts in Australia?) > > Brisbane. Not over here yourself are you?No, I just have fond memories of working for a year in Melbourne, and taking some good holidays in that time. Justin
Hey Ben, Just got to your thread on the list (went away - 300 threads unread) and I''m working in a company in South Brisbane called Tangelix... top secret application though ;) Just thought I''d drop you a line so that you know there _are_ more of us out here.. Dan On 8/20/05, Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8/19/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: > > (PS - whereabouts in Australia?) > > Brisbane. Not over here yourself are you? > > Speaking of which, any other aussies on this list? > > Ben > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Sydney here :) On 20/08/2005, at 2:42 AM, Ben Myles wrote:> On 8/19/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: > >> (PS - whereabouts in Australia?) >> > > Brisbane. Not over here yourself are you? > > Speaking of which, any other aussies on this list? > > Ben > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Nice! Maybe there''s enough aussies on here after all to organise some kind of gig at the end of the year - get to know each other in person? Ben On 8/25/05, Julian Leviston <julian-AfxEtdRqmE/tt0EhB6fy4g@public.gmane.org> wrote:> Sydney here :) > > > On 20/08/2005, at 2:42 AM, Ben Myles wrote: > > > On 8/19/05, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: > > > >> (PS - whereabouts in Australia?) > >> > > > > Brisbane. Not over here yourself are you? > > > > Speaking of which, any other aussies on this list? > > > > Ben > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> On 8/25/05, Julian Leviston <julian-AfxEtdRqmE/tt0EhB6fy4g@public.gmane.org> wrote: > >>Sydney here :)Likewise. -- We develop, watch us RoR, in numbers too big to ignore.
Over here, in Perth! On 8/25/05, Mark Reginald James <mrj-bzGI/hKkdgQnC9Muvcwxkw@public.gmane.org> wrote:> > > > On 8/25/05, Julian Leviston <julian-AfxEtdRqmE/tt0EhB6fy4g@public.gmane.org> wrote: > > > >>Sydney here :) > > Likewise. > > -- > We develop, watch us RoR, in numbers too big to ignore. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jordan Brock Spin Technologies www.spintech.com.au <http://www.spintech.com.au> _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Melbourne! -DF On 8/25/05, Jordan Brock <jordan-gs9ls/6d/500n/F98K4Iww@public.gmane.org> wrote:> Over here, in Perth! > > > On 8/25/05, Mark Reginald James <mrj-bzGI/hKkdgQnC9Muvcwxkw@public.gmane.org> wrote: > > > > > On 8/25/05, Julian Leviston <julian-AfxEtdRqmE/tt0EhB6fy4g@public.gmane.org> wrote: > > > > > >>Sydney here :) > > > > Likewise. > > > > -- > > We develop, watch us RoR, in numbers too big to ignore. > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > Jordan Brock > Spin Technologies > www.spintech.com.au > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Melbourne here, and I know of one other person on the list who''s also in Melbourne. (I''ll let him name himself if he wants to be named.)
Maybe we oughta use meetup.com to organise some meetings? Like everywhere :) Julian. On 25/08/2005, at 11:05 PM, Pete Yandell wrote:> Melbourne here, and I know of one other person on the list who''s > also in Melbourne. (I''ll let him name himself if he wants to be > named.) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >