Reasons to use Phoenix instead of Rails

Re:Reasons to use Phoenix instead of Rails by sanderjd on Sunday November 26, 2017 @02:52PM (#15782626)

Yeah we struggled to keep our memory usage under 500M per worker. Sidekiq helped because it was able to use threads effectively, but especially when we were running resque workers, we could only handle tens of tasks per second, and often fell behind. I think Rails' autoload-the-world philosophy was a big part of the problem and we spent some time trying to untangle dependencies, but it was swimming against the stream.

I'm not sure if these same problems do or don't come up with Phoenix, but when I briefly used it, it did seem to have a smaller memory footprint.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by tychver on Monday November 27, 2017 @03:24AM (#15785683)

500MB per worker is totally standard. What happens is a job causes a huge array or hash to be allocated, and after it‘s finished the memory can’t be returned to the OS due to heap fragmentation. Java does some crazy stuff with compaction. C programs typically try and internally allocate into arenas to avoid it.

[ Parent | on HN ]

Re:Reasons to use Phoenix instead of Rails by 33degrees on Wednesday November 29, 2017 @01:14PM (#15809264)

The thing is we're not even using rails, it's a simple Sinatra app with ActiveRecord, so there's not much being loaded that's not being used. Could be the ActiveRecord itself is the problem though.

[ Parent | on HN ]