В production ява и питон не особо различаются, разве что ява быстрее считает. Зато для неё нет множества полезных мелочей, доступных для питона. В целом, AE на питоне это взгляд гугла на разработку веб-приложений, а ява — поддержка устоявшегося корпоративного стандарта.
Если не знакомы ни с одним из языков, то лучше начинать с питона в нормальной IDE. Попробуйте поработать в PyCharm — она поддерживает GAE «из коробки» и существенно облегчает процесс разработки.
1. Из логов приложений и наблюдений за приложениями. Команда App Engine не успевает даже поддерживать в актуальном состоянии документацию по более общим и используемым API, так что найти информацию «от производителя» о нюансах работы инстансов вряд ли представляется возможным. К тому же, эта информация может устареть после следующей оптимизации системы.
2. Как единственное хранилище, конечно же, не стоит. Но для дублирования данных, которые хранятся в datastore память подходит очень хорошо. Ведь данные из API приходят не в готовом к употреблению формате, и объект приходится собирать на стороне приложения (этим занимается модуль db). Всё это потребляет и процессор и память, так что зачастую гораздо выгоднее просто хранить копию данных в памяти (тем более, что за неё денег не просят).
Память инстанса плохо подходит для часто изменяемых данных — может быть несколько инстансов приложения и в каждом будет свой набор данных. В такой ситуации для тяжёлых запросов к базе лучше использовать memcache.
После 9000 запросов к инстансу App Engine сообщает, что достигнуто максимальное количество запросов для инстанса и он будет перезапущен. Но это происходит при равномерной небольшой нагрузке, то есть сравнительно редко. Обычно, у инстансов высокие шансы отключиться при достижении размера потребляемой памяти в 70Мб — и на переменные, и для выполнения кода. Чем больше объём памяти, тем раньше инстанс отключится (иногда при этом может выдавать предложения поискать утечки памяти), при достижении объёма в 200Мб инстансы выключаются с критическими ошибками примерно такого содержания:
Exceeded soft memory limit with 200.852 MB after servicing 17 requests total
Похоже, что дорабатывают и настраивают основное datastore — HRDS-приложения работают стабильно, в то время, как обычные лихорадит самыми различными способами.
А что у Вас при этом отображается? Гугл говорит, что должна быть капча.
Вообще, не ожидал столь активных действий от гугловского анти-DoS. Кто-нибудь знает когда он начинает срабатывать?
Некоторые преподаватели уже несколько лет сами раздают конспекты — остаётся только слушать лекции, сверяясь с распечаткой. Самые изобретательные оставляют в таких конспектах ошибки, о которых говорят только на лекциях или вообще составляют такие конспекты, что без прослушивания лекции не разберёшься…
Предпочитаю webob для приложений «полегче» и webapp для «покрасивее» — весь луна-парк из django вряд ли когда понадобится. Плюс, django может стартовать секунд 10, что может быть довольно неприятно для пользователя. Однако, изменение полезных часто используемых компонентов может поломать приложение — так что, мой комментарий был скорее для тех, кто читает хабр и не читает логи приложений.
Хотя бы потому, что он может потреблять много ресурсов :)
Чтобы проверить код на актуальных данных не в боевом режиме, достаточно отредактировать одну строку в app.yaml. Ну а дальше AppStats, логи приложения и нехитрое умножение на возможное количество выполнений кода выявили бы проблему до появления душераздирающих скриншотов.
В эти квоты довольно сложно упереться — трафик кончится быстрее. Даже чтоб использовать 657К запросов с выключенным биллингом и не упереться в 1Гб надо, чтоб на запрос уходило менее 1.5Кб трафика — при таких объёмах большинство других способов подойдёт гораздо лучше.
Может быть Вы имеете в виду что запрос выполняется секунду? Процессорное время в таких количествах URLFetch не потребляет. Цифры с работающего приложения — запрос хабраленты, её парсинг с добавлением в очередь отсутствующих хаписей, либо получение записей и занесение в базу в среднем потребляет 418 cpu_ms (из них 249 api_cpu). Время выполнения при этом находится в пределах 0.3..4с.
На этом агрегате нет привычного для больших антенн разъёма N-type, для линков гораздо лучше подходит ubiquiti bullet. Также я бы посоветовал присмотреться к антеннам на 27дБ — они не сильно дороже, но скорость будет заметно выше.
У меня сейчас в режиме моста работают dwl-2100 (с поднятой мощностью и немного допиленные) с антеннами asp-24, расстояние менее 3км, обзор также закрывают деревья — в зависимости от погоды скорость линка колеблется от 1 до 24 Мбит, иногда связь может пропадать на короткий срок.
Пока не было Always On, для поддержания приложений активно использовались хаки с запросами через cron или бесконечный taskqueue раз в минуту или чаще. Похоже, что теперь сервисные запросы обладают другим приоритетом и эффективность хаков снизилась. Что, впрочем, не мешает повесить запрашивающий скрипт на другое приложение…
Подробная информация по архитектуре вряд ли будет доступна. Желающих получить максимальный приоритет обходными путями немало, а их действия могут плохо повлиять на простых пользователей.
Если не знакомы ни с одним из языков, то лучше начинать с питона в нормальной IDE. Попробуйте поработать в PyCharm — она поддерживает GAE «из коробки» и существенно облегчает процесс разработки.
2. Как единственное хранилище, конечно же, не стоит. Но для дублирования данных, которые хранятся в datastore память подходит очень хорошо. Ведь данные из API приходят не в готовом к употреблению формате, и объект приходится собирать на стороне приложения (этим занимается модуль db). Всё это потребляет и процессор и память, так что зачастую гораздо выгоднее просто хранить копию данных в памяти (тем более, что за неё денег не просят).
Вообще, не ожидал столь активных действий от гугловского анти-DoS. Кто-нибудь знает когда он начинает срабатывать?
Чтобы проверить код на актуальных данных не в боевом режиме, достаточно отредактировать одну строку в app.yaml. Ну а дальше AppStats, логи приложения и нехитрое умножение на возможное количество выполнений кода выявили бы проблему до появления душераздирающих скриншотов.
У меня сейчас в режиме моста работают dwl-2100 (с поднятой мощностью и немного допиленные) с антеннами asp-24, расстояние менее 3км, обзор также закрывают деревья — в зависимости от погоды скорость линка колеблется от 1 до 24 Мбит, иногда связь может пропадать на короткий срок.
Подробная информация по архитектуре вряд ли будет доступна. Желающих получить максимальный приоритет обходными путями немало, а их действия могут плохо повлиять на простых пользователей.