4 ms·
We have two main stacks at my company. One is Rails-based, the other is a mix of C++ and Java. The tasks that the C++ and Java side do is significantly more c
by wheels 14y ago
We have two main stacks at my company. One is Rails-based, the other is a mix of C++ and Java. The tasks that the C++ and Java side do is significantly more complex (real-time graph-traversal and number crunching) than what Rails is doing.
On similarly sized server instances our Rails stack can handle about 10 requests per second, whereas our C++ / Java stack can handle about 400.
In practice the only time that I've seen the database be the bottleneck in Rails is when the database is accessed by people that pretend that ActiveRecord is in-process data and just use it like it's not querying a database (e.g. I've seen pageviews that require 30+ SQL queries). That or their database is set up in stupid ways and doesn't have indexes in the right places.
Rails is actually very slow. That said, I think a smarter approach than recreating the framework in faster languages would be to allow C or C++ into the main Rails project and to rewrite the hot parts in one of them. We sped up ActiveResource by about 35x by reimplementing it in C++ (with no changes required to our apps).
- rbanffy 14y ago> our Rails stack can handle about 10 requests per second Is this representative? I built JMeter testing into a series of Django apps I built for the portal I worked for and the numbers were consistently higher. I always assumed they were similar in performance.
- deleted 14y ago[deleted]
- aaronblohowiak 14y agoNot representative for senior devs who have put any meaningful time into performance tweaking.
- rurounijones 14y agoTotally meaningless number since we have no idea what the Rails app is doing.
- rbanffy 14y agoI think that if the app were doing something extraordinary, wheels would mention it. The ones i built Jmeter testing do straightforward database queries, HTML (sometimes image) rendering and queuing stuff for future processing. In any case, I haven't tried to optimize them (memcache and front-end caching were kept minimal and implementation as simple as possible) before going live (after, of course, making sure they were load-tested and would survive a reasonable load) so we could watch what breaks under load, compensate with extra iron, and correct it later. All those machines were heavily monitored.
- derwiki 14y ago> We sped up ActiveResource by about 35x by reimplementing it in C++ (with no changes required to our apps). What version of Rails is this? And can I talk you into open-sourcing it, if you haven't already? :)
- sayrer 14y agoQActiveResource is pretty cool. It looks like it might leak in the presence of Ruby exceptions, though. When I do this sort of thing, I wrap ruby.h function calls with rb_protect, check the return code, and then throw a C++ exception to unwind the stack. There is an allocation cost to doing that.