Is there a way to free up memory used by required gems? My Rails app grows in memory usage and I would like to use gems only when I need them and after that free them up, IF this is possible.
Thanks!
The whole purpose of a memory managed programming language (Ruby) is to avoid developers having to concern themselves with such issues.
If memory does become a sticking point, you'll need to profile the memory by using the following tools
ruby/ruby on rails memory leak detection
Although your control over memory is limited to ensuring memory leaks are avoided and the overall architecture is inline with best practices. An example is ImageMagick takes excessive memory, so rather than having images being converted by all rails mongrels/passengers, restricting the conversion to dedicated ruby services, so as to avoid a large memory footprint.
The Garbage Collector do it this best to you. There are no better solution. Check all part where you can have some memory leak and avoid it. Use less of gems too.
Related
Is it possible to know how much memory a program will need?
The usual method is to use some form of profiler. Many IDEs include their own, Netbeans for example has a particularly good profiler (in my opinion) for Java applications. This will show the memory consumption of your program as its running, and is good for testing for things such as memory leaks as well as overall consumption.
If you've only got the binary, then you'll just have to use a basic tool such as task manager or pmap. This won't give you nearly as much detail though.
if you're using an IDE then it will probably have some in-built feature by which you can see the same...
In case you are executing directly, I guess probably the Task Manager is the best way.
What impact, if any, does having A LOT of gems have on the performance of your Rails app?
I would say the biggest impact is when your rails app starts up, as the gems are all loaded into memory. If you have lots of gems loaded, chances are you'll also have a lot of code loaded that your app doesn't use, so one way to cut down on the memory usage is to take advantage of copy-on-write support in the linux kernel. One way to do this is to use ree and unicorn, as github did
This is just an assumption though. You should always profile your app when dealing with timing and memory questions. It can make a really useful blog post.
no impact on performance. It's just a problem of memory. You memory can be very big with so much gem and if you really use it.
I have to run a Web server with many services on an embedded server with limited RAM (1 GB, no swap). There will be a maximum of 100 users. I will have services such as a forum, little games (javascript or flash), etc.
My team knows Ruby on Rails very well, but I am a bit worried about Rails' memory usage. I really do not want to start a troll here, but I am wondering if there are any serious (i.e. documented) benchmarks comparing Rails, Django, CakePHP or any other PHP framework?
Could you please point to benchmarks or give me your opinion about Rails' memory usage? Please please please no troll.
In terms of memory usage it's generally going to be Python > Ruby > PHP, which of course leads to Django > Rails > CakePHP. Not just memory but that also tends to hold for raw performance. EDIT: Also worth noting that there are, of course, no absolutes here. There are plenty of usage scenarios in which Ruby will beat Python, hands down. I think we can all agree that Ruby and Python will always beat PHP, though :)
Here's a straight-forward 3-way benchmarking (with Symfony on the PHP side of things) that bears out the above: http://wiki.rubyonrails.com/rails/pages/Framework+Performance. Though of course it's easy to find stats to support your own viewpoint :)
That said, it's still very easy to make a crappy, slow, and inefficient Django application and a lean, fast, and efficient Rails application, or vice-versa. Skill, knowledge, and expertise with the system you are using will do far more for its memory and performance footprint than just the framework itself. Database optimizations, server choices and architectures (Apache vs. proxy setups using nginx/lighttpd, etc.), and fundamental design decisions are likely going to overwhelm the framework's inherent characteristics pretty quickly.
So I guess what I'm saying is if your team knows Rails, and your expertise lies in Rails, I would stick with Rails.
I just stumbled upon this benchmark which looks pretty good. It just gives data about Rails' memory usage (and performance) but it only partially answers the question because it does not compare Rails with other frameworks.
http://www.rubyenterpriseedition.com/comparisons.html
My own experience is that Rails memory usage can be high, especially on 64 bit machines (min. is around 95-100 MB with thin as web front-end). PHP tends to be used with different patterns so it is a bit difficult to compare directly.
Hypothetically, if I were to build the same app using a few popular/similar frameworks, say PHP(cakePHP|Zend), Django, and Rails, should the memory consumption of each be roughly the same?
Also, I'm sure many have evaluated or used each and would be interested in which you settled on and why?
Code with whatever framework you like best. Then pray your app is popular enough to cause memory problems. We should all be so lucky.
No, it will absolutely vary wildly from one framework to another.
That said, in most cases the memory footprint of the framework is not the determining factor in site performance nor in selection of a framework. It's usually more a matter of using the right tool for the job, since each framework has its own strengths and weaknesses.
It is hard to efficiently say, I would say that PHP frameworks will have mostly a similar footprint, which is typically less than other frameworks such as Rails and Django. But it depends what you include as rails, such as mongrel (rails server proxy). Overall it depends on your code as well however PHP will most of the time give an easier time on the server. (Without any language Bias, I use both PHP and Rails)
Just for getting some perspective let me report a real case memory consumption using a Smalltalk web framework AIDA/Web.
For running 40+ websites on a single Smalltalk image on a single server it currently consumes 330MB of memory.
The only one of those frameworks I have used is CakePHP. I found that it's not to bad footprint wise however it is a lot more heavy that normal PHP without using a framework obviously but can be a good trade off.
A good comparison of some of the most popular PHP frameworks can be found at http://www.avnetlabs.com/php/php-framework-comparison-benchmarks.
Memory is cheap these days. Go with what will make your development easiest (which is usually what your team knows best).
But... In my experience, Django isn't terribly memory hungry. I've run it on my shared host with less than 100 MB of RAM. But my experience is sheerly anecdotal. YMMV. If you go with Django, here are some tips to keep memory usage down.
EDIT: And don't go with zope if memory footprint is important to you.
I have been hacking with Ruby from time to time, but I haven't done anything big or multithreaded with it. I have heard that MRI only supports green threads and JRuby supports native threads via JVM. However, I stumble upon comments on blogs and discussion groups which say that "Rails is not thread-safe" or that Ruby itself is not thread safe. For example someone commented that there is a problem with the require statement. That sounds a bit fundamental.
I have seen a lot of Java apps which don't handle concurrency properly and I have nightmares about them from time to time :-) But at least you can write thread-safe applications in Java if you really know what you are doing (it's just not easy).
This all sounds quite alarming, can someone elaborate more - what is exactly the problem and how Rails manages to work at all if this is the case? Can I write multithreaded Ruby code which works correctly without race conditions and deadlocks? Is it portable between JRuby and MRI or do I have to hack in JVM specific code to take advantage of the JVM native threads properly?
EDIT:
I should have asked two questions, because people only seem to answer the rails threading stuff (which is nice in itself) and green threading vs. native threading. My concerns on core Ruby issues about thread safety haven't really been addressed. There seems to be at least an (unresolved?) issue with require in certain cases.
First and foremost, Ruby 1.9 (the most recent official release) now uses native (kernel) threads. Previous versions of Ruby used green threads. To answer your question succinctly, prior to 1.9, threads have not commonly been used in Ruby applications large or small precisely because they're not particularly safe or reliable.
This is not particularly alarming because prior to version 2.2 Rails made no attempt to be threadsafe, and so we typically handle asynchronous processing through the use of multiple processes, database record locking, and message queues like Starling. This is generally a pretty reliable way to scale a web application--at least as reliable than incorrectly multithreaded Java applications--and has the added advantage that it becomes easier to scale your application sideways to multiple processors and servers.
I have no idea whether the 'require' issue you've mentioned has been resolved as of 1.9, but I do humbly venture that if you're requiring libraries dynamically in new threads then you have more than one maintainability problem.
If you'd like to avoid threads entirely, Ruby 1.9 also supports fibers, which employ a shared-nothing approach to concurrency and are, from what I gather, generally easier to write and maintain than threads. Performance numbers here.
I really suggest you to watch Jim Weirich`s speech from RubyConf 2008 (it's very funny and informative:) :
https://www.youtube.com/watch?v=fK-N_VxdW7g
This one is nice too:
http://rubyconf2008.confreaks.com/summer-of-code-rails-thread-safety.html
The normal solution for MRI is to run multiple Rails instances, each handling requests independently. Since MRI isn't multithreaded anyway, you can't run multiple Rails instances on top of it. This means you take a memory hit since Rails is loaded once per Ruby process.
Since JRuby supports native threads, you could always run several Rails instances in a single JVM. But with Rails being thread-safe, you can cut it down to one, which means lower memory usage and less JIT compilation.
Charles Nutter (JRuby) has a nice summary.
I think the previous posters covered the Rails cases pretty well, so I won't bother going into that sort of stuff.
It's certainly possible to write threaded Ruby applications. Some of the problems that exist with ruby threads is that they are 'green' in as they are managed by the virtual machine. Currently, the default interpreter (MRI) only has one true system thread that need to be shared by all of the threads that the interpreter has control over.
The downside to this is that if you have a computer with multiple processors or cores you can't have a thread in your application running on some other core. This is a pretty big deal for people running servers and high performance apps.
As for your interpreter-specific-code question: I don't think so. AFAIK you don't have to do anything special to take care of JRuby/JVM threads.
Also: This article over on Igvita that takes a good look at the state of concurrency in Ruby.