Rails 3 performance [closed]

开发者_Go百科 It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I want to implement a web app like stock exchange where the values will change all the time (let's say once in a sec). I probably will do it using ajax comet.

Because of the nature of the app the users will be somewhat concurrent and I'm worring a litle bit about perfomance.

These are my thoughts:

I want to make it in Rails 3, but I'm worring about performance. Any good hosting companies to choose? should I use cloud? Rails 3 in ruby 1.9.2 will be faster than php (including db queries)?

I could make it in Play framework, which probably has not perfomance issues, but i'd like to make changes on the fly (if needed) in production, without re-deploy etc. Also I like rails a bit more.

I could make it in PHP but it' will take more time, more code

I don't have experiance in real production systems with Rails or Play so i don't know much about performance. Can any one help?

---

It might be worth thinking about using Faye, which is a framework for "simple pub/sub messaging for the web".

Faye has both Ruby and Node.js server components, as well as clients for Ruby, and crucially for your use case web-browsers (through javascript, obviously).

There are two approaches to this:

• Embed the Faye server inside your rails app. Nice and simple, fewer moving parts, less processes to manage, but probably not as scalable as:
• Run a separate Faye server in Node.js, and push messages to it from your rails app using the Ruby Faye client. Slightly more complicated. More moving parts. More processess to manage. But, crucially, all the heavy lifting of connections is done in Node.js, which is something its very good at.

If it were me, I'd start with option 1 to keep things simple, and upgrade to option 2 if and only if I could prove it was necessary.

There's a great introduction to using Faye from Ruby in Railscast 260.

---

It's really hard to be specific without knowing the specific case your building for, but for things that might be accessed concurrently by lots of clients, and that might not necessarily need access to the full-application environment of a Rails app, you might consider using a combination of something like node.js + Rails. If I'm understanding you correctly, once a page is opened it will hold a connection to the server via comet/websocket and elements on that page will frequently update.

You can have your Rails app notify a node.js app (via Redis or some such) about relevant changes and then have that broadcast those changes to any connected clients... keeping the role your node.js server is playing to a lightweight minimum. When somebody comes online, the page loads, a comet stream (call it what you like... a socket) is opened to the really lightweight node.js and whatever content is available is pushed down to the browser, followed by the broadcast updates that it receives as events transpire inside the Rails app. It seems silly to have all these clients with persistent connections into a Rails environment when there are better tools for such things.

I'm not saying don't use Rails, I'm just suggesting that you think of your application in terms of services and run those services with the relevant tools ;)

Here's a little broadcast example of a chat application using node.js, just to give you an idea:

http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/

node.js is only a suggestion... you can go away and research alternatives, or sure, if you want to keep things "simple", just manage that from Rails, but it will be heavier, and that seems to be of concern to you :)