Thanks Steve. I did try bare rack for file uploads and it was great: fast, non-blocking, tiny memory footprint. However, I then realized that I need authentication and a bunch of other stuff. I though about writing it myself in rack (e.g. read the request, get username&password, etc.). Of course, this would have been dumb (not DRY at all) since Merb already offers it all.
And btw, I don't know how you got 46MB for the Rails app. I coded the same functionality(authentication + file upload using attachment_fu) in a Rails application and the System Monitor on Ubuntu shows 32.7MB (starts at 27MB and after the first upload it jumps to 32.7MB, and it stays there). I guess 30MB X 9 isn't that bad. We'll just buy more RAM if we run into trouble. Thanks, Tiberiu On Feb 26, 11:42 pm, Stephen Eley <[email protected]> wrote: > On Wed, Feb 25, 2009 at 12:02 PM, Mr_Tibs <[email protected]> wrote: > > > Thanks for the reply. I have to ask: what is then the advantage of > > using Merb over Rails? From what I was reading online, since Merb is > > modularized (e.g. use what you need), it is supposed to have a smaller > > memory footprint than Rails. A Rails cluster (even though it shares no > > memory) would be just as big as a Merb cluster. > > I'd have to disagree with you there. 30 MB after decoupling is really > quite small compared to Rails. On a lark, I just opened up a terminal > prompt and typed "rails helloworld" and ran script/server, with no > code modifications whatsoever. According to top the resident size was > 46 MB. That's just from initialization, before even hitting a page. > > Anyway, percentage differences between resident memory sizes aren't a > great reason for making a choice as fundamental as which framework to > use. If that's the only criterion you'd use to gauge 'advantage,' > maybe you should be using Sinatra or Camping. Or a bare method on top > of Rack. >8-> > > Think about where your comfort levels are instead. Merb offers > flexibility, efficiency, real multithreading with render_then_run > behavior, cleaner code with consistent design philosophies, and a > router that blows away anything else. Rails offers maturity, tons of > plugins, and a much broader community. It's much more likely with > Rails that any wheel you need has already been invented, and overall > it's better documented. > > Of course it'll all be academic soon, as within several months they're > going to be the same thing. But I personally have confidence that > that'll just mean Rails getting more efficient and more flexible. > > > Any way I can get that memory footprint down? > > Well, you could try Ruby Enterprise Edition. It's designed to help > specifically with this sort of thing. Other than that, if 9 workers > at 30 MB each is too much, you're really going to need either to run > fewer workers or get a VPS (I assume) with more memory. The sizes > you're talking about really aren't bad by modern app standards, and I > doubt there's much code improvement that could be easily done to > reduce them. > > -- > Have Fun, > Steve Eley ([email protected]) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
