0,0
рейтинг
21 сентября 2009 в 19:24

Разработка → Стоит ли вам использовать Google AppEngine?

Disclaimer: Эта статья не о том, «какой я умный и какой Гугл тупой». Эта статья о некоторых неочевидных проблемах и особенностях Google AppEngine (GAE), о которых было бы неплохо знать тем, кто хочет начать работать с «империей зла» :-)


Гугл сделал много отличных вещей – поиск, почта без спама… Гугл получает кучу наших приватных данных, но мы продолжаем пользоваться им, потому что оно так классно работает…
Некоторое время в IT-шных кругах поднялось достаточно шума об AppEngine, и я решил попробовать поработать с ним в моём новом проекте.

Я выбрал Python с гугловским framework-ом чтобы получить наилучшую совместимость и скорость. Начал я с тестов производительности, и результаты были… несколько разочаровывающими.
Тест Запросов в секунду
print 'Hello world' 260
1 чтение из Datastore, запись в Datastore 38
1 чтение из Datastore 60
10 чтений из Datastore, 1 запись 20
1 чтение из memcached, 1 запись в memcached 80
1 чтение из memcached 120
Обычное LAMP приложение, 6 SQL queries, http://3.14.by/ 240 на Atom 330 сервере
198 на shared hosting-е за 7$

Тест проводился на 20 параллельных запросах из двух разных серверов на том же континенте, цифры – средние за 7 секунд выполнения (позднее я долбил и по 10 минут). Некоторые могут сказать: «Эй! Результаты не такие уж плохие, мой [вставить урл тут] может обрабатывать всего 2 запроса в секунду, так что даже 20-38 уже неплохо ». Я бы ответил, что это простейшее приложение из пары строк, в настоящем приложении нужны будут 5-25 запросов к данным на страницу. Ну а классические LAMP Web-приложения, которые не показывают 100 запросов в секунду должны отправляться прямиком на свалку :crazy:

Кроме того, в тесте ‘10 чтений 1 запись’ отваливалась ошибка ‘Error: Server Error’ если использовалось более чем 10 параллельных запросов (внутренняя ошибка была ‘too much contention on these datastore entities. please try again’) – один из примеров неожиданных исключений на ровном месте.

Масштабируемость


Я ожидал, что в какой-то момент GAE распределит моё приложение больше чем на 1 сервере (по крайней мере так оно должно было быть в теории). Однако после 10 минут стресс-тестирования и расходования 10% дневной квоты на CPU скорость оставалась в точности такой же. Вероятно GAE не так быстро масштабирует приложения.

Исходники


достаточно простые:
from google.appengine.ext import db

class Counter(db.Model):
nick = db.StringProperty()
count = db.IntegerProperty()

res = Counter.gql(«WHERE nick = 'test3'»)
print 'Content-Type: text/html'
print ''
print '<html><body><h1>This is datastore performance test</h1>'
print '<h2>It reads a counter, and increment it''s value in datastore</h2>'
for v in res:
v.count = v.count + 1
print 'New counter value: ', v.count
# v.put()
print '</body></html>'


Приложение залито сюда: http://mafiazone-dev.appspot.com/.

В общем, действительно, все работает как и обещает Гугл – скорость не зависит от масштаба, медленно в маленьком масштабе, медленно и в большом :-) Даже один запрос к чему-то, что требует работы с Datastore или несколько Memcached – занимает кучу времени. Ну а если вам нужно сделать несколько запросов на страницу – ваши шансы увидеть exception’ы по таймауту резко повышается.

Обычные LAMP приложения (вроде моей домашней страницы) могут легко обслужить 10'000'000 хитов в день, а после более жесткой оптимизации – и 30'000'000 (в среднем 500 хитов в секунду при 8-10 пиковых часах). Много ли проектов требуют хотя-бы 10% от такой нагрузки? А что если 0.01% этих запросов отвалится из-за какого-нибудь исключения, которое вы не смогли или не успели обработать?

Общий список проблем, на мой взгляд


