4 ms·

I have misgivings about ruby, but for the majority of the sites I work on CPU-burn isn't the issue. The second I touch a network resource (typically the databa

I have misgivings about ruby, but for the majority of the sites I work on CPU-burn isn't the issue. The second I touch a network resource (typically the database) all the hand-crafted assembler in the world ain't gonna save me. A stronger argument for a rails rip off in a statically typed language would be tool support, esp. consistent code completion.

yummyfajitas 14y ago
I don't know why you are being downmodded. You are precisely on point - in Python (a slow language, similar to ruby), I'd often spend 50-500ms in the db (or 10-100ms in memcached) and 1-10ms in code. Optimize your sql, then optimize your memcached. That said, I've recently been working on a project building a webapp in Scala. The type safety Scala gives is amazing. Want to write to master then read from a slave in the same http request [1]? Won't compile. Want to build a page without a tracking beacon? Won't compile. Want to prevent invalid input to enum fields (e.g., a string for which the only valid choices are "moderator", "subscriber" and "contributor")? Compiler has you covered. [1] If you write to master then read from a slave, there is a nontrivial chance that the result of your write won't be mirrored to the slave.
- SkyMarshal 14y ago
  Are you using a particular Scala framework, or building your site from scratch?
  - yummyfajitas 14y ago
    Play, with large components ripped out and rewritten. In particular, the monadic db access system is something we wrote in house.
    - rabbitfang 14y ago
      I've been very impressed by Scala. Play is also very productive. IntelliJ has an excellent (free) Scala plugin and I've read that support for Play is coming in the next version: http://blog.jetbrains.com/scala/2012/07/20/play-2-0-support/ http://blog.jetbrains.com/scala/2012/07/20/play-2-0-support/
bluesnowmonkey 14y ago
I was on a Rails project with some pages spending 200ms or more rendering views. To some extent that could have been got around by inlining partials or getting very clever with cache invalidation, but it would have come at a high cost in terms of complexity. Maybe a C++ framework could hit the performance/complexity sweet spot better. Then again, the site's down, so maybe not.
- klickverbot 14y ago
  The site is/was hosted on a Wordpress instance… ;)
- xiaoma 14y ago
  To be fair, though the error I'm seeing blames the database (エラー: データベースに接続できません).
- carsongross 14y ago
  I agree that one area where rails could improve is in the string serialization/ERB component (e.g. includes shouldn't materialize a string then write, but should concat to the current output for example) but ruby strings are pretty damned fast in my experience. I believe that's an implementation detail that could be addressed without going to C++.
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 ago
    Not representative for senior devs who have put any meaningful time into performance tweaking.
  - rurounijones 14y ago
    Totally meaningless number since we have no idea what the Rails app is doing.
    - rbanffy 14y ago

yummyfajitas 14y ago

I don't know why you are being downmodded. You are precisely on point - in Python (a slow language, similar to ruby), I'd often spend 50-500ms in the db (or 10-100ms in memcached) and 1-10ms in code. Optimize your sql, then optimize your memcached. That said, I've recently been working on a project building a webapp in Scala. The type safety Scala gives is amazing. Want to write to master then read from a slave in the same http request [1]? Won't compile. Want to build a page without a tracking beacon? Won't compile. Want to prevent invalid input to enum fields (e.g., a string for which the only valid choices are "moderator", "subscriber" and "contributor")? Compiler has you covered. [1] If you write to master then read from a slave, there is a nontrivial chance that the result of your write won't be mirrored to the slave.

SkyMarshal 14y ago
Are you using a particular Scala framework, or building your site from scratch?
- yummyfajitas 14y ago
  Play, with large components ripped out and rewritten. In particular, the monadic db access system is something we wrote in house.
  - rabbitfang 14y ago
    I've been very impressed by Scala. Play is also very productive. IntelliJ has an excellent (free) Scala plugin and I've read that support for Play is coming in the next version: http://blog.jetbrains.com/scala/2012/07/20/play-2-0-support/ http://blog.jetbrains.com/scala/2012/07/20/play-2-0-support/

bluesnowmonkey 14y ago

I was on a Rails project with some pages spending 200ms or more rendering views. To some extent that could have been got around by inlining partials or getting very clever with cache invalidation, but it would have come at a high cost in terms of complexity. Maybe a C++ framework could hit the performance/complexity sweet spot better. Then again, the site's down, so maybe not.

klickverbot 14y ago
The site is/was hosted on a Wordpress instance… ;)
xiaoma 14y ago
To be fair, though the error I'm seeing blames the database (エラー: データベースに接続できません).
carsongross 14y ago
I agree that one area where rails could improve is in the string serialization/ERB component (e.g. includes shouldn't materialize a string then write, but should concat to the current output for example) but ruby strings are pretty damned fast in my experience. I believe that's an implementation detail that could be addressed without going to C++.

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 ago
  Not representative for senior devs who have put any meaningful time into performance tweaking.
- rurounijones 14y ago
  Totally meaningless number since we have no idea what the Rails app is doing.
  - rbanffy 14y ago