Google App Engine *

В прошлой моей статье про скорость работы с данными GAE был встроен графический счетчик показов. Каждый мог видеть значение счетчика и израсходованные ресурсы CPU. Как я уже говорил, счетчик был довольно «тяжелым»: создаваемая им нагрузка эквивалентна отображению на странице 1000 записей из базы данных без использования кеширования.

Эксперимент со счетчиком оказался весьма полезным, а его результаты несколько неожиданными для меня (отличными от запросов с одного IP-адреса). Хочу поделиться результатами эксперимента и поставить новый эксперимент, уже с учетом пройденных ошибок. Кстати, исходный код нового графического счетчика доступен для всех и приведен в статье.

Столкнувшись с вопросом выбора базы данных для проекта, провел небольшое исследование Google App Engine на предмет скорости работы с данными. Результаты исследования оформил в виде таблиц.

Эти подсчеты сэкономят время тем, кто ищет площадку для размещения своего проекта, но не уверен подходит ли ему Google App Engine. Кроме того эти таблицы можно использовать как некую «шпаргалку», чтобы примерно ориентироваться сколько времени займет обработка запроса и как его лучше оптимизировать.

В то время, как я закладываю основу новой клиентской библиотеки для работы с Datastore с поддержкой асинхронных запросов, я добавил кое-какой низкоуровневый функционал, который Вы можете использовать уже сегодня. Единственный API с документированной поддержкой асинхронных запросов – это urlfetch. И этот функционал может оказаться довольно полезным.

Как вы уже знаете из предыдущей статьи, в App Engine есть множество способов хранения информации. Но многие из них весьма специфичны, и для повсеместного пользования подходят всего три: память инстанса, memcache и datastore.

Под катом вас ждёт изложение в цифрах и картинках, краткие рекомендации по кэшированию и исходные коды простого cacher'a и приложения для тестов.

О выходе 1.4.2 версии SDK уже писали на Хабре, меня же интересуют именно изменения в второй версии XMPP API



Так же, напоминаю про топик о первой версии XMPP API.

Сначала расскажу об изменениях в SDKs, а потом о том, что разработчики нам обещают в ближайшие 6 месяцев.

Итак,
— Capabilities API более не экспериментальная фича. Доступна как в Java, так и в Python SDK.
— XMPP v2. Теперь с поддержкой presence и subscriptions.
— Добавлена возможность программного удаления заданий из TaskQueue.
— Увеличена максимальная скорость пополнения очереди до 100/сек.
— В URL Fetch добавлен метод позволяющий проверить сертификат, при обращении к хосту по https.
— Улучшен Memcache API.

Задумалось мне сделать в игрушке, о которой я раньше писал, простую вещь — подсчитывать, какое место человек занимает в общем рейтинге:

Как я писал, для различных статистик игра использует AppEngine. Подкатом я расскажу об оптимизациях, которые пришлось применить для этой простой фичи.

Bulkloader — это интерфейс в Google App Engine для загрузки данных из/в хранилище на серверах Google. Bulkloader удобно использовать для бэкапа/восстановления/миграции данных приложения, однако документации и примеров использования катастрофически мало, а на сложном приложении придётся натыкаться на разнообразные проблемы и баги. Сам я довольно долго раскапывал разные источники информации, копался в исходном коде SDK, читал баги, писал свои воркараунды; и теперь готов представить некоторые плоды в виде подробной статьи.

Статья очень большая, имейте в виду.

Одной из проблем, с которой сталкиваются GAE-разработчики, привыкшие работать с реляционными СУБД и ORM, являются ссылки и отношения в App Engine. В данном руководстве рассматриваются два вопроса: во-первых, что вообще представляют из себя отношения в СУБД?; во-вторых, как ими пользоватья в GAE?

