Вместе веселей: python + flask + google app engine

Думаю, лучше посмотреть в сторону чего-то вроде Azure. При работе с GAE выбор языков, фреймворков, БД сокращается до неприличия. Но как зарядка для мозгов сервис весьма интересен. Написать приложение, которое держало бы хоть какую-то нагрузку, и при этом не выбивалось бы за пределы бесплатных лимитов — не самая тривиальная задача.
Я как-то использовал GAE для создания RSS-ленты обновлений «Самиздата». Первоначальная версия регулярно сканировала странички выбранных авторов и собирало обновления в RSS.
Эта версия проработала менее суток, после чего улетела в бан на сутки в связи с превышением лимитов на процессорное время. К счастью, GAE обладает отличной системой логгирования, т.ч. разобраться в проблеме удалось довольно быстро. Оказывается, один из отслеживаемых авторов удалил свою страничку, и при попытке её прочитать приложение падало с исключением. А GAE, как оказалось, в случае падения cron-задания сразу же его перезапускает. Т.е. приложение отрабатывало раз за разом, без перерыва, каждый раз падая. А когда подходило время следующего сканирования, по cron'у запускался новый экземпляр, и тоже начинал непрерывно падать/перезапускаться. И так пока не кончились выделенные ресурсы.
В итоге вынес для себя первое правило: исключения надо обрабатывать, а не забивать на них в надежде, что падение просто убьёт данный конкретный экземпляр.
Итак, исправленная версия некоторое время успешно работала, но как только количество авторов превысило некоторый предел — вновь улетело в бан, уже с исчерпанием лимита обращений к БД.
Вообще, база у них довольно своеобразно устроена. А уж подсчёт количества «условных операций» и вовсе производится чрезвычайно хитрым способом, т.ч. чем больше полей в записи, тем больше этих операций уходит во время поиска/считывания даже одного поля.
В итоге единственный способ кардинально уменьшить кол-во операций — завернуть все записи в неиндексируемый blob (например, с помощью pickle), а наружу пробросить и хранить в открытом виде только те поля, которые непосредственно нужны для поиска.
На некоторое время такой оптимизации хватало, но по мере роста числа пользователей вновь превысился лимит. Пришлось провести следующий этап оптимизации — активно использовать кэш (memcache). Теперь вся работа с записями была целиком помещена в кэш, операции с которым полностью бесплатны, а в базу его содержимое скидывалось раз в сутки. Кэш периодически сбрасывается, причём логики в этом процессе я не увидел — может работать неделю, а может по три раза в сутки очищаться. В случае сброса кэша приложение загружало в него данные из базы — в этом случае терялось лишь несколько последних обновлений, которые восстанавливались путём сканирования «Самиздата».
По мере увеличения количества отслеживаемых авторов рос и трафик приложения, т.ч. пришлось, пока он не подобрался вплотную к лимитам, оптимизировать процесс сканирования.
Так, большинство авторов обновлялось по утрам и вечерам, а после полуночи количество обновлений было исчезающе малым, да и обращений к RSS-ленте падало почти до нуля. Поэтому было решено с полуночи и до семи утра сканирование вообще не проводить. А в дальнейшем интервалы между сканированиями сделать настраивающимися — в зависимости от того, как часто в эти часы обновляются авторы.
Немного общих впечатлений:

1. Абсолютно все файлы должны использовать utf-8. Если где-то у вас используется другая кодировка, потом в самых неожиданных местах начнут вываливаться исключения. Это же касается и всех входных данных. Самиздат использует win-1251, и я потратил немало времени в бесплодных попытках парсить его прямо в этой кодировке. В итоге наконец перестал маяться дурью и просто конвертировал все входные данные в utf-8 в момент их чтения.
2. Изрядно пришлось помучиться с функциями даты и времени. В конце концов привязался к UTC, ибо автоматическую работу с локальным временем так и не осилил — все эти функции ведут себя неадекватно, настройки всё время самопроизвольно сбрасываются, часть функций вообще не работает, вместо них там стоят заглушки. В общем, Python там какой-то урезанный.
3. SDK для Windows не обрабатывает ошибок загрузки и не позволяет «разруливать» связанные с ними проблемы. Например, если на середине деплоя прервётся соединение, приложение окажется в мёртвом состоянии, и залить поверх него рабочую версию не получится — придётся закрыть SDK и открыть консоль, через которую и решаются все подобные случаи. Т.ч. лучше учиться сразу работать с консолью, т.к. рано или поздно она вам всё равно понадобится.

Нет, не мой.

Благодарю, рад, что оказался полезен :)

Спасибо :)

Done!