Ruby 1.9.1 на самом деле готов и быстрее для нового развертывания направляющих?
Я не собираюсь превращать это в направляющие по сравнению с Платформой X обсуждений, уже существуют многие из тех. После серьезного рассмотрения, какую платформу я собираюсь использовать для своего следующего развертывания, я решил, что очень трудно отказаться из направляющих воздействия поля REST, дает Вам для минимальной работы назад. Это - что-то, что требует немного большего количества работы в Django и рассмотрения, что я ставлю главным образом акцент на часть API приложения, направляющие имеет больше смысла на этот раз. При рассмотрении, насколько важный это для меня для записи приложения, которое содержит неоднородные клиенты (iPhone/андроид/планшеты), который может получить доступ (не только веб-браузеры), я должен смочь создать УСПОКОИТЕЛЬНЫЕ API с минимальным сопротивлением от любой платформы, которую я использую.
Мой вопрос, действительно ли направляющие готово обработать не, Твиттер измерил приложение, но что-то, что делает примерно 75 000 уникальных хитов в день? Ruby 1.9.1 действительно улучшают вещи? Существует много историй кошмара и одинаково многих историй успеха в зависимости от того, кого Вы спрашиваете. Joel Spolsky (один из основателей stackoverflow.com), полагает, что сам Ruby просто не готов к прайм-тайму, потому что это все еще значительно медленнее, чем другие интерпретируемые языки. Я не волнуюсь по поводу получения к размеру Твиттера (это - проблема, которую я хочу иметь однажды), но на том же маркере, у меня действительно есть сайт в среднем с 75 000 уникальных пользователей в день. Я задаюсь вопросом, с какими масштабирующимися проблемами я столкнусь, решая использовать Ruby 1.9.1 + последние направляющие (затраты ЦП + объем потребляемой памяти) как часть моего стека API по сравнению только с заниманием время, чтобы на самом деле сделать немного дополнительной работы в Django для создания УСПОКОИТЕЛЬНОГО API. Как Joel упоминает в своей статье, я не хочу покупать 100 серверов, когда я могу купить 10. Я хотел бы быть убежденным относительно того, почему направляющие теперь готовы отвечать моим требованиям.
5 ответов
Мы экспериментировали с версией 1.9 пару месяцев назад и были настолько впечатлены улучшением скорости, что почти сразу же начали процесс перехода на нее. Единственными библиотеками, которые не работали гладко, были Facebooker, который один из наших разработчиков смог исправить за пару дней (плагин теперь полностью совместим с 1.9), и VPim (библиотека iCalendar), которую мы смогли легко отключить с помощью гораздо более новый плагин RiCal.
Rails 2.3 полностью готов к работе на 1.9, и, по нашему опыту, время запросов сократилось более чем на 60%. Наши интеграционные тесты также получили такое же преимущество. У нас было 1200 тестов, на выполнение этого инструмента 300 секунд, которые теперь занимают всего 110 секунд без каких-либо других изменений, кроме перехода с Ruby 1.8.7 на Ruby 1.9.1. Это также означает, что мы смогли вдвое увеличить нагрузку, которую мог выдержать каждый из наших серверов.
Конечно, возможно, что вы используете гем, несовместимый с 1.9, но подавляющее большинство из них совместимы или могут быть сделаны совместимыми с небольшими изменениями.
Вы определенно не испытаете никаких проблем с 75 000 уникальных посетителей, и один сервер должен иметь возможность размещать приложение rails с как минимум в десять раз большим объемом трафика, если ваше приложение не написано очень плохо.
Сообщение Джоэла от ДВУХ ТЫСЯЧ И ШЕСТЬ. Это ЧЕТЫРЕ года назад. К счастью, все изменилось :) Ruby 1.9 готов к работе. Он совместим с Rails 2.3.5, а Rails 3 построен с учетом Ruby 1.9, поэтому он будет полностью с ним совместим.
«У меня вопрос, готов ли Rails обрабатывать не приложение размером с Twitter, а что-то, что делает примерно 75 000 уникальных обращений в день?»
Это это примерно то же самое, что спросить, считаете ли вы, что десять тысяч яиц помогут вам приготовить омлет не для города, а для семьи.
На самом деле вопрос не в том, готов ли Ruby 1.9 для Rails, а в том, готов ли Rails для Ruby 1.9. Из того, что я читал, похоже, что сам Rails (ActiveRecord и т. Д.) Хорошо работает на нем. У вас могут возникнуть проблемы с любыми рубиновыми драгоценными камнями, которые вы можете использовать, но не готовы к версии 1.9. Посетите http://isitruby19.com/ , чтобы узнать, прокомментировал ли кто-нибудь конкретные драгоценные камни, которые вы используете.
У меня вопрос: готов ли Rails обрабатывать не приложение размером с Twitter, а что-то, что делает примерно 75 000 уникальных обращений в день?
Что такое сервер вы используете? Что делает каждый запрос? Если вы используете одноядерный 128-мегабайтный слайс, то, вероятно, нет.
Ruby 1.9.1 действительно намного быстрее Ruby 1.8.X, а также требует меньше памяти. 1.9.2 не за горами, по сути, Rails 3 выполняет всю свою работу Dev на стволе 1.9.2.
На моем сервере я могу обрабатывать 80 тыс. Просмотров страниц в день, не беспокоясь и без какого-либо сложного кеширования. Если бы я построил интеллектуальное кеширование с помощью redis или memcached, я бы чувствовал себя комфортно, обслуживая 10-20 раз больше.
Вы можете создавать великолепно работающие веб-приложения с помощью Ruby и Rails (даже на REE 1.8.7). Вы можете создавать ужасно производительные веб-приложения, написанные на C ++.
Если вы разбираетесь в своей платформе и умеете оптимизировать, вы можете добиться отличной производительности.
Я бы, вероятно, держался подальше от Ruby 1.9.1 (если вы не считаете себя экспертом по Ruby) исключительно из-за того, что несколько библиотек не работают и подавляющее большинство приложений Rails не работают на нем. Я попробовал 1.9.1 несколько недель назад и смог заставить мое приложение работать, но для этого требовалось немного Ruby foo.
У вас не должно быть проблем с Ruby 1.9.1; Я просто хотел оспорить это:
75 000 уникальных пользователей в день
Это совершенно ничего не значит. Мы не знаем, сколько запросов в секунду соответствует вашему приложению. Если вы на самом деле имеете в виду 75 000 запросов в день, это тривиально - это меньше одного запроса в секунду. Любая среда, которая не может гарантировать вам, что до того, как вы достигнете ограничений, налагаемых базой данных или архитектурой вашего приложения, у нее будут большие проблемы, чем у платформы, на которой она работает: -)