Blobstore api — недавнее пополнение платформы App Engine, позволяет загружать и раздавать большие файлы, в настоящий момент до 2Gb (в оригинале — 50Mb, прим. переводчика). Это также один из наиболее сложных в использовании API. Небольшая серия заметок покажет как реализовать «dropbox» сервис на базе App Engine используя Blobstore API. Для начала мы рассмотрим основы, необходимые для загрузки файлов, сохранении информации о них в datastore и дальнейшей отдачи их пользователям для скачивания.

По своей работе я часто имею дело с почтой, размещенной у разных хостинг-компаний. Несмотря на то, что за хостинг платятся вполне приличные деньги, качество услуг в разы проигрывает «бесплатным» почтовым серверам. Мало того, что под почту дают мало места, так и доступность её чаще всего хромает. Но когда мне довелось с почтой, размещенной у Хостинг-центра РБК, количество проблем достигло такого уровня, что было принято решение перейти на какой-либо альтернативный сервис.

Выбор был невелик – «Почта Для Домена» Яндекса или «Gmail для предприятий».
После недолгих размышлений было принято решение в пользу Google, т.к.:

1. Это «Корпорация зла», а все бизнесмены – адепты зла :)
2. Почта располагается за рубежом, что немного усложняет получения доступа к почте третьих лиц.
3. Масса дополнительных сервисов, как стандартных (Docs, Calendar), так и дополнительных.
4. Возможность подключения дополнительных возможностей за деньги (больше места, маршрутизация почты и пр.).
5. Возможность создания нескольких администраторов для управления всем сервисом.
6. Известная стабильность и качество сервиса.
7. Всё таки, ПДД Яндекса – это клон Gmail для предприятий.

За основу данной статьи взята запись в блоге Ника Джонсона (Nick Johnson). В дополнение к ней приведено немного цифр, актуальных на данный момент и добавлены некоторые заметки.

App Engine предоставляет множество способов хранения информации. Некоторые (например, хранилище данных) хорошо известны, но другие почти нет, и у всех них характеристики различаются. В этой статье будут перечислены различные возможности и описаны преимущества и недостатки каждой из них, так что Вы сможете принимать решения, имея больше информации о возможностях хранения данных.

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

Если вы используете App Engine только для простых приложений, то лучше воздержаться от дальнейшего чтения. Если же вам интересны низкоуровневые оптимизации или вы хотите написать библиотеку для работы с самыми сокровенными компонентами App Engine, прошу читать далее!

Общий API-интерфейс

В конечном счете, каждый API-вызов проходит через один общий интерфейс с 4-я аргументами: имя службы (например, 'datastore_v3' или 'memcache'), имя метода (например, 'Get' или 'RunQuery'), запрос и ответ. Запрос и ответ являются буферами протоколов — двоичным форматом, широко используемым в Google для обмена структурированными данными между процессами. Конкретный тип запроса и ответа буферов протокола зависит от вызванного метода. Когда происходит вызов API, буфер протокола запроса формируется из данных, отправленных в запросе, а буфер протокола ответа остается пустым и в дальнейшем заполняется данными, возвращенными ответом API-вызова.

Здравствуй HabraUser.
Сегодня я хочу рассказать о бесплатной open-source CMS написанной специально под Google App Engine for Java Vosao CMS ™

Выпущен релиз Google App Engine SDK 1.4.0

2 декабря разработчики Google App Engine выпустили новую версию SDK. Без преувеличений, этот релиз богат на нововведения и улучшения. Узнать о новых возможностях и других вкусностях новой версии можно под катом.

Пока у Гугла данный раздел только на английском, я делюсь своим знакомством с данной службой.



Служба XMPP позволяют GAE-приложениям отправлять и принимать жаббер-сообщения.
XMPP – открытый протокол обмена мгновенными сообщениями, на основе XML, так же известный как Jabber. Именно он уже используется в Google Talk.

API скрывают весь механизм работы с протоколом. Разработчик получает очень высокоуровневые методы, что упрощают разработку, но в то же время очень ограничивают возможности.
Если просмотреть джавадок по XMPP API, то видно, что реализован только самый необходимый минимум.

