Memory paging in crowdAI about crowdai HOT 5 CLOSED

http://www.slideshare.net/heroku/optimizing-production-apps-on-heroku-73113

from crowdai.

• upgraded memory and the database
• turned off caching

f79cb39
now is lighting fast, but this is not an ideal solution.

from crowdai.

Related #59

from crowdai.

Notes

• Puma is a multithreaded server and MRI is single threaded. Puma will work best with Rubinius or JRuby.
• There is a gem configuring a default plugin, but the contents can be easily added to the initializer https://github.com/puma/puma-heroku/blob/master/lib/puma/plugin/heroku.rb

Because MRI doesn't have "real threads", ideally there would be at least one worker
for each CPU core. Heroku 1x, 2x, and Performance-M dynos each have 8 cores. Performance-L
dynos have 2 cores.

It's often not possible to have a worker per core, because of memory constraints.
For example, a medium to large rails app on a Heroku 2x dyno will take up 300-550 megs, which
alows for only running 1-3 workers.

Some references

https://github.com/puma/puma-heroku

http://julianee.com/rails-sidekiq-and-heroku/

http://stackoverflow.com/questions/8821864/config-assets-compile-true-in-rails-production-why-not

puma/puma-heroku#4

from crowdai.

Moving research to the Wiki https://github.com/crowdAI/crowdai/wiki/Profiling

This issue has been solved & closed, assets are back online.

from crowdai.