I''ve seen a lot of issue regarding the stability of Rails apps. I''m charged with investigation of Rails for my company and I''ve looked at numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* like there is a stability problem with Rails (ie: crashes, etc.) Is this as common as it looks, or is this tied to things like Lighttpd (web server) or Typo (Rails app) quirks? I''ve run PHP apps that have never crashed as far as I know and haven''t needed to restart Apache on those boxes. Can anyone verify if a Rails app is capable of staying up longer than a couple weeks before memory leaks (see the Ruby forum for recent memory leak issue), or some other issue hauls it down? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I can''t say I''ve experienced many stability issues. I''ve never had memory leaks for instance. The apps that I''ve deployed have thus far been very stable. The only time I''ve experienced problems was when we went from lighttpd to mongrel. We experienced a week of crashes that were rectified by going back to lighttpd. I don''t see Rails as having stability issues and as a former sys admin I understand where you are comming from. When rails initially came out I opted not to deploy it simply because I didn''t think there was a solid server stack supporting it. Now there are a variety of software stacks to run Rails off. I do feel that there needs to be work still to creating more of a standard in regards to rails server platforms. -m On 8/29/06, Leo Silver <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > charged with investigation of Rails for my company and I''ve looked at > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > like there is a stability problem with Rails (ie: crashes, etc.) Is > this as common as it looks, or is this tied to things like Lighttpd (web > server) or Typo (Rails app) quirks? > > I''ve run PHP apps that have never crashed as far as I know and haven''t > needed to restart Apache on those boxes. > > Can anyone verify if a Rails app is capable of staying up longer than a > couple weeks before memory leaks (see the Ruby forum for recent memory > leak issue), or some other issue hauls it down? > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I''ve worked with PHP for 6 years before migrating to Rails. I would absolutely not agree that PHP is in any way more stable than Rails. I set up my first heavy duty Rails application with the best practices detailed in "The Perfect Rails Stack"[1]. I did not experience any stability issues with that first application. It was at least as stable as any PHP application I''ve ever worked with, including those deployed and administered by sysadmins far more specialised and knowledgable than me. And yes, that first application and several others following it ran for weeks at a time, with zero adminning, zero restarts, and zero stability issues. It is still running today. There are several heavy-duty Rails applications[2], serving millions of requests a day[3]. Not sure where you got that information about supposedly rampant stabity concerns, but it runs contrary to my personal experience and to common knowledge of many others as well. -- [1] http://brainspl.at/rails_stack.html [2] http://rubyonrails.com/applications [3] http://poocs.net/articles/2006/03/13/the-adventures-of-scaling-stage-1 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I can see how you''d get that impression from the messages posted to the list, but my experience is that after you get through the inevitable "teething problems" of setting up a prod server running software you haven''t used before, Rails is very robust. I suspect most of the issues you''re reading about are from people still going through the learning curve; people who''ve got things set up and running smoothly typically don''t post that often about it... Regards Dave M. On 30/08/06, Leo Silver <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > charged with investigation of Rails for my company and I''ve looked at > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > like there is a stability problem with Rails (ie: crashes, etc.) Is > this as common as it looks, or is this tied to things like Lighttpd (web > server) or Typo (Rails app) quirks? > > I''ve run PHP apps that have never crashed as far as I know and haven''t > needed to restart Apache on those boxes. > > Can anyone verify if a Rails app is capable of staying up longer than a > couple weeks before memory leaks (see the Ruby forum for recent memory > leak issue), or some other issue hauls it down? > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
David Mitchell wrote:> I can see how you''d get that impression from the messages posted to > the list, but my experience is that after you get through the > inevitable "teething problems" of setting up a prod server running > software you haven''t used before, Rails is very robust. > > I suspect most of the issues you''re reading about are from people > still going through the learning curve; people who''ve got things set > up and running smoothly typically don''t post that often about it... > > Regards > > Dave M.Perhaps we should encourage people to chime in with good news. I can see it now... "OMG, my rails app is getting about ten thousands hits per hour and it hasn''t crashed yet; what should I do!!!!!????" :) jp -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Aug 29, 2006, at 2:51 PM, Leo Silver wrote:> > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > charged with investigation of Rails for my company and I''ve looked at > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > like there is a stability problem with Rails (ie: crashes, etc.) Is > this as common as it looks, or is this tied to things like Lighttpd > (web > server) or Typo (Rails app) quirks? > > I''ve run PHP apps that have never crashed as far as I know and haven''t > needed to restart Apache on those boxes. > > Can anyone verify if a Rails app is capable of staying up longer > than a > couple weeks before memory leaks (see the Ruby forum for recent memory > leak issue), or some other issue hauls it down? > > -- > Posted via http://www.ruby-forum.com/. >The http://yakimaherald.com/ website has been running since July 2005 on rails first on lighttpd/fcgi and now on apache2.2/ mod_proxy_balancer/mongrel_cluster and it runs for months at a time without restarts. Cheers- -Ezra --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
No stability problems for me... Mongrel Lighttpd PostgreSQL Rails Fedora Core 4 Keeps going and going, weeks and weeks, months and months... Joe -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I have had serious problems with stability on Windows, but I have not had any trouble with Ruby on Linux. I have upgraded to a box with more memory and faster CPU which has really helped the problems. When I saw crashing I was using windows box with low memory. That caused operations to take longer to run, and I think I was hitting a race condition in the MySQL driver. Now that I''ve got a faster box with more memory I haven''t had any crashes when I run rails. However, the same situation could arise from a server under heavy load and that race condition could come back. I wouldn''t be surprised if that is the same problem other people are seeing. While my new box has helped getting rid of the crashes when I run rails. The debugger is a different story. The debugger on windows won''t even work. It crashes in just a few seconds of coming up. It''s almost enough to make me quit using Rails altogether. Having a proper debugger is essential for productivity. I find it terribly ironic that a framework that predicates itself on productivity doesn''t have a working debugger. While you can go without a debugger it''s just faster to have one at your side when you need it. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Charlie Hubbard wrote:> > While my new box has helped getting rid of the crashes when I run rails. > The debugger is a different story. The debugger on windows won''t even > work. It crashes in just a few seconds of coming up. It''s almost > enough to make me quit using Rails altogether. Having a proper debugger > is essential for productivity. I find it terribly ironic that a > framework that predicates itself on productivity doesn''t have a working > debugger. While you can go without a debugger it''s just faster to have > one at your side when you need it.OMG!!! I''ve never had any problems with the debugger on my windows box since I started using Rails!!! What should I do????!!!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Windows debugger -- isn''t that an oxymoron? Joe -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
mark wrote:> Charlie Hubbard wrote: > > > > While my new box has helped getting rid of the crashes when I run rails. > > The debugger is a different story. The debugger on windows won''t even > > work. It crashes in just a few seconds of coming up. It''s almost > > enough to make me quit using Rails altogether. Having a proper debugger > > is essential for productivity. I find it terribly ironic that a > > framework that predicates itself on productivity doesn''t have a working > > debugger. While you can go without a debugger it''s just faster to have > > one at your side when you need it. > > OMG!!! I''ve never had any problems with the debugger on my windows box > since I started using Rails!!! What should I do????!!!!Yeah, it generally worked for me too. That said, *everything* works much better and more predictable on Linux (preferably Debian). Developing on a good Linux box, you basically don''t experience any random crashes and the like. It''s about as good as it gets, stability wise. Maybe a modern Mac is about is good. Windows definitely isn''t (no, not even a properly set-up XP). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> On Aug 29, 2006, at 2:51 PM, Leo Silver wrote: > > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > > charged with investigation of Rails for my company and I''ve looked at > > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > > like there is a stability problem with Rails (ie: crashes, etc.) Is > > this as common as it looks, or is this tied to things like Lighttpd > > (web > > server) or Typo (Rails app) quirks? > > > > I''ve run PHP apps that have never crashed as far as I know and haven''t > > needed to restart Apache on those boxes. > > > > Can anyone verify if a Rails app is capable of staying up longer > > than a > > couple weeks before memory leaks (see the Ruby forum for recent memory > > leak issue), or some other issue hauls it down? > > > > -- > > Posted via http://www.ruby-forum.com/.I suspect that the answer to this depends on how intensively your site operates and how well written the app is. I am aware of commercial J2EE apps with serious memory leak issues, requiring reboots of the server every few days. But the issue is not with J2EE, it is an acknowledged problem in the software. Memory leaks in Ruby/Rails apps have to be approached with an understanding that the platform will not prevent bad application code, it only makes it easier to write good application code. My observation is that Rails is mature enough for "bread and butter" applications, and I am using it for small-scaled systems. But it is still experiencing sufficient teething pains that I do not recommend it for "enterprise applications" where I work (I hate the overused and poorly defined designation "enterprise", but I don''t have a better designation at this time of the morning). The specific issues that I have against Rails are all maturity issues, not core architecture issues. That means that they will be addressed at some point in the future, although they may have a low priority with the Rails developers right now. 1. Rails builds every SQL request dynamically, instead of preparing the request once and then reusing the prepared statement. When I brought this up I was told that "The sanitize SQL method takes care of everything, and not all RDMS''s support prepared statements". The prepare phase of SQL execution can be over 80 percent of CPU usage on the database server, so turning this into a one-time cost at initialization will improve performance and scalability enormously. Sanitize methods increase CPU usage on the application, but do not decrease them on the RDBMS. What RDBMS'' do not support prepared statements? Even MS-Access supports prepared statements in some form. For "real work" am running against a database on a maxed out IBM 9000 series server that averages 85% CPU usage 24x7, and all of the efficiency tricks in the book have already been applied to existing apps in other platforms. The system administrator calls me up and says "Your little app is doing 10,000 prepares every hour and impacting everyone else'' performance - you''ll have to rewrite it before it goes back into production". I know that there are only a few SQL statements being executed over and over in my app, but apps on assorted other platforms will do one prepare each for a few hundred SQL once at deployment, and run for weeks with those few hundred prepares at startup. I sincerely hope that I have been misinformed on this point, and that I can be corrected. In the meantime, this is a serious showstopper for mid-to large sized shops. 2. A specifc few lines of code in the ActiveRecord are not sensitive to the possibility that the primary key of a system is not necessarily a sequential integer token. This impacts Rails'' usefulness in interfacing to some legacy databases and in distributed databases using UUID''s for primary keying. The fix is simple but I have not had the time and energy at the same time to submit the fix. I can''t claim the flaw, but I have to take the hit for not getting the fix submitted. This was a showstopper for using rails on a small-scale distributed application I worked on. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 8/30/06, David Johnson <johnson_d-j9pdmedNgrk@public.gmane.org> wrote:> > 1. Rails builds every SQL request dynamically, instead of preparing the > request once and then reusing the prepared statement. When I brought this up > I was told that "The sanitize SQL method takes care of everything, and not > all RDMS''s support prepared statements". > > The prepare phase of SQL execution can be over 80 percent of CPU usage on the > database server, so turning this into a one-time cost at initialization will > improve performance and scalability enormously. Sanitize methods increase > CPU usage on the application, but do not decrease them on the RDBMS. > > What RDBMS'' do not support prepared statements? Even MS-Access supports > prepared statements in some form. > > For "real work" am running against a database on a maxed out IBM 9000 series > server that averages 85% CPU usage 24x7, and all of the efficiency tricks in > the book have already been applied to existing apps in other platforms. >Mysql for one didn''t support prepared statements until the latest versions. When we started using prepared statements with earlier versions that supported them, we had numerous instability problems. Things might have changed since. Regardless of this, classes in Ruby are open. No one prevents you from opening an appropriate connection adapter and adding prepare statement support. That what we did anyways.> > 2. A specifc few lines of code in the ActiveRecord are not sensitive to the > possibility that the primary key of a system is not necessarily a sequential > integer token. This impacts Rails'' usefulness in interfacing to some legacy > databases and in distributed databases using UUID''s for primary keying. The > fix is simple but I have not had the time and energy at the same time to > submit the fix. I can''t claim the flaw, but I have to take the hit for not > getting the fix submitted. > > This was a showstopper for using rails on a small-scale distributed > application I worked on. >I hope you have time and energy for coping with other frameworks then. It was stated many times that Rails is not good for you when you use the database as an integration mechanism with external applications. Rails places numerous assumptions on your database schema, but most of them are configurable though. -- Kent --- http://www.datanoise.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Tue, 2006-08-29 at 18:22 -0700, Ezra Zygmuntowicz wrote:> > On Aug 29, 2006, at 2:51 PM, Leo Silver wrote: > > > > > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > > charged with investigation of Rails for my company and I''ve looked at > > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > > like there is a stability problem with Rails (ie: crashes, etc.) Is > > this as common as it looks, or is this tied to things like Lighttpd > > (web > > server) or Typo (Rails app) quirks? > >There actually are three remaining stability bugs in Mongrel that hit some folks: * LEAK: A slow memory leak when the site is hit with enough requests to trigger a leak that shows up in Ruby thread locking. This bug is fixed in the latest pre-release for POSIX systems, but not win32. * CLOSE_WAIT: Excessive numbers of sockets in CLOSE_WAIT state that cause a Mongrel process to stop answering requests. This appears to hit people who are behind Apache most, and especially those who are having Mongrel serve files. It also seems to be rare, but you can test it by running: lsof -i -P | grep CLOSE_WAIT and looking to see if they never go down. * 99% CPU: After running for a while, a Mongrel process will just eat CPU like crazy. This so far is rare and I can''t replicate this so I''m looking for people who have this happen and can let me onto their computer to look at the process when it happens. I''m currently working with people who have these problems, and hopefully will have it solved soon. If you are seeing these issues then please contact me so I can give you special builds of Mongrel and have you run a debugging process for me. Otherwise, very few people have reported these problems and the majority of them are doing strange things like accessing legacy databases. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 8/29/06, Jeff Pritchard <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Perhaps we should encourage people to chime in with good news. I can > see it now... > > "OMG, my rails app is getting about ten thousands hits per hour and it > hasn''t crashed yet; what should I do!!!!!????"Heh. One of my admin users sent me a note this morning complaining that the site was way too fast. Damn that pound + mongrel combo! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Kent Sibilev wrote:> On 8/30/06, David Johnson <johnson_d-j9pdmedNgrk@public.gmane.org> wrote: > > Mysql for one didn''t support prepared statements until the latest > versions. When we started using prepared statements with earlier > versions that supported them, we had numerous instability problems. > Things might have changed since. >I''ve had trouble considering MySQL to be a "real" RDBMS because, until recently, it did not pass the ACID test. It didn''t help that one of our vendors switched to MySQL for the back end a service that is mission critical to my company, and immediately suffered a number of costly outages over a period of several weeks. However, since MySQL bought Netfrastructure and hired Jim Starkey (architect and major developer of Firebird through all of its incarnations), things have been improving on that end. I expect to see some groundbreaking work from them in the next couple of years.> Regardless of this, classes in Ruby are open. No one prevents you from > opening an appropriate connection adapter and adding prepare statement > support. That what we did anyways.And that is what I intend to do ... about #8 on my list.> > > > 2. A specifc few lines of code in the ActiveRecord are not sensitive to the > > possibility that the primary key of a system is not necessarily a sequential > > integer token. This impacts Rails'' usefulness in interfacing to some legacy > > databases and in distributed databases using UUID''s for primary keying. The > > fix is simple but I have not had the time and energy at the same time to > > submit the fix. I can''t claim the flaw, but I have to take the hit for not > > getting the fix submitted. > > > > This was a showstopper for using rails on a small-scale distributed > > application I worked on. > > > > I hope you have time and energy for coping with other frameworks then.Actually, I usually toss out the frameworks entirely because the learning curve is too steep. 5 hours to code and test, then 60 hours to deploy under J2EE just doesn''t add up in my books. Rails is an exception, so far. It is the first framework I have used that has bought back enough time to more than make up for the learning curves. It''s just not quite there for core applications that really scale. Ruby and rails'' scaling issues are not in the design, but are all readily correctable (and are being corrected) as the codebase matures. I have seen the "10,000 hits per hour" (2.78 hits per second) figure bandied about in this thread. As long as this is the scale that is considered a heavy load, rails development will be tied firmly to the world of small and non-core systems. A core application can expect to see 60 hits per user per hour, or 60,000 hits per hour for 1,000 users. When I see someone saying "OMG my application has sustained 60,000 hits per hour for 90 continuous days and is still stable, what do I do?", then rails will have made it into prime time.> > It was stated many times that Rails is not good for you when you use > the database as an integration mechanism with external applications. > Rails places numerous assumptions on your database schema, but most of > them are configurable though. >The issues though are not with the core design, they are just maturity of the code base. A simple correction to a very few easily identified lines of code resolves this in most cases. When I get to #8 on my priority list, I will submit my proposed corrections so that these few lines (12 lines, I think) match other code in ActiveRecord. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
the guys of eins.de recently (around the beginning of 2006) switched to rails, and i read the articles about that yesterday. they have about 1M hits a day, most of them being within 14 hours), so they are at about 20 hits per second. possibly this article should interest you: http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1 2006/8/31, johnson_d-j9pdmedNgrk@public.gmane.org <johnson_d-j9pdmedNgrk@public.gmane.org>:> > > > Kent Sibilev wrote: > > On 8/30/06, David Johnson <johnson_d-j9pdmedNgrk@public.gmane.org> wrote: > > > > Mysql for one didn''t support prepared statements until the latest > > versions. When we started using prepared statements with earlier > > versions that supported them, we had numerous instability problems. > > Things might have changed since. > > > > I''ve had trouble considering MySQL to be a "real" RDBMS because, until > recently, it did not pass the ACID test. It didn''t help that one of > our vendors switched to MySQL for the back end a service that is > mission critical to my company, and immediately suffered a number of > costly outages over a period of several weeks. > > However, since MySQL bought Netfrastructure and hired Jim Starkey > (architect and major developer of Firebird through all of its > incarnations), things have been improving on that end. I expect to see > some groundbreaking work from them in the next couple of years. > > > Regardless of this, classes in Ruby are open. No one prevents you from > > opening an appropriate connection adapter and adding prepare statement > > support. That what we did anyways. > > And that is what I intend to do ... about #8 on my list. > > > > > > > 2. A specifc few lines of code in the ActiveRecord are not sensitive > to the > > > possibility that the primary key of a system is not necessarily a > sequential > > > integer token. This impacts Rails'' usefulness in interfacing to some > legacy > > > databases and in distributed databases using UUID''s for primary > keying. The > > > fix is simple but I have not had the time and energy at the same time > to > > > submit the fix. I can''t claim the flaw, but I have to take the hit > for not > > > getting the fix submitted. > > > > > > This was a showstopper for using rails on a small-scale distributed > > > application I worked on. > > > > > > > I hope you have time and energy for coping with other frameworks then. > > Actually, I usually toss out the frameworks entirely because the > learning curve is too steep. 5 hours to code and test, then 60 hours > to deploy under J2EE just doesn''t add up in my books. > > Rails is an exception, so far. It is the first framework I have used > that has bought back enough time to more than make up for the learning > curves. It''s just not quite there for core applications that really > scale. Ruby and rails'' scaling issues are not in the design, but are > all readily correctable (and are being corrected) as the codebase > matures. > > I have seen the "10,000 hits per hour" (2.78 hits per second) figure > bandied about in this thread. As long as this is the scale that is > considered a heavy load, rails development will be tied firmly to the > world of small and non-core systems. > > A core application can expect to see 60 hits per user per hour, or > 60,000 hits per hour for 1,000 users. When I see someone saying "OMG > my application has sustained 60,000 hits per hour for 90 continuous > days and is still stable, what do I do?", then rails will have made it > into prime time. > > > > > It was stated many times that Rails is not good for you when you use > > the database as an integration mechanism with external applications. > > Rails places numerous assumptions on your database schema, but most of > > them are configurable though. > > > > The issues though are not with the core design, they are just maturity > of the code base. A simple correction to a very few easily identified > lines of code resolves this in most cases. When I get to #8 on my > priority list, I will submit my proposed corrections so that these few > lines (12 lines, I think) match other code in ActiveRecord. > > > > >-- Michael Siebert <info-norLuBQQNv0t+8dGM1inlw@public.gmane.org> www.siebert-wd.de - Gedanken lesen www.stellar-legends.de - Weltraum-Browsergame im Alpha-Stadium --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Thursday 31 August 2006 02:02, Michael Siebert wrote:> the guys of eins.de recently (around the beginning of 2006) switched to > rails, and i read the articles about that yesterday. they have about 1M > hits a day, most of them being within 14 hours), so they are at about 20 > hits per second. possibly this article should interest you: > > http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1 >Yes, that''s volume worth talking about. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> I''ve had trouble considering MySQL to be a "real" RDBMS because, until > recently, it did not pass the ACID test. It didn''t help that one of > our vendors switched to MySQL for the back end a service that is > mission critical to my company, and immediately suffered a number of > costly outages over a period of several weeks.<...> However MySQL is good enough wor Wikipedia, Flick, Youtube, del.icio.us, LiveJournal, Technorati... Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> I have seen the "10,000 hits per hour" (2.78 hits per second) figure > bandied about in this thread. As long as this is the scale that is > considered a heavy load, rails development will be tied firmly to the > world of small and non-core systems. > > A core application can expect to see 60 hits per user per hour, or > 60,000 hits per hour for 1,000 users. When I see someone saying "OMG > my application has sustained 60,000 hits per hour for 90 continuous > days and is still stable, what do I do?", then rails will have made it > into prime time.We averaged about 6,000,000 pages per day for about a month (busy season)... http://img312.imageshack.us/img312/3569/alexavd9.png -philip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Yo EZ, Have a good tutorial on getting mongrel/apache running on a Debian server? On 8/29/06, Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > On Aug 29, 2006, at 2:51 PM, Leo Silver wrote: > > > > > I''ve seen a lot of issue regarding the stability of Rails apps. I''m > > charged with investigation of Rails for my company and I''ve looked at > > numerous fourms, groups, etc. (Textdrive, here, etc.) and it *seems* > > like there is a stability problem with Rails (ie: crashes, etc.) Is > > this as common as it looks, or is this tied to things like Lighttpd > > (web > > server) or Typo (Rails app) quirks? > > > > I''ve run PHP apps that have never crashed as far as I know and haven''t > > needed to restart Apache on those boxes. > > > > Can anyone verify if a Rails app is capable of staying up longer > > than a > > couple weeks before memory leaks (see the Ruby forum for recent memory > > leak issue), or some other issue hauls it down? > > > > -- > > Posted via http://www.ruby-forum.com/. > > > > > The http://yakimaherald.com/ website has been running since July > 2005 on rails first on lighttpd/fcgi and now on apache2.2/ > mod_proxy_balancer/mongrel_cluster and it runs for months at a time > without restarts. > > Cheers- > -Ezra > > > >-- seth at subimage interactive http://www.subimage.com/sublog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Aug 31, 2006, at 10:16 AM, subimage interactive wrote:> Yo EZ, > > Have a good tutorial on getting mongrel/apache running on a Debian > server? >Well you will ant to compile apache2.2.3 yourself. If you are anal about debian packaging then use chkinstall to do it so it will be packaged into a .deb as well. But here are the good config flags for a nice slim apache2.2.3/mod_proxy_balancer setup. the mongrel cluster part is easy once you get apache compiled and a good vhost set up. Here''s a good vhost: http://brainspl.at/articles/2006/06/12/apache2-2-vhost-template-for- mongrel-clusters configure flags for compiling a skinny apache: ./configure \ --with-mpm=worker \ --with-ssl \ --enable-alias \ --enable-cache \ --enable-auth-basic \ --enable-auth-digest \ --enable-authn-anon \ --enable-authn-default \ --enable-authn-file \ --enable-authz-default \ --enable-authz-host \ --enable-authz-user \ --enable-dir \ --enable-disk-cache \ --enable-expires \ --enable-mime \ --enable-mem-cache \ --enable-negotiation \ --enable-deflate \ --enable-http \ --enable-headers \ --enable-include \ --enable-log-config \ --enable-proxy \ --enable-proxy-balancer \ --enable-proxy-http \ --enable-rewrite \ --enable-setenvif \ --enable-so \ --enable-ssl \ --enable-threads \ --disable-actions \ --disable-asis \ --disable-authn-alias \ --disable-authn-dbd \ --disable-authn-dbm \ --disable-authz-dbm \ --disable-authz-groupfile \ --disable-authz-ldap \ --disable-authz-owner \ --disable-autoindex \ --disable-bucketeer \ --disable-case-filter \ --disable-case-filter-in \ --disable-cern-meta \ --disable-cgi \ --disable-cgid \ --disable-charset-lite \ --disable-dav \ --disable-dav-ds \ --disable-dav-lock \ --disable-distcache \ --disable-dbd \ --disable-dumpio \ --disable-echo \ --disable-env \ --disable-example \ --disable-ext-filter \ --disable-file-cache \ --disable-filter \ --disable-index \ --disable-indent \ --disable-imagemap \ --disable-imap \ --disable-info \ --disable-isapi \ --disable-ldap \ --disable-log-forensic \ --disable-logio \ --disable-mime-magic \ --disable-nw-ssl \ --disable-optional-fn-export \ --disable-optional-fn-import \ --disable-optional-hook-export \ --disable-optional-hook-import \ --disable-proxy-ajp \ --disable-proxy-connect \ --disable-proxy-ftp \ --disable-speling \ --disable-status \ --disable-suexec \ --disable-unique-id \ --disable-userdir \ --disable-usertrack \ --disable-version \ --disable-vhost-alias Cheers- -Ezra --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
The main problem I ran into with Debian is that ruby 1.8.2 is the standard. I''m guessing I''d have to recompile 1.8.4, then ImageMagick, and everything else (along with Apache) right? On 8/31/06, Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > On Aug 31, 2006, at 10:16 AM, subimage interactive wrote: > > > Yo EZ, > > > > Have a good tutorial on getting mongrel/apache running on a Debian > > server? > > > > Well you will ant to compile apache2.2.3 yourself. If you are anal > about debian packaging then use chkinstall to do it so it will be > packaged into a .deb as well. But here are the good config flags for > a nice slim apache2.2.3/mod_proxy_balancer setup. the mongrel cluster > part is easy once you get apache compiled and a good vhost set up. > > Here''s a good vhost: > > http://brainspl.at/articles/2006/06/12/apache2-2-vhost-template-for- > mongrel-clusters > > configure flags for compiling a skinny apache: > > ./configure \ > --with-mpm=worker \ > --with-ssl \ > --enable-alias \ > --enable-cache \ > --enable-auth-basic \ > --enable-auth-digest \ > --enable-authn-anon \ > --enable-authn-default \ > --enable-authn-file \ > --enable-authz-default \ > --enable-authz-host \ > --enable-authz-user \ > --enable-dir \ > --enable-disk-cache \ > --enable-expires \ > --enable-mime \ > --enable-mem-cache \ > --enable-negotiation \ > --enable-deflate \ > --enable-http \ > --enable-headers \ > --enable-include \ > --enable-log-config \ > --enable-proxy \ > --enable-proxy-balancer \ > --enable-proxy-http \ > --enable-rewrite \ > --enable-setenvif \ > --enable-so \ > --enable-ssl \ > --enable-threads \ > --disable-actions \ > --disable-asis \ > --disable-authn-alias \ > --disable-authn-dbd \ > --disable-authn-dbm \ > --disable-authz-dbm \ > --disable-authz-groupfile \ > --disable-authz-ldap \ > --disable-authz-owner \ > --disable-autoindex \ > --disable-bucketeer \ > --disable-case-filter \ > --disable-case-filter-in \ > --disable-cern-meta \ > --disable-cgi \ > --disable-cgid \ > --disable-charset-lite \ > --disable-dav \ > --disable-dav-ds \ > --disable-dav-lock \ > --disable-distcache \ > --disable-dbd \ > --disable-dumpio \ > --disable-echo \ > --disable-env \ > --disable-example \ > --disable-ext-filter \ > --disable-file-cache \ > --disable-filter \ > --disable-index \ > --disable-indent \ > --disable-imagemap \ > --disable-imap \ > --disable-info \ > --disable-isapi \ > --disable-ldap \ > --disable-log-forensic \ > --disable-logio \ > --disable-mime-magic \ > --disable-nw-ssl \ > --disable-optional-fn-export \ > --disable-optional-fn-import \ > --disable-optional-hook-export \ > --disable-optional-hook-import \ > --disable-proxy-ajp \ > --disable-proxy-connect \ > --disable-proxy-ftp \ > --disable-speling \ > --disable-status \ > --disable-suexec \ > --disable-unique-id \ > --disable-userdir \ > --disable-usertrack \ > --disable-version \ > --disable-vhost-alias > > > Cheers- > -Ezra > > > > >-- seth at subimage interactive http://www.subimage.com/sublog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Yes. Or upgrade to testing instead of sarge and you can get ruby1.8.4 and imagemagick and all that stuff thru apt. Or if you have to stay on sarge you can use apt-pinning to pin ruby1.8.4 from testing back into sarge. Or there is always backports too. I am still debating how I am going to reccomend installing ruby on the debian server I walk you thru installing in my book. I might just have people install ruby and friends from source and use chkinstall to install them as .deb''s. -Ezra On Aug 31, 2006, at 11:11 AM, subimage interactive wrote:> The main problem I ran into with Debian is that ruby 1.8.2 is the > standard. I''m guessing I''d have to recompile 1.8.4, then > ImageMagick, and everything else (along with Apache) right? > > On 8/31/06, Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > On Aug 31, 2006, at 10:16 AM, subimage interactive wrote: > > > Yo EZ, > > > > Have a good tutorial on getting mongrel/apache running on a Debian > > server? > > > > Well you will ant to compile apache2.2.3 yourself. If you > are anal > about debian packaging then use chkinstall to do it so it will be > packaged into a .deb as well. But here are the good config flags for > a nice slim apache2.2.3/mod_proxy_balancer setup. the mongrel cluster > part is easy once you get apache compiled and a good vhost set up. > > Here''s a good vhost: > > http://brainspl.at/articles/2006/06/12/apache2-2-vhost-template-for- > mongrel-clusters > > configure flags for compiling a skinny apache: > > ./configure \ > --with-mpm=worker \ > --with-ssl \ > --enable-alias \ > --enable-cache \ > --enable-auth-basic \ > --enable-auth-digest \ > --enable-authn-anon \ > --enable-authn-default \ > --enable-authn-file \ > --enable-authz-default \ > --enable-authz-host \ > --enable-authz-user \ > --enable-dir \ > --enable-disk-cache \ > --enable-expires \ > --enable-mime \ > --enable-mem-cache \ > --enable-negotiation \ > --enable-deflate \ > --enable-http \ > --enable-headers \ > --enable-include \ > --enable-log-config \ > --enable-proxy \ > --enable-proxy-balancer \ > --enable-proxy-http \ > --enable-rewrite \ > --enable-setenvif \ > --enable-so \ > --enable-ssl \ > --enable-threads \ > --disable-actions \ > --disable-asis \ > --disable-authn-alias \ > --disable-authn-dbd \ > --disable-authn-dbm \ > --disable-authz-dbm \ > --disable-authz-groupfile \ > --disable-authz-ldap \ > --disable-authz-owner \ > --disable-autoindex \ > --disable-bucketeer \ > --disable-case-filter \ > --disable-case-filter-in \ > --disable-cern-meta \ > --disable-cgi \ > --disable-cgid \ > --disable-charset-lite \ > --disable-dav \ > --disable-dav-ds \ > --disable-dav-lock \ > --disable-distcache \ > --disable-dbd \ > --disable-dumpio \ > --disable-echo \ > --disable-env \ > --disable-example \ > --disable-ext-filter \ > --disable-file-cache \ > --disable-filter \ > --disable-index \ > --disable-indent \ > --disable-imagemap \ > --disable-imap \ > --disable-info \ > --disable-isapi \ > --disable-ldap \ > --disable-log-forensic \ > --disable-logio \ > --disable-mime-magic \ > --disable-nw-ssl \ > --disable-optional-fn-export \ > --disable-optional-fn-import \ > --disable-optional-hook-export \ > --disable-optional-hook-import \ > --disable-proxy-ajp \ > --disable-proxy-connect \ > --disable-proxy-ftp \ > --disable-speling \ > --disable-status \ > --disable-suexec \ > --disable-unique-id \ > --disable-userdir \ > --disable-usertrack \ > --disable-version \ > --disable-vhost-alias > > > Cheers- > -Ezra > > > http://www.subimage.com/sublog/ > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Thursday 31 August 2006 11:00, Philip Hallstrom wrote:> We averaged about 6,000,000 pages per day for about a month (busy > season)...That''s a good testimonial. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Thursday 31 August 2006 07:27, Rimantas Liubertas wrote:> > I''ve had trouble considering MySQL to be a "real" RDBMS because, until > > recently, it did not pass the ACID test. It didn''t help that one of > > our vendors switched to MySQL for the back end a service that is > > mission critical to my company, and immediately suffered a number of > > costly outages over a period of several weeks. > > <...> > > However MySQL is good enough wor Wikipedia, Flick, Youtube, > del.icio.us, LiveJournal, > Technorati... >This is getting way off topic, and people''s favorite RDBMS'' get to be like a religion. I shouldn''t, but I''ll follow it up anyways because I''m a sucker for debate. MySQL has been making strides in the direction of ACID compliance. The purchase of NetFrastructure positions them to become a technical leader in the next generation of robust RDBMS'' for backing web applications. However, this future release is not the product we are talking about. I don''t like to bash MySQL, but their current product line does not fill the needs for core real-time business applications. None of your examples are core real-time business applications, with complex business logic that must share data concurrently with other dissimilar applications. They are all primarily web page providers that happen to be backed by an RDBMS. There is a difference between a web page service that happens to be backed up by an RDBMS and a high-volume mission critical real-time decision support system. Failure to understand that difference almost killed my vendor''s business. MySQL is ideal for backing mostly static web page services that have only a small amount of application logic, such as the examples that you provided. However, their definition of a transaction boundary (statement level) leaves holes where exceptions (rollbacks) can leave operations that should be atomic in reliable system in invalid states. For example, your banks ATM application inserts a transaction record that says you deposited $1,000,000 to your bank account, then immediately issues an update to your bank account balance in another table that says that you have that money in your account. However, an exception occurs in updating your account balance - power failure, intern Joe trips over the network cable and yanks it out, the page is deadlocked, or the windoze server blue screen''s. In MySQL, the transaction has been processed but you don''t have the money. You complain, a two week "needle in haystack" hunt ensues, and the IT director gets fired or goes to jail. In the more robust model, all you see is that there was a delay in processing the transaction. You inquire and find out that they had a server problem, but your money is now where it belongs. The IT director never even hears about it. But that is getting way off the topic of the thread - the only pertinent lesson for this thread is that the stability of the underlying RDBMS and the application software can impact the users perception of the stability of Rails, incorrectly. The three concerns must never be confused in the evaluation process. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> A core application can expect to see 60 hits per user per hour, or > 60,000 hits per hour for 1,000 users. When I see someone saying "OMG > my application has sustained 60,000 hits per hour for 90 continuous > days and is still stable, what do I do?", then rails will have made it > into prime time.That would only be 16 req/sec. At 37signals, we''re currently doing at least 40 req/sec during prime time on Basecamp alone. Then add Writeboard, Backpack, Campfire, and Tada list (which all run on the same 5-app server cluster). Others, like 43things.com, are doing more than 3 million dynamic requests per day. And I''m sure there are others doing even more than that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Thursday 31 August 2006 22:46, DHH wrote:> > A core application can expect to see 60 hits per user per hour, or > > 60,000 hits per hour for 1,000 users. When I see someone saying "OMG > > my application has sustained 60,000 hits per hour for 90 continuous > > days and is still stable, what do I do?", then rails will have made it > > into prime time. > > That would only be 16 req/sec. At 37signals, we''re currently doing at > least 40 req/sec during prime time on Basecamp alone. Then add > Writeboard, Backpack, Campfire, and Tada list (which all run on the > same 5-app server cluster). Others, like 43things.com, are doing more > than 3 million dynamic requests per day. And I''m sure there are others > doing even more than that. >This response shows that you understood my point. These applications give a very good baseline for stability based on volume of hits. This suite also appears to require a more business logic than the other applications that have been mentioned on this thread, and the performance demands of a real-time collaboration support system should not be underestimated. The 37signals suite should provide the original poster with a good foundation for evaluating Ruby and Rails stability. For the sake of completeness, the app I am using as my baseline for comparison is a Java servlet app that runs on a single server. It supports 1,000 concurrent users who, essentially, live in the application. Every hit performs complex real-time decision support and accounting transactions. The one server is, essentially, maxed out. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I''m having memory issues with rails at the moment, but I can''t say yet if it''s our fault or the fault of rails, lighty, fcgi, etc. Our site is very dynmic and is getting between 30k -40k hits per day and the memory uses of our fcgi processes grows very fast and we have to restart it once a day. Unfortunately, we haven''t been able to duplicate this problem off of the live server so we''re having a hard time tracking it down. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---