1. Когда я активно изучал GAE, не слышал, чтобы docs был сделан на нем.
2. Python. Сначала django, потом родной для GAE webapp.
3. Stateless.
4. При пиковой нагрузке в memcache хранилось 0,8 — 2 млн. объектов. Каждый объект содержал данные о юзере. В каждом объекте — не более 100 байт. Впоследствие оказалось, что узкое место было именно в чтении из datastore и memcache при этом не спасал. Так что, скорее всего, размер memcache полтора года назад был не более 200 МБайт на приложение.
5. Объект в datastore хранил тоже самое, что и memcache + историю операций пользователя.
6,7. Datastore contention — это первое, что пришло на ум разработчикам GAE. В итоге пришлось использовать технику sharding и разбить каждый объект на несколько, переписав логику работы с ними. Не помогло. Как я уже говорил, узкое место было в datastore read, т.к. каждый запрос в среднем генерировал по 10-20 запросов к хранилищу. Решение проблемы заключалось в присвоении каждому объекту ключевого имени (которым было id пользователя) и чтению объектов batch запросами по этим ключевикам. Кстати, вскоре после этого они написали статью о решении этой проблемы: code.google.com/appengine/articles/scaling/minimize.html.
8. Глянул сейчас в админку GAE и не нашел способа посмотреть данные логов годичной давности. На самом деле приложение было не большим, наоборот, простейшим, но все равно проблем избежать не удалось. Сейчас размер datastore 5 gb, но вряд ли это очень интересно.
Ага, было такое:) Проблемы начались после того, как нагрузка превысила 200rps. Latency стала доходить до 10 секунд и соединение принудительно разрывалось. Обратившись в тех. поддержку, от разработчиков GAE я узнал, что они впервые сталкиваются с такой нагрузкой и посоветовали несколько вариантов решения проблемы. К сожалению, они не помогли, но в ходе дальнейшей переписки все-таки удалось выявить ботлнэк. Кстати, вскоре после этого они сделали отдельный раздел с советами по масштабируемости, который обязателен к прочтению всем тем, кто собирается разрабатывать высоконагруженный проект на этой платформе.
Если вас пугает невозможность использовать программу, написанную под app engine на своих серверах, то есть проект App Scale, который как раз и решает эту проблему.
Из их блога: «We believe these new levels will continue to support a reasonably efficient application serving around 5 million page views per month, completely free.»
Точные цифры они еще не назвали.
Есть, но в SDK включена версия 0.96. Советую использовать app_engine_patch для работы с django в gae. В версии 1.0 (совсем недавно вышла) включена поддержка приложений, включая джанговскую админку.
Ага, точно. Сейчас исправлю. Для полноты картины, как считается процессорное время, следует добавить еще одну цитату из доков:
«CPU time is reported in „seconds,“ which is equivalent to the number of CPU cycles that can be performed by a 1.2 GHz Intel x86 processor in that amount of time. The actual number of CPU cycles spent varies greatly depending on conditions internal to App Engine, so this number is adjusted for reporting purposes using this processor as a reference measurement.»
Думаю, только по метаинформации определять достаточно релевантную рекламу сложно. Вот когда они прикрутят систему распознавания речи к ютьюбу, возможно и появится видео реклама в начале ролика либо бегущая строка.
Появление такого сервиса скорее связана с успешным опытом использования аутсорс-переводов фэйсбуком, который начал локализовывать свой сайт таким образом еще с прошлого года. А недели две назад фэйс анонсировал, что такой перевод также будет доступен и для приложений, созданных с помощью API Facebook'а.
2. Python. Сначала django, потом родной для GAE webapp.
3. Stateless.
4. При пиковой нагрузке в memcache хранилось 0,8 — 2 млн. объектов. Каждый объект содержал данные о юзере. В каждом объекте — не более 100 байт. Впоследствие оказалось, что узкое место было именно в чтении из datastore и memcache при этом не спасал. Так что, скорее всего, размер memcache полтора года назад был не более 200 МБайт на приложение.
5. Объект в datastore хранил тоже самое, что и memcache + историю операций пользователя.
6,7. Datastore contention — это первое, что пришло на ум разработчикам GAE. В итоге пришлось использовать технику sharding и разбить каждый объект на несколько, переписав логику работы с ними. Не помогло. Как я уже говорил, узкое место было в datastore read, т.к. каждый запрос в среднем генерировал по 10-20 запросов к хранилищу. Решение проблемы заключалось в присвоении каждому объекту ключевого имени (которым было id пользователя) и чтению объектов batch запросами по этим ключевикам. Кстати, вскоре после этого они написали статью о решении этой проблемы: code.google.com/appengine/articles/scaling/minimize.html.
8. Глянул сейчас в админку GAE и не нашел способа посмотреть данные логов годичной давности. На самом деле приложение было не большим, наоборот, простейшим, но все равно проблем избежать не удалось. Сейчас размер datastore 5 gb, но вряд ли это очень интересно.
Точные цифры они еще не назвали.
«CPU time is reported in „seconds,“ which is equivalent to the number of CPU cycles that can be performed by a 1.2 GHz Intel x86 processor in that amount of time. The actual number of CPU cycles spent varies greatly depending on conditions internal to App Engine, so this number is adjusted for reporting purposes using this processor as a reference measurement.»
материал-то не новый