Стоит ли вам использовать 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, и вас устраивает производительность и вероятность ошибок – думаю, это будет лучшее решение для Вас.

    Лежит тут. А тут — по-английски.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 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 узнать

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