Comments 23
Оптимизаторов нет.
Но можно начать использовать passenger, REE или ruby1.9, nginx, настроить кеширование — это все быстро и эффективно.
А потом уже пусть девелоперы оптимизируют код
Но можно начать использовать passenger, REE или ruby1.9, nginx, настроить кеширование — это все быстро и эффективно.
А потом уже пусть девелоперы оптимизируют код
текущий техрук говорил о новом ruby 1.9, но якобы фреймворк рельсов к нему пока нет. Однако мне, как техническому специалисту (уж простите за пафос) как-то не очень по душе взглды, типа: «вот сейчас выйдет новая версия языка и она будет панацеей». За ключевые слова passenger и REE спасибо, погуглю. Под кешем я имел введу кеш исполняемых файлов соответственно, а не контента. В данном вопросе мемкеш мне не интересен =) тут 16 ядер, 16 гигов оперы и 300-400к хитов в сутки. Еще раз спасибо.
Узкое место при любом раскладе — бд. У руби невероятно мощная система кеширования и, если свиперы не были настроены для 300к хитов в сутки — кривые руки программистов. Если они использовали erb, а не erubis — кривые руки программистов. Если не используется memcached — кривые руки программистов. В остальном — что htop показывает конкретно? если 1 процесс рельсов занимает больше 200м — это уже серьёзное приложение. Существуют, например, проблемы со сборщиком мусора и некоторыми плагинами/гемами. Приложение банально течёт. То есть, вы смотрите, каков размер одного рельсопроцесса при старте, прибавляете к нему 50-100м и перезапускаете процесс по достижении им этого размера, например, годом. Очень много советов можно дать, а ситуация не ясна.
на обоих серверах порядка 10-15 ruby процессов, которые жрут по 20-30% процессорного времени (не могу сказать точнее, не знаю как вычесляет htop) и по 100-150 памяти. Один из серверов загружен на 100%, второй процентов на 80.
Между серверами кластер на уровне фс для статики (даже не спрашивайте…)
Между серверами кластер на уровне фс для статики (даже не спрашивайте…)
Значит проблема в кешировании. Настраивайте свипинг, ставьте erubis и будет счастье. Что же касается ruby 1.9 — в рельсах 2.3.4 есть баг, несовместимый с ними. Более ранние версии использоват не рекомендуется. Значит, надо ждать 2.3.4.1 или 2.3.5. Но, если сайт не англоязычный — будут проблемы с кодировками, что решается буквально парой патчей и явным проставление кодировки файлов. В целом, я бы рекомендовал переходить на 1.9. Сам уже вовсю использую.
А как вы думаете, лучше использовать свипперы или cache-money?
Касательно оценки производительности, вот интересный скринкаст:
blog.envylabs.com/2009/11/scaling-rails-part-2/
Касательно оценки производительности, вот интересный скринкаст:
blog.envylabs.com/2009/11/scaling-rails-part-2/
А вообще интересно где обо всём этом можно почитать основательно…
Например, RSS-ленты, скринкасты, статьи…
Буду очень признателен если подскажете!
Например, RSS-ленты, скринкасты, статьи…
Буду очень признателен если подскажете!
Свипперы и cache-money — разные вещи. Свиперы делают кеш на уровне отображения, а cache-money — на уровне запросов к бд. Cache-money я никогда не использовал.
Очень много важной информации можно найти на guides.rubyonrails.org/. Там вопросы кеширования затрагиваются неплохо. Ну и гуглом пользуйтесь, естественно.
Очень много важной информации можно найти на guides.rubyonrails.org/. Там вопросы кеширования затрагиваются неплохо. Ну и гуглом пользуйтесь, естественно.
Кстати, а по поводу пассажира — в данном случае лучше будет сделать кластера thin и нгинксом их. Заодно try_files таскать кеш прямо нгинксом.
1.9.1 действительно быстрее 1.8.7 более чем в два раза.
руби 1.9 уже работает и работает очень быстро
рельсы под него уже заточены
рельсы под него уже заточены
Не подумайте, что это претензия к вам, но на офф сайте ни слова про 1.9, на русскоязычном есть предложение: «Ruby 1.9 лучше пока не использовать». dymdym я был бы вам очень благодарен, если бы вы дали свою экспертную оценку по использованию RnR на Ruby 1.9 и масштабах переписывания ПО для этой связки.
с руби1.9 проблемы будут только с кодировкой(точно будут если проект русский) — решается добавлением одной строки в проблемные файлы. за сутки двое вполне справитесь.
а вот если рельсы дуже старые то тогда переносить надо на новые
Моя экспертная оценка :) — заставите работать passenger+ruby1.9 — будет в разы быстрее
какой эксперт такая и оценка :)
а вот если рельсы дуже старые то тогда переносить надо на новые
Моя экспертная оценка :) — заставите работать passenger+ruby1.9 — будет в разы быстрее
какой эксперт такая и оценка :)
С кривыми руками можно тормознуть все, что угодно. Попробуйте для начала поставить и грубо настроить кеш-прокси.
вот сейчас всё рекламируют New Relic, как средство аналитики приложения на рельсах, я сам его в живую не видел, но по обзорам выглядит впечатляюще, возможно поможет Вам найти узкие места
ребят, я не против чтобы вы минусовали топик. Хоть в самый низ его опустите, честно. Мне нужна истина, кармы мне не жалко =)
Вообще странно почему проблемами с производительностью приложения не занимаются люди, которые его же и писали. У меня не было проектов с посещаемостью 30 тысяч уников в день и с таким мощным железом я еще не работал, наверное поэтому для меня это странно.
Может Вам обратиться за помощью к таким людям как Макс Лапшин (levgem.livejournal.com), который недавно как раз ушел с хабра? Вы знаете о существовании группы ror2ru groups.google.com/group/ror2ru/topics?
Еще мне нравится как Вы сокращенно называете фреймворк. =))
Может Вам обратиться за помощью к таким людям как Макс Лапшин (levgem.livejournal.com), который недавно как раз ушел с хабра? Вы знаете о существовании группы ror2ru groups.google.com/group/ror2ru/topics?
Еще мне нравится как Вы сокращенно называете фреймворк. =))
возможно вы правы, спасибо.
Я, возможно, ошибаюсь, называя Ruby On Rails «RnR», но в моих кругах его называют именно так. Я не буду говорить, что в моих кругах его называют верно, в RnR я далёк от прикладной и программной части. Однако Rock-anf-Roll тоже сокращенно называют RNR, или
Rock-n-Roll. Смысла это не меняет =)
p.s. производительностью приложения не занимаются люди, которые его же написали потому, что они считают, что каждые 200к хитов посещаемости должны обслуживать 2 ксеона и 6 гигов оперы. Собственно именно по этому существует моя профессия — аналитика.
p.s. В MechCommander старых версий, кнопка старта миссии тоже называлась Rock-n-Roll =)
Я, возможно, ошибаюсь, называя Ruby On Rails «RnR», но в моих кругах его называют именно так. Я не буду говорить, что в моих кругах его называют верно, в RnR я далёк от прикладной и программной части. Однако Rock-anf-Roll тоже сокращенно называют RNR, или
Rock-n-Roll. Смысла это не меняет =)
p.s. производительностью приложения не занимаются люди, которые его же написали потому, что они считают, что каждые 200к хитов посещаемости должны обслуживать 2 ксеона и 6 гигов оперы. Собственно именно по этому существует моя профессия — аналитика.
p.s. В MechCommander старых версий, кнопка старта миссии тоже называлась Rock-n-Roll =)
Ну для начала надо смотреть в сторону другого application сервера и версии ruby.
github.com/kpumuk/easy-prof/ – профайлер для рельсов простенький.
newrelic.com/ – аналитика и мониторинг производительности рельсов.
А вообще да, рельсы могут столько отъесть.
github.com/kpumuk/easy-prof/ – профайлер для рельсов простенький.
newrelic.com/ – аналитика и мониторинг производительности рельсов.
А вообще да, рельсы могут столько отъесть.
Как по мне — так для меня не ясен Ваш вопрос. Верней, что бы на него ответить нужно знать, что это за приложение, его архитектуру. Вполне возможно что действительно производятся какие-то обработки данных и вычисления, которые грузят сервера, а также может быть что это простая cms которая просто написана далекими от рельсов людьми.
Имхо Вы правы — 1.9 не будет серебренной пулей, которая решит все проблемы. Если есть ошибки в архитектуре — более быстрый интерпретатор не вылечит.
Имхо Вы правы — 1.9 не будет серебренной пулей, которая решит все проблемы. Если есть ошибки в архитектуре — более быстрый интерпретатор не вылечит.
Sign up to leave a comment.
Пост — вопрос