How can I improvement concurrence performance?

I found that if many users access to Rails at the same time, users will
wait for a long time. How can I set the concurrence user number in
Rails?

First, what is your set up?

What is the hardware you are running Rails on?

What else is running on the machine that might impact Rails?

What database are you using and how is it configured?

Are you running in development or production mode?

What timings does your log file tell you?

What do you mean by ‘a long time’. Hours, minutes, seconds?

What do you mean by ‘many users’. Thousands, hundreds, dozens?

Peter Hickman wrote:

First, what is your set up?

What is the hardware you are running Rails on?

It is running on 2G memory hardware with Fedora system.

What else is running on the machine that might impact Rails?

There isn't any processes running on this machine.

What database are you using and how is it configured?

I am using MySql.

Are you running in development or production mode?

Production mode.

What timings does your log file tell you?

What do you mean by 'a long time'. Hours, minutes, seconds?

Several minutes.

What do you mean by 'many users'. Thousands, hundreds, dozens?

5 to 10 users.

I just tried. If one user run a time-caused job on Rails server. Other
users have to wait until it finished.

Peter Hickman wrote:

First, what is your set up?

What is the hardware you are running Rails on?

It is running on 2G memory hardware with Fedora system.

2G is plenty of memory. I take it the disk and cpu are reasonable.

What else is running on the machine that might impact Rails?

There isn’t any processes running on this machine.

What database are you using and how is it configured?

I am using MySql.

Thats fine too.

Are you running in development or production mode?

Production mode.

What timings does your log file tell you?

In your log file there will be lines like

Completed in 3ms (View: 0, DB: 1) | 200 OK [http://…

after each request. This says that the request took 3ms and that 1ms of that was taken up by the database and the view rendered so fast that is wasn’t worth measuring. The format may be a little different depending on the version of rails you have but this information is a good place to start.

Find the log lines for the requests that are taking a long time and see how much of the time taken to serve a request is spent in the database. This then will give us somewhere to look.

What do you mean by ‘a long time’. Hours, minutes, seconds?

Several minutes.

That sounds really bad. At peak times our system handle 1000’s of concurrent requests and we rarely hit more than 8 seconds per request.

What do you mean by ‘many users’. Thousands, hundreds, dozens?

5 to 10 users.

That is not many users by any stretch of the imagination.

Lets see what the logs say.

Any chance you're running your Rails server as a single instance of Mongrel?
If so, using a Mongrel cluster will help very quickly and easily; and
longer term Phusion Passenger would be even better.

Peter Hickman wrote:

Your server’s processing power is the limit, there is no concurrency limit in Rails.

Best regards

Peter De Berdt

很多时候不是硬件不行,是代码写得有问题,5-10个人就挂了可以肯定是代码写得有问题,你不会是用webrick在跑吧?

Well if we read this correctly the system updated the sessions table and then tried to read a record from the sessions table. That should have come back instantly. It would make sense if one request opened the session table but did not complete. Then the next request for the session table would have to wait until the previous one completes or times out. In theory you can get a deadlock like this with a database. But rails does a pretty good job (out of the box) of not generating such errors.

Here’s something you might try. You are obviously using the database to store session data. If you can reproduce this problem in development try turning off storing sessions in the database. I think it is the ‘config.action_controller.session_store’ parameter in config/environment.rb

So

  1. Reproduce the problem in development

  2. Disable the storing of sessions in the database

  3. See if the problem persists

If the problem is reproducible in development and goes away when you stop storing sessions in the database then we will know at least where the problem lies.

Finding out what the problem is however is something else entirely :slight_smile:

True but given that the system has 2G of ram and is not really running anything else I would expect that the OPs system would be capable of handling 10 concurrent requests.

Besides there may be no concurrency limits in rails but if you were running it behind a web server (such as apache) then the limit might be imposed by the web server. But here it is looking more like a locking problem with the sessions table at this point.

Tim Teng wrote:

很多时候不是硬件不行,是代码写得有问题,5-10个人就挂了可以肯定是代码写得有问题,你不会是用webrick在跑吧?

我没有用webrick,就是用ruby script/server跑的

script/server will invoke webrick by default, and webrick of course is a single thread server. So test your app with other servers and check whether it still performs poor.

在 2010年6月28日 下午4:48,Zhao Yi lists@ruby-forum.com写道:

Tim Teng wrote:

script/server will invoke webrick by default, and webrick of course is a
single thread server. So test your app with other servers and check
whether
it still performs poor.

在 2010年6月28日 下午4:48,Zhao Yi <lists@ruby-forum.com>写道:

What do you mean by "other servers"? Do you know other ways to run the
server?

Thanks

Well, have a try ‘Passenger’ server, or ‘Thin’, ‘ngix’, etc

Try to use some third party web service to host your app, like Heroku
or Amazon Web Service EC2.

Cheers,
Lecky Lao

Try unicorn, it is dead easy;

sudo gem install unicorn

cd /yourRailsRoot

unicorn_rails

it will listen on 8080 by default.

hi

unciron is non faster then mongrel or thins or passenger

try analyze your applications, buy log, or tools such as new relic

after this

or refactor your app or go to another server (hetzner.de or rakspacecloud.com)

Best Regards, dieinzige

hi

unciron is non faster then mongrel or thins or passenger

try analyze your applications, buy log, or tools such as new relic

after this

or refactor your app or go to another server (hetzner.de or rakspacecloud.com)

Best Regards, dieinzige

For concurrency?

Passenger is tied to apache which inherently scales poorly.

Thin is nice, but unicorn still beats it on provisioning.

Benchmarks: http://cmelbye.github.com/2009/10/04/thin-vs-unicorn.html

Sure, one should make ensure a perfomant codebase. ruby-prof + KCachegrind ftw.

hi

unciron is non faster then mongrel or thins or passenger

try analyze your applications, buy log, or tools such as new relic

after this

or refactor your app or go to another server (hetzner.de or rakspacecloud.com)

Best Regards, dieinzige

For concurrency?

Passenger is tied to apache which inherently scales poorly.

Ah, I see Passenger also plays well with nginx now.