Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Хочется побольше историй про опыт использования GAE и выводы.
Думаю, лучше посмотреть в сторону чего-то вроде Azure. При работе с GAE выбор языков, фреймворков, БД сокращается до неприличия. Но как зарядка для мозгов сервис весьма интересен. Написать приложение, которое держало бы хоть какую-то нагрузку, и при этом не выбивалось бы за пределы бесплатных лимитов — не самая тривиальная задача.
Я как-то использовал GAE для создания RSS-ленты обновлений «Самиздата». Первоначальная версия регулярно сканировала странички выбранных авторов и собирало обновления в RSS.
Эта версия проработала менее суток, после чего улетела в бан на сутки в связи с превышением лимитов на процессорное время. К счастью, GAE обладает отличной системой логгирования, т.ч. разобраться в проблеме удалось довольно быстро. Оказывается, один из отслеживаемых авторов удалил свою страничку, и при попытке её прочитать приложение падало с исключением. А GAE, как оказалось, в случае падения cron-задания сразу же его перезапускает. Т.е. приложение отрабатывало раз за разом, без перерыва, каждый раз падая. А когда подходило время следующего сканирования, по cron'у запускался новый экземпляр, и тоже начинал непрерывно падать/перезапускаться. И так пока не кончились выделенные ресурсы.
В итоге вынес для себя первое правило: исключения надо обрабатывать, а не забивать на них в надежде, что падение просто убьёт данный конкретный экземпляр.
Итак, исправленная версия некоторое время успешно работала, но как только количество авторов превысило некоторый предел — вновь улетело в бан, уже с исчерпанием лимита обращений к БД.
Вообще, база у них довольно своеобразно устроена. А уж подсчёт количества «условных операций» и вовсе производится чрезвычайно хитрым способом, т.ч. чем больше полей в записи, тем больше этих операций уходит во время поиска/считывания даже одного поля.
В итоге единственный способ кардинально уменьшить кол-во операций — завернуть все записи в неиндексируемый blob (например, с помощью pickle), а наружу пробросить и хранить в открытом виде только те поля, которые непосредственно нужны для поиска.
На некоторое время такой оптимизации хватало, но по мере роста числа пользователей вновь превысился лимит. Пришлось провести следующий этап оптимизации — активно использовать кэш (memcache). Теперь вся работа с записями была целиком помещена в кэш, операции с которым полностью бесплатны, а в базу его содержимое скидывалось раз в сутки. Кэш периодически сбрасывается, причём логики в этом процессе я не увидел — может работать неделю, а может по три раза в сутки очищаться. В случае сброса кэша приложение загружало в него данные из базы — в этом случае терялось лишь несколько последних обновлений, которые восстанавливались путём сканирования «Самиздата».
По мере увеличения количества отслеживаемых авторов рос и трафик приложения, т.ч. пришлось, пока он не подобрался вплотную к лимитам, оптимизировать процесс сканирования.
Так, большинство авторов обновлялось по утрам и вечерам, а после полуночи количество обновлений было исчезающе малым, да и обращений к RSS-ленте падало почти до нуля. Поэтому было решено с полуночи и до семи утра сканирование вообще не проводить. А в дальнейшем интервалы между сканированиями сделать настраивающимися — в зависимости от того, как часто в эти часы обновляются авторы.
Немного общих впечатлений:
Я как-то использовал GAE для создания RSS-ленты обновлений «Самиздата». Первоначальная версия регулярно сканировала странички выбранных авторов и собирало обновления в RSS.
Эта версия проработала менее суток, после чего улетела в бан на сутки в связи с превышением лимитов на процессорное время. К счастью, GAE обладает отличной системой логгирования, т.ч. разобраться в проблеме удалось довольно быстро. Оказывается, один из отслеживаемых авторов удалил свою страничку, и при попытке её прочитать приложение падало с исключением. А GAE, как оказалось, в случае падения cron-задания сразу же его перезапускает. Т.е. приложение отрабатывало раз за разом, без перерыва, каждый раз падая. А когда подходило время следующего сканирования, по cron'у запускался новый экземпляр, и тоже начинал непрерывно падать/перезапускаться. И так пока не кончились выделенные ресурсы.
В итоге вынес для себя первое правило: исключения надо обрабатывать, а не забивать на них в надежде, что падение просто убьёт данный конкретный экземпляр.
Итак, исправленная версия некоторое время успешно работала, но как только количество авторов превысило некоторый предел — вновь улетело в бан, уже с исчерпанием лимита обращений к БД.
Вообще, база у них довольно своеобразно устроена. А уж подсчёт количества «условных операций» и вовсе производится чрезвычайно хитрым способом, т.ч. чем больше полей в записи, тем больше этих операций уходит во время поиска/считывания даже одного поля.
В итоге единственный способ кардинально уменьшить кол-во операций — завернуть все записи в неиндексируемый blob (например, с помощью pickle), а наружу пробросить и хранить в открытом виде только те поля, которые непосредственно нужны для поиска.
На некоторое время такой оптимизации хватало, но по мере роста числа пользователей вновь превысился лимит. Пришлось провести следующий этап оптимизации — активно использовать кэш (memcache). Теперь вся работа с записями была целиком помещена в кэш, операции с которым полностью бесплатны, а в базу его содержимое скидывалось раз в сутки. Кэш периодически сбрасывается, причём логики в этом процессе я не увидел — может работать неделю, а может по три раза в сутки очищаться. В случае сброса кэша приложение загружало в него данные из базы — в этом случае терялось лишь несколько последних обновлений, которые восстанавливались путём сканирования «Самиздата».
По мере увеличения количества отслеживаемых авторов рос и трафик приложения, т.ч. пришлось, пока он не подобрался вплотную к лимитам, оптимизировать процесс сканирования.
Так, большинство авторов обновлялось по утрам и вечерам, а после полуночи количество обновлений было исчезающе малым, да и обращений к RSS-ленте падало почти до нуля. Поэтому было решено с полуночи и до семи утра сканирование вообще не проводить. А в дальнейшем интервалы между сканированиями сделать настраивающимися — в зависимости от того, как часто в эти часы обновляются авторы.
Немного общих впечатлений:
- Абсолютно все файлы должны использовать utf-8. Если где-то у вас используется другая кодировка, потом в самых неожиданных местах начнут вываливаться исключения. Это же касается и всех входных данных. Самиздат использует win-1251, и я потратил немало времени в бесплодных попытках парсить его прямо в этой кодировке. В итоге наконец перестал маяться дурью и просто конвертировал все входные данные в utf-8 в момент их чтения.
- Изрядно пришлось помучиться с функциями даты и времени. В конце концов привязался к UTC, ибо автоматическую работу с локальным временем так и не осилил — все эти функции ведут себя неадекватно, настройки всё время самопроизвольно сбрасываются, часть функций вообще не работает, вместо них там стоят заглушки. В общем, Python там какой-то урезанный.
- SDK для Windows не обрабатывает ошибок загрузки и не позволяет «разруливать» связанные с ними проблемы. Например, если на середине деплоя прервётся соединение, приложение окажется в мёртвом состоянии, и залить поверх него рабочую версию не получится — придётся закрыть SDK и открыть консоль, через которую и решаются все подобные случаи. Т.ч. лучше учиться сразу работать с консолью, т.к. рано или поздно она вам всё равно понадобится.
В то время Google очень активно пиарил свой сервис, облака были в моде — считалось, что за этими технологиями будущее, а стандартные хостинги рано или поздно вымрут. Вот и стало интересно попробовать на вкус облачные технологии. В итоге пришёл к выводу, что GAE сильно на любителя. Это не самое удачное из облачных решений, т.к. в нагрузку к облаку идёт пакет специфических гуглотехнологий.
Я когда читал ваш комментарий у меня волосы дыбом вставали. Ну как такое можно писать не разобравшись в теме?
Большинство проблем у вас возникало, только потому что вы в один присест хотели освоить целый стек технологий. Причем постоянно прослеживается мысль, что вы толком не изучали документацию.
Чего только стоит ваше:
Про кодировки, тут вообще не понятно причем тут облачный хостинг. Их везде самому надо разруливать.
Python действительно сильно порезан, но это как бы уже сразу описано в документации.
По последнему пункту, вообще у меня такое бывало и не раз. И постоянно я видел в логе чёткие указание, что необходимо сделать чтобы исправить. И после одной команды всё приходило в норму. Прямо представляю ситуацию из параллельного мира, разработчик на php который деплоит через ftp на хостинг. И тут рвется соединение, половина прошла, а другая нет, а посетители таким образом нашли лазейки «для чего-нибудь», к примеру из-за этого создаются временные файлы. И бедный программист заново идет и руками разгребает, что наделали посетители, а потом ещё и жалуется что деплой в лайв не консистентый!
Ну и финишом, рекомендация использовать виртуалки другого облачного хостинга? Серьезно? Это даже не на одном уровне. Я понимаю, если бы вы конкретно разобрались, а так это не профессионально.
Большинство проблем у вас возникало, только потому что вы в один присест хотели освоить целый стек технологий. Причем постоянно прослеживается мысль, что вы толком не изучали документацию.
Чего только стоит ваше:
На некоторое время такой оптимизации хватало, но по мере роста числа пользователей вновь превысился лимит. Пришлось провести следующий этап оптимизации — активно использовать кэш (memcache). Теперь вся работа с записями была целиком помещена в кэш, операции с которым полностью бесплатны, а в базу его содержимое скидывалось раз в сутки. Кэш периодически сбрасывается, причём логики в этом процессе я не увидел — может работать неделю, а может по три раза в сутки очищаться.Логики? Какой логики вы ожидали? Кэш, он на то и кэш, что не гарантирует постоянное хранение данных, а тем более предсказуемое время хранения!
Про кодировки, тут вообще не понятно причем тут облачный хостинг. Их везде самому надо разруливать.
Python действительно сильно порезан, но это как бы уже сразу описано в документации.
По последнему пункту, вообще у меня такое бывало и не раз. И постоянно я видел в логе чёткие указание, что необходимо сделать чтобы исправить. И после одной команды всё приходило в норму. Прямо представляю ситуацию из параллельного мира, разработчик на php который деплоит через ftp на хостинг. И тут рвется соединение, половина прошла, а другая нет, а посетители таким образом нашли лазейки «для чего-нибудь», к примеру из-за этого создаются временные файлы. И бедный программист заново идет и руками разгребает, что наделали посетители, а потом ещё и жалуется что деплой в лайв не консистентый!
Ну и финишом, рекомендация использовать виртуалки другого облачного хостинга? Серьезно? Это даже не на одном уровне. Я понимаю, если бы вы конкретно разобрались, а так это не профессионально.
Сколько примерно пользователей / обновлений держало в бесплатном режиме?
Не ваш ли проект VK Auidopad?
Спасибо! Очень подробная и весьма достойная статья. Вдвойне приятно, что выполняете данные обещания — это дорого стоит.
Хорошая статья, продолжайте. Для себя узнал про пакет
site, даже странно что я про него ничего не знал. Позор мне! =)
Касательно Mac OS — все точно также, есть Launcher, но можно и из командной строки все делать (и даже большее).
Кстати, а почему flask? Вот "сравнение".
Очень нужно про АПИ Вконтакте, может быть ответите на вопрос на стэке: stackoverflow.com/questions/25673941/how-to-save-json-from-vk-com-api-response-to-mongodb
Done!
plus.google.com/u/0/+VicNgrail/posts/f8YWYtdqGSz вот тут еще обсуждение, ответа пока нет, застрял на
Этот код печатает то, что нужно сохранить, айтемы вроде: {u'likes': {u'count': 4, u'can_publish': 1, u'can_like': 1, u'user_likes': 0}, u'attachments': [{u'photo': {u'access_key': u'dff779d5b0ebfa8818', u'src': u'cs540104.vk.me/c540103/v5401039… u'from_id': 71234389}
Вот не могу этот JSON сохранить
for vk_post in vk_posts[1:]:
print vk_post
Этот код печатает то, что нужно сохранить, айтемы вроде: {u'likes': {u'count': 4, u'can_publish': 1, u'can_like': 1, u'user_likes': 0}, u'attachments': [{u'photo': {u'access_key': u'dff779d5b0ebfa8818', u'src': u'cs540104.vk.me/c540103/v5401039… u'from_id': 71234389}
Вот не могу этот JSON сохранить
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вместе веселей: python + flask + google app engine