Если вы собираетесь работать с Google AppEngine, нужно иметь в виду следующее:
  • Любое обращение к Datastore может случайно отвалится с небольшим шансом. Google говорит, что шанс этого снизился с 0.4% до 0.1, но все равно остается. Datastore не проектировался как классическая база данных – ответ за ожидаемое время не гарантирован. И вы не сможете обработать все возможные исключения, т.к. все это требует процессорное время, а оно ограничено.
  • Memcached – это не тот memcached, к которому вы привыкли. Тут он достаточно медленный (сотни операций в секунду, вместо обычных десятков тысяч).
  • Вам придется подыскать место для хранения статики. Вы не можете раздавать большие файлы из GAE, ну и к тому же оно не очень быстро и достаточно дорого.
  • Есть отзывы что URLFetch недостаточно надежен. Думаю это исправят со временем :-)
  • Вы не можете выбрать Datacenter. Например – если вы живете в Европе, а GAE запустит ваше приложение в США, пользователи будут чувствовать что все несколько тормозит, и переместить в Европу приложение вы не сможете. Оно само перенесется, но когда – неизвестно. Моё так и не перенеслось после всех моих бенчмарков.
  • Google может обслужить неограниченное количество запросов, но каждый запрос – это минимум 100-200мс, и ваше приложение никогда не будет «летать». И не забываем, что вам нужно писать дополнительный код для обслуживания новых неожиданных exception-ов.
  • Google уверяет, что бесплатных лимитов хватит на несколько миллионов запросов. Однако я на своих простейших примерах потратил 0.65 CPU часа за 15к запросов, т.е. всего 150к хитов в день. Соответственно, и платный сервис несколько дороже, чем можно представить. Вероятно, эти миллионы достижимы только на 100% статичных страничках.
  • Google может много говорить о том, что это Open-source решения, но это не так. Ключевые технологии закрытые, а тестовый сервер SDK похоже намеренно сделан супер-тормозным (всего 2 запроса в секунду на Core2Duo 3.6Ghz). Так что никакой конкуренции, или смиритесь с сервисом, или переписывайте все с 0.


Чтобы я хотел видеть в GAE по другому:


  • Намного более детерминированное поведение. Если я выхожу за лимиты – лучше я получу предупреждение по почте, чем мне кинет exception, который я потенциально не успею обработать.
  • Намного более высокую производительность Datastore & Memcached. Вероятно memcached тут общий, и завален запросами, потому и медленно…
  • Выбор датацентра
  • Cluster-aware API. Было бы неплохо иметь небольшой кусочек очень быстрой памяти на локальном сервере, с event-ами «initialize storage» и «release storage».


Еще немного мыслей


Некоторое время назад я работал с очень классной технологией – все было избыточно и супер-надежно, «облачное», удобные API, но с ним отрисовка странички форума занимала 4 секунды на 4-х процессорном сервере. Это было полное дерьмо. Если технология тормозит или пользователю с ней не комфортно – эта технология полное дерьмо. Использовать технологию только потому что «это круто» как-то глупо.

Где Google App Engine можно использовать и где не стоит


GAE превосходно подходит для простых read-only (т.е. без сложной логики БД, небольшие объемы данных) приложений БЕЗ пиковых нагрузок (т.е. может не успеть на лету отмасштабироваться). Ваша домашняя страничка будет просто идеально сидеть на GAE с нулевыми расходами на поддержку.

Не подойдет это для сложных приложений, где много логики, много данных на экране, и есть время от времени shashdot/хабра-эффекты. Google AppEngine может не успеть обработать неожиданный пик в несколько сотен запросов в секунду.

Заключение


Значит ли это все что прогеры и архитекторы Goggle-а тупы? :crazy: Совсем нет, на самом деле при таких условиях трудно было бы добиться лучшего. Действительно трудно достигнуть неограниченной масштабируемости для приложений, которые не заточены специально под кластер. В результате, большинство приложений не сможет как следует работать на GAE.

Но если ваше приложение хорошо уживается с особенностями и ограничениями GAE, и вас устраивает производительность и вероятность ошибок – думаю, это будет лучшее решение для Вас.

