On Sat, Mar 19, 2005 at 07:29:38AM +0900, Eric Hodel wrote: > > 43 Things averages 46661 KB/Rails process (we peak at 200,000 > pageviews/day running 40 processes FastCGI across 2 servers). Most of > the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with > 2GB RAM), but peaks at about 0.50. i'm surprised you're using so much memory. is the 46MB number just rss, or rss+shared? i would expect your rss-per-process to be 1-10MB, with >10MB being indicative of leaks, unless you're doing lots of per-process caching, which doesn't make a lot of sense from a locality perspective anyways. > I was under the impression that Java takes up a much larger memory > footprint, but have never actually used it so I can't say how much > memory it takes. I have no idea how much CPU an equivalent Java site > would use. > > Please provide some relevant data about how much memory/CPU a Java site > would need to have equivalent performance. > > People have just managed to fit Rails into 64MB virtual servers. I > doubt you could do the same with a Java app. i can tell you that 64MB is quite doable with most j2ee containers, and in fact i would argue it's easier to constrain memory usage with java web apps than it is with ruby rails apps. while it's not as hungry as perl, ruby is pretty liberal with memory usage. i've had containers with 20+ server threads use 25MB, and i bet you could tune them even smaller than that if you stripped out non-essential features. it does depend on which container you use, though. with containers, you get a fixed cost for the container itself (10-20MB), and then a per-thread overhead of 100-200KB. just ruby itself on OS X takes 1.3MB rss per process, so you can see how much more memory ruby is using for each handler... as far as container memory usage goes, you can also use jvm switches to set min/max limits for jvm memory usage, so you can force java to stay within a given memory usage range, while the same is not true for ruby. you still have to make sure you don't create too many request threads and get an OutOfMemoryError, but it is a cleaner failure mode versus having the OS just kill your process without warning when you reach your limit. re: cpu usage, it would be interesting to do some benchmark comparisons. the major containers out there are pretty mature and have a lot of optimizations to help with GC; they reuse per-request objects, push declarations to the widest scope possible, avoid destruction, etc. servlets have deeper call chains when dealing with requests than webrick does, but when you factor in the near-C speed of modern jvms with the relatively mature containers out there, i would be surprised if rails could handle requests with less cpu time expended per-request or handle more aggregate requests per second than a servlet app. of course, i don't think that being the market leader in speed or memory usage is rails's goal. it's a lightweight and agile web app framework that lets you get things running 10x faster than any other framework out there. i think it's awesome, and the more i use rails, the more i like it. i just wanted to give some data points showing that java isn't the memory/cpu hog it is sometimes made out to be. i think rails is great for rapid development and prototyping, and for running small to moderate request loads, but if i'm deploying the app for enterprise request rates, i'm probably going to port it to java for the final deployment. hardware is cheap, but not that cheap. :-) doug -- "Contrary to what most people say, the most dangerous animal in the world is not the lion or the tiger or even the elephant. It's a shark riding on an elephant's back, just trampling and eating everything they see." -- Jack Handey