Re:Ask HN: On scalability and memory footprint
by jgalvez on Saturday October 11, 2008 @09:31AM
(#329684)
AR usage is one of my main concerns. I myself am a Python guy with good proficiency and understanding of Rails, but we employ mostly Rails people. Our biggest project right now uses Rails for the API and website and several background daemons (work queues) in Python.
I'm already rewriting the API code in a minimal Merb app, which uses a lot fewer memory and can-haz C-based ORM code with DataMapper. My plan in the future is to try and push possible migration of the Rails-based site code to Merb as well.
Re:Ask HN: On scalability and memory footprint
by mixmax on Saturday October 11, 2008 @05:25AM
(#329606)
Interesting to see yet another company starting out with ruby on rails and then rewriting the whole thing in PHP when it has to scale. There seems to be a pattern to it...
Re:Ask HN: On scalability and memory footprint
by alecco on Saturday October 11, 2008 @09:50AM
(#329690)
Had a similar situation in a Python project. Got it working by adding a few Python callbacks to the SQL as functions. The code stayed in the same language and memory consumption flatlined. Don't know if that is easy to do from RnR, though.
Re:Ask HN: On scalability and memory footprint
by davidw on Saturday October 11, 2008 @03:56AM
(#329577)
You do know that you can connect to databases and do stuff in Ruby without AR, right?
Re:Ask HN: On scalability and memory footprint
by furiouslol on Saturday October 11, 2008 @04:24AM
(#329590)
Yes. That's what we did. But the memory usage was still higher than the PHP option.
Sure, we could process the data rows outside of Rails in C but because the processing of data rows is an integral part of the project, that would mean coding 80% in C and 20% in rails. Not exactly an enjoyable experience.
So we rewrote it in PHP and avoid objects and use just functions and hashes/arrays. And it worked very well for us. The site render time drops from 0.8s to 0.03s. Memory usage rarely exceeds 100MB.