Лежит тут. А тут — по-английски.
Михаил Сваричевский @BarsMonster
карма
965,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (74)

  • +2
    Пробовал на java тестить? всё так же?)
    • +1
      Вот есть приложение на java
      Объём данных по больше и скорость работы нормальная.
      Там приводится тест Datastore и memcached.
    • 0
      Корень проблемы — в производительности системы хранения данных. От языка это сильно не зависит.
      А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
      • 0
        От языка вообще не зависит хранилище. Основной платформы нет, есть 2 среды исполнения. Все «оборачивается» в protobuf и проходит через rpc, читайте ниже.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Готово, картинка на главной ;-) :-)
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        С вас графики ;-)
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Очень интересно. А вы пробовали сранивать производительность Google App Engine с AWS?
    • +3
      GAE и AWS не одно и тоже.
      AWS «продвинутый» хостинг.
      GAE же дает среду, так же как если бы вы писали приложения под Win API.
      Концептуально архитекторы GAE заглянули дальше чем AWS.
  • 0
    Да, теперь хотелось бы услышать результаты подобной проверки по амазонскому сервису.
  • +1
    помоему GAE рано еще так тестить:
    1) клиентов у GAE на порядок меньче чем у амазона
    2) амазон все таки предоставляет виртуальные машины, а не среду выполнения
  • +1
    Подтверждаю. GAE, — даже без обращений к базам, без авторизаций, сессий и прочего, — просто по HTTP отвечает не всегда; и часто — с очень большими задержками. В AJAX-приложениях надо обязательно учитывать таймауты и обязательно выдавать хорошие сообщения при протормозах (т.е. не просто отваливаться, а писать «подождите», «повторите»,...), иначе сервис выглядит как полное глюкалово. Такой проблемы с тормозами, как в GAE, я не видел нигде.
    • +1
      На форум им писать не пробывали? Они обычно отвечают в течении всего их рабочего дня, постоянно мониторят. Надо описать проблемму и сказать app-id. У вас включена оплата на приложении?
  • +1
    Есть подозрения, что как и у многих хостинг компаний в европе (и уже пошла практика у нас), вначале (бесплатно) дают мелкие возможности и ресурсы на опробирование, а уж надо серьезно позвольте переходить на тариф покрупнее и платить поболее…

    «Ну а классические LAMP Web-приложения, которые не показывают 100 запросов в секунду должны отправляться прямиком на свалку :crazy:»
    Не скромный вопрос, но что такое классические LAMP веб-приложения?
    • –1
      Вероятно имеется ввиду аббревиатура характеризующая обычное окружение — LAMP = Linux Apache MySQL PHP
      • 0
        Наверное, автор имел в виду, что такое классическое веб-приложение под LAMP?
        • 0
          Именно так.
          • +2
            Что — так? Так что такое классическое веб-приложение, которое должно легко держать 10 млн хитов на LAMP? Мне тоже интересно.
          • 0
            Я хотел сказать, автор комментария имел в виду. Не автор поста.
  • +4
    Ну вообще не забывайте, что проект в стадии pre-release, и не было пока сообщений, что он вышел из этого статуса. Во вторых — 22 сентября они «меняют» хранилище на улучшенное, так что посмотрим на его работу.

    Далее, мемкеш тормозной, не потому что он забит, а потому что все обращения к любым сервисам проходят через rpc, читайте доки (сегодня средняя скорость чтения ~10мс на ключ. Все операции последовательны). Так же это относится к локальному sdk, текущие реализации (а гугл пока свой rpc-сервер не собираеся открывать) не позволяют сделать его быстрым. Хотите скорости на локали, отправьте им быструю версию, они примут.

    По поводу масштабируемости — было неоднократно замечено, что быстро маштабировать gae начинает при включенной оплате. Что логично. У меня нагрузка на приложении легко возрастала в 10-15 раз, все было ок.

    Ну и в завершении, AppEngine надо уметь готовить. Есть jaiku.com, google modertor (который висит на сайте белого дома, если не ошибаюсь) и т.п высоконагруженные приложения. Работают они хорошо, без видимых ошибок.
    • 0
      1. Будем верить и недеяться
      2. На мой взгляд 10мс на memcached — это никогда не будет приемлимо. И наличие rpc не значит, что нельзя было иметь 1мс.
      3.
      4. С этим не поспоришь. Подходящие приложения написать хорошо можно.
      • 0
        Ну считайте что это не memcached, а ничего не гарантируеще хранилилище типа key-value… Наличие прослойки в виде rpc и говорит о том, что хотелось бы, но 5мс предел, насколько я знаю… плюс само обращение. А на кой вам больше если не секрет? 1000 запросов в мемкеш на один веб-запрос — это неграмотно спроектированное приложение. А так из разных запущенных инстансов AppEngine, мемкеш дергается фактически параллельно. 8 мс — это на последовательные запросы из одного приложения. Но из-за локов в транзакционных записях могут быть проблеммы со скоростью, тут архитектурой заниматься надо.
        • 0
          Любые пределы — в голове. Можно и 0.5мс иметь на запрос, можно и 0.05. :-)
          1000 запросов не нужно, а вот 20 — это похоже на правду.

          • +2
            Пределы в архитектуре их rpc, насколько я понял из разговоров с разработчиками. Они бы и сами рады наверное, да никак.
            А даже 20 это имхо многовато. В среднем 10, т.е 80-100мс, что допустимо для любого веб-приложения.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Ну кратко есть тут. Чтиво ровно на 5 мин.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Меня в нем привлекает архитектура гугли и де-юро масштабируемость. Это в краце. Полностью меня в нем привлекает все то, что написанно по ссылке, которую дал выше. + там не описанны TaskQueues и XMPP. Полностью все есть в англ. версии.
  • +10
    Если в русском тексте встречаешь фразу «полное дерьмо» сразу же понятно, что это перевод ;)
    • +3
      Вы будете смеяться, но таки да :-)
      Сначала я написал английскую версию :-D
  • 0
    попробуйте MS Azure
    тормозов никаких не замечено
    всё просто «летает».
    • +1
      парни, за что минусуем? Пробовали, и тормозит? Тогда расскажите пожалуйста!
    • 0
      кстати. сама МС выпустила кучи инструкций о том, как ваше любимое (или не любимое) приложение на РНР запускать на Azure с минимумом модификаций.
      для поклонников питона есть IronPython, который тоже отлично работает на Azure
  • +5
    Включали ли Вы биллинг?
    Сам не делал сравнений, но точно читал статью с подобными сравнениями, где автор с радостью обнаружил, что и лимиты на сервисы и скорость сильно поднимаются при включённом биллинге(при этом это не значит, что нужно выйти за пределы бесплатных параметров)
  • 0
    Насчет исключения про слишком много запросов к одной сущности: в документации про это явно написано, так что исключение не такое уж и неожиданное.
  • +2
    К слову, была же хорошая статья, как гаджет для Евровидения делали на GAE. И там хорошо описано, для чего GAE подходит, а для чего — нет.
    Но четко ясно — GAE не универсальное средство и подходит далеко не для всего.
    Нужно знать, что можно делать, а что нет. Нужно знать множество мелочей, которые иногда сильно влияют на производительность.
  • +3
    По поводу URLFetch это правда.
    Я тут баловался с GWT+GAE вот что получилось eventstimeline.appspot.com/
    • 0
      В догонку к urlfetch — сделал для себя habrahabr-lite для того чтобы смотреть на мобиле. toster1976.appspot.com (не реклама). Если бы сейчас переделывал, то сделал бы выкачивание url по крону и кэширование. Когда делал часть запросов не отрабатывала и глючила авторизация, по этому забил на все это.
  • 0
    Писал на основе GAE Java Web-приложение. Не дождался поддержки миграций для разрабатываемых приложений с версии на версию, а без них трудно соблюсти полный цикл разработки и поддержки продукта. Ушёл с сервиса.
  • 0
    статику с него отдавать — как раз те 10М запросов получаться. Только статику лучше с code.google.com отдавать :)
  • 0
    А я по совету webo.in/articles/all/2009/08-google-cdn-in-minutes/ разместил статику (600 кб) на google appengine.
    Движок сайта (самописный на django) и база mysql на firstvds под apache.
    Время загрузки по тестам на webo.in сократилось в 1,8 раза
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Google использует стратегию «ковровой бомбардировки» даже если 2 сервиса из 20 будут успешными, то при таком объеме он итак забирает значимую долю рынка.
    Эффективность хостинга мощностей наиболее высока на больших ресурсах и за адекватные деньги, например cdn-хостинг Akamai.
    Минус — отсутствие QoS. Работали ли Вы с локальной базой данных где каждый 1000 запрос отваливался, а каждый 10000?
  • +5
    У нас работает интернет-магазин на GAE. В среднем 500-600 хитов в день. Использует 0,3-0,4 часа процессорного времени в сутки из 6,5 бесплатных.
    axiomashop.appspot.com/
    • +3
      Ого! Может статью напишете о его разработке?
      • +1
        Обязательно. Планировал в ближайшее время написать о подводных камнях с которыми столкнулся при разработке, но к сожалению пока нет на это времени. Но раз тема поднялась не мог не упомянуть о нашем реально существующем и работающем проекте на GAE.
      • 0
        По просьбам трудящихся небольшая заметка в личном блоге.
        Появится карма — перенесу в блог GAE.
        Будут вопросы, напишу более подробно.
    • 0
      Магазин писался с «нуля» или в GAE были портированы наработки?
      Если использовались готовые наработки, то какие «грабли» были при портировании в GAE?
      • 0
        Писался с нуля.
        На текущий момент есть проблемы с загрузкой/выгрузкой большого количества данных. На данный момент использую CSV для загрузки обновлений (цены, товары, наличие). При большом объеме данных превышается тайм-аут 30 сек на выполнение. Кроме этого в GAE ограничение на 30 запросов на запись (put). Соответственно обновлять больше 30 товаров за один проход не получается. Этот момент можно оптимизировать и обновлять данные не поштучно, а сразу пачками т.к. в GAE запись в хранилище может производится целыми массивами.
        Выгрузка данных для Яндекс.Маркета занимает почти 10 секунд (200 товаров), 90% времени это генерация HTML.

        Также не решил еще проблему с фильтрами и сортировками товаров по характеристикам. Т.к. БД не реляционная, привязать характеристики к товарам тяжело. Как вариант делать для каждого типа товара вручную в коде свой фиксированный набор характеристик, это возможно пока типов товаров не больше десятка.
        • 0
          bulk data uploader / downloader пробовали использовать?
          code.google.com/appengine/docs/python/tools/uploadingdata.html
          • +1
            Это подходит только для разовой выгрузки/загрузки.
            Данные на сайт загружаются ежедневно, данные после загрузки должны обрабатываться и вносить изменения в существующие данные (проверять изменение цены/наличия и добавлять новый товар).
            Кроме этого загружаться все должно само по расписанию из определенного места.

            Тоже самое касается выгрузки. Яндекс сам раз в час забирает свежий прайс, он не знает что такое коммандная строка (только через нее работает массовая загрузка/выгрузка) и ему нужно отдавать данные в XML и раздельно отрабатывать его GET и HEAD запросы.
        • 0
          TaskQueue вам в помощь. Я думаю к следующему релизу он выйдет из labs, ну а пока можно пользоваться и так.
          • +1
            Точнее Cron.
            TaskQueue немного другие задачи решает. А кроме этого лимиты в 30 сек. и на get()/put() все равно остаются.
            • 0
              TaskQueue, генерация контента частями, кеширование. Это про Я.Маркет.
              А про выгрузку-загрузку — ну я бы все же на bulk_uploader посмотрел. Готовое мнгопоточное решение запихивания данных в базу.
              Сделайте отдельную «промежуточную таблицу», куда вы будете лоадером данные заливать, а потом уже через веб-интерфейс эти данные обрабатывать, «подтверждать» и чего там вам нужно. Или, опять же, Cron, да.
              Вполне себе можно по расписанию из определенного места.

              В решении таких задач в GAE приходится крутиться и придумывать всякие хитрые штуки :) Ну и главное — параллелить и разбивать задачу на кучу мелких подзадач, чтобы не вылезти за лимиты.
              • 0
                Скоро еще MapReduce обещают. Вернее эфективное хранилище для reduce(), map() то по сути готов в тасках.
            • 0
              Не, крон то ясно для подгоовки периодики. Я для обновления имел ввиду. Ну и + батчи. Я предпочитаю у себя если индексов много и обьект большой, не более 10 в батче и распределять по таскам, типа лучше меньше и часто, и в батчах.
    • +1
      И последний вопрос. После разработки на GAE, променяли бы вы его на обычный платный хостинг?
      • 0
        Преимуществ у GAE на данный момент все-таки больше чем недостатков. На платном хостинге на мой взгляд имеет смысл делать проект который нельзя сделать на GAE.
        Самое главное для меня — это отсутствие головной боли с покупкой/настройкой/поддержкой серверов.
        Естественно речь о проектах требующих не меньше VPS.
        • 0
          Еще преимущество — надежность.
          Все-таки кластер из кучи серверов в нескольких ДЦ — это очень серьезно. Я считаю, что это надежно.
          VPS/дедик/колок может упасть — и это жопа :) Мало ли что с сервером могут сделать. Если конкуренты злые, то могут и украсть, и изъять…
          Ну или надо несколько серверов для обеспечения надежности — а это уже дорого.

          К слову, это характеристика клауда, а не только GAE.
    • +1
      Интересно, что у вас favicon дефолтный :)
  • 0
    Спасибо за интересную статью! Будет интересно почитать о тестировании Amazon Web Services в вашем исполнении :)
  • 0
    По поводу своего домена: покупаете на стороне домен ВашДомен, регистрируете и устанавливаете для него Гугл Почту, после этого прямо в почте можно добавить ваше приложение из GAE и присвоить ему www.ВашДомен. А для просто www.ВашДомен делаете редирект 301 на ВашДомен.
    Паривно конечно, но работает, если не охота сидеть на доменах *.appspot.com

    У меня чистая статика тут www.roadslot.com. Действительно удобно, если уже знаком с технологией.
  • 0
    Кстати, уже существуют и первые социальные сети UGC-типа, вполне успешно работающие на GAE.

    Реальный работающий пример: enetri.com, украинский аналог Хабра.
    Работает уже почти полгода, полет — нормальный, впечатления — положительные :)
  • 0
    Ого классная статья, еще бы про windows azure узнать

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.