Ruby On Rails работает медленно?

Я согласен со всеми. Вы должны профилировать. Нет смысла делать что-либо с вашим кодом, пока вы не узнаете, что конкретно вызывает медлительность. Пытаться решить проблему, не понимая ее причины, - все равно что чувствовать себя плохо и решиться на много операций, пока не почувствуете себя лучше. Сначала диагностируйте свою проблему. Это может быть что-то маленькое, например настройка сети, или одна плохая строка в вашем коде.

Несколько советов по профилированию:

Как профилировать ваше приложение Rails

Приложения Rails для тестирования производительности

В кузнице - профилирование приложений Rails

Как только вы найдете узкое место, вы можете решить, что делать.

Я рекомендую эти видео: Railslab Scaling Rails

Пересмотрено на основании результатов прибыли:

В ПОРЯДКЕ. Теперь, когда вы видите, что ваша проблема заключается в том, что вы выполняете какие-то вычисления с использованием запроса, основанного на циклическом просмотре результатов другого запроса активной записи, я бы посоветовал вам изучить создание настраиваемого оператора SQL, объединяющего ваши первоначальные критерии выбора и расчет цикла, чтобы получить то, что вам нужно. Вы определенно можете ускорить это, оптимизировав SQL.

Сколько из этих запросов 0-10 мс выполняется при доступе к просмотру? На какие части вашей модели данных ссылаются? Используете ли вы: include, чтобы сильно нагружать свои ассоциации?

Rails работает так же медленно, как и вы. С пониманием приходит скорость (обычно!)

Расширяя вышесказанное, есть ли у вас ассоциации has_many, в которых, в частности, ваша точка зрения ссылается на сторону "многие" без :include? Это приводит к тому, что ваш find(:all) в главной таблице будет выполняться с присоединением к деталям - если у вас есть большое количество подробных записей и вы обрабатываете их все по отдельности, это может обойтись дорого.

Что-то вроде этого:

Master.find(:all, :include => :details)

...может помочь. Тем не менее, все еще догадываюсь на основании скудной информации.

здесь

Хотя RnR имеет репутацию медленного, это звучит слишком экстремально. быть простой проблемой с языком.

Вы должны запустить профилировщик, чтобы точно определить, какие функции работают медленно и почему. Наиболее частая проблема, замедляющая работу веб-приложения, - это "проблема n + 1". То есть, когда у вас есть n элементов данных в вашей базе данных, приложение выполняет n отдельных запросов к базе данных вместо того, чтобы делать один запрос, который их получает. Но вы не сможете узнать, пока не запустите профилировщик. ruby-prof - это профилировщик, который я использовал.

Редактировать на основе результатов редактирования профиля:

Я твердо верю, что вы можете всегда удалить цикл запроса. Как говорит Майк Вудхаус, способ сделать это в Rails - указать отношения между вашими таблицами с помощью has_many или другую ассоциацию, а затем пусть rails автоматически сгенерируют соединение таблиц, это понятно, быстро и "по-Rails". Но если вы начинаете с чистого SQL или если ассоциации в этом случае не работают, вы можете просто сгенерировать соответствующие соединения самостоятельно. И если все остальное не удается, вы можете создать представление или денормализованную таблицу, в которой будут храниться результаты, которые ранее были найдены с помощью цикла. В самом деле, тот факт, что вам нужно перебирать сгенерированные запросы, может быть признаком того, что сама конструкция вашей таблицы имеет некоторые недостатки.

С учетом всего сказанного, если кеширование результатов вашего запроса работает для вас достаточно хорошо, оставайтесь с ним. При необходимости оптимизируйте.

Это ненормально. У вас есть какая-то логика, которая вас тормозит. Попробуйте закомментировать фрагменты кода, которые, по вашему мнению, занимают много времени, и посмотрите, поможет ли это. Если это так, вам нужно выяснить, как оптимизировать эту логику.

Если вы выполняете много вычислений в цикле, перебирающем очень большое количество объектов, то, конечно, это будет медленным.

Проблемы такого типа могут возникать на любом языке или в любом фреймворке. Хотя Ruby не так быстр, как другие языки, в большинстве случаев он достаточно быстр. Если вам нужно постоянно проводить вычисления с большими наборами данных, Ruby может не подойти вам. Подумайте о написании расширения Ruby C, которое будет обрабатывать ваш код, снижающий производительность. Но сначала попробуйте провести диагностику и рефакторинг.

Наконец, посетите RubyProf, чтобы узнать, поможет ли он найти узкое место.

Предыдущие два ответа полезны, особенно при использовании инструментов мониторинга производительности. Я использую New Relic RPM, и в прошлом это мне очень помогло.

Однако такие инструменты действительно лучше всего подходят, когда вы пытаетесь ускориться, скажем, с 3 секунд до менее 1 секунды.

2-4 минуты на визуализацию вида - это абсолютно ненормально при любых нормальных обстоятельствах.

Не могли бы вы показать нам некоторые из ваших журналов разработки, чтобы выяснить, где находятся узкие места?

Включаете ли вы время, необходимое браузеру для загрузки изображений, JavaScript или других файлов в это общее измерение?

Такое долгое время выполнения заставило бы меня заподозрить проблему с сетью - может быть, истекло время ожидания DNS-запроса на основном DNS-сервере?

Вы можете попробовать использовать JRuby или переключиться на Ruby 1.9.
И то, и другое должно привести к значительному увеличению производительности.
Проблема с JRuby в том, что драгоценные камни, использующие C, не будут компилироваться / работать. Существуют эквиваленты Java, которые устанавливаются приложением jruby "gem", но некоторые из них просто не работают.

По сути, у вас будет такая же проблема с Ruby 1.9. Немного изменился синтаксис, но основная проблема в том, что огромное количество драгоценных камней больше не работает. Тем не менее, люди в процессе обновления (проверьте прогресс на http://isitruby19.com/)

Почему бы не выполнить предварительную выборку всех данных и не заставить цикл for находить их локально в памяти вместо того, чтобы каждый раз запрашивать базу данных? Тысячи запросов для одного представления указывают на то, что с вашим дизайном что-то серьезно не так.

По этой теме есть несколько хороших снимков экрана http://railslab.newrelic.com/scaling-rails

Когда я привязал сервер к IP-адресу ящиков вместо 0.0.0.0, это ускорило для меня процесс.

Вы можете сначала профилировать код, прежде чем что-либо делать, однако запросы внутри циклов for - очень частая причина проблем с производительностью, и на первый взгляд это кажется вашей проблемой. В любом случае вы можете найти практического профилировщика здесь:

Как уже было сказано в других ответах, если обе модели связаны, вы должны стремиться загрузить ассоциации, что подразумевает указание Active Record для выполнения запросов на соединение:

#left outer join
ofkbs=Ofkb.includes(:operation).where(name: "banana")

Если вам не нужны ofkbs, а нужны только операции, вы можете выполнить внутреннее соединение

#inner join (discards the Ofkbs that do not have any operation)
operations=Operation.joins(:ofkb).where(ofkb:{name:"banana"})

Это решение выполняет только один запрос и позволяет впоследствии перебирать данные, которые уже были собраны из БД:

operations=ofkbs.map{|of| of.operations}.flatten

operations.each do |o|
  do_whatever_you_want_with_operation(o)
end

Если запросы очень сложные, используйте вместо них arel.