Для django есть хорошая утилитка, которая анализирует описание модели данных и рисует её графическое представление в dot-формате graphviz.
Сегодня переписал эту утилитку под appengine.



Утилита распознаёт Expando (добавляет многоточие в список атрибутов),
наследование от PolyModel (рисует стрелки наследования),
а также ссылочные свойства (в том числе самодельные, типа ManyToManyProperty).

Как пользоваться:

1. засунуть скрипт в каталог с sdk
2. запустить её из корневого каталога приложения, указав аргументами список модулей для анализа (в формате имён дя import):
   python path/to/modelviz.py models.foo models.bar > models.dot
3. сконвертить полученный dot-файл во что-нибудь более удобное, например, в png:
   dot models.dot -Tpng > models.png
4. наслаждаться неземной красотой

• Удалены лимиты на zigzag merge-join запросы. Теперь для большинства сложных запросов не нужны композитные индексы, которые сильно увеличивали занимаемый объем в хранилище. Подробнее можно посмотреть с презентации на Google IO — Next gen queries
• Максимальный размер корзины для TaskQueue увеличен до 100
• Добавлен параметр «качество изображение» для операций с Image API

Для Java: Внесение java.net.InetAddress и некоторых интерфейсов и абстрактных классов из javax.xml.soap в белый список.

Для Python: Поддержка builtin-обработчиков — отличная фича, позволяющая включить некоторую функциональность SDK (к примеру remote_api, mapreduce, etc) прямо из коробки, одним движением руки. Ниже пример для включения appstats и mapreduce. Подробнее о builtin и includes

builtins:
- mapreduce: on
- appstats: on

Изменения в админке на продакшене:

• Instances консоль — теперь можно посмотреть, сколько их запущено для приложения, а также посмотреть их параметры (QPS, Latency, Memory)
• Можно запускать задания прямо из админки
• При включенном built-in datastore_admin можно удалить все (или часть) данных из конкретной таблицы в автоматическом режиме, используя для этих целей mapreduce. Однако нужно помнить, что это ресурсозатратно, и можно попасть на лимиты

Те, кто включил в своём приложении на GAE поддержку сессий, знают, что сессии, во-первых, записываются в datastore, а во-вторых, автоматически оттуда не исчезают. От протухших сессий надо как-то избавляться самостоятельно.

Я как-то не заботился о протухших сессиях, и за полтора года их накопилось полтора миллиона штук. Недавно размер хранимых в datastore данных превысил бесплатную квоту и, так как 99% было занято сессиями, я решил поудалять протухшие.

• Отмена 1000-лимита на запрос в хранилище для count и offset. Такие безлимитные запросы будут теперь исполняться до получения результата, или выкидывать ошибку по таймауту хранилища. Я сам слегка потестировал — есть небольшие тормоза на средней базе в пару миллионов записей при смещении в миллион (порядка пары-тройки секунд задержка), однако вполне годно. Хотя, судя по коду SDK, максимальный лимит все же есть, равный 2^31 — 1.
• Новое Namespaces API для Java и Python, которое позволяет создавать «коммунальные» (multi-tenancy) приложения без особых модификаций уже существующего кода.
• Замена сервиса картинок на высокопроизводительное решение, основанное на picasa, что позволит делать превьюшки картинок (crop и/или resize), фактически без использования ваших ресурсов (только трафик) в добавлении к предыдущим умениям Image API.
• Пользовательские страницы для системных ошибок — over quota, DoS, timeout и прочих.
• В Java добавлено Capabilities API, по аналогии с Питоном, а также java-приложения научились понимать конфиги в yaml-формате.
• Многие фиксированные квоты бесплатных приложений увеличились до уровня платных, подробнее.
• Blobstore API теперь поддерживает Content-Range заголовок.

Полные списки изменений:
— Release Notes: Python
— Release Notes: Java
— Revision History