Комментарии 21
Пост интересный, ещё бы картини показывались бы:
Our systems have detected unusual traffic from your computer network. Please try your request again later. Why did this happen?
IP address: — Time: 2011-02-16T11:54:31Z
URL: cache.aeresearchlab.appspot.com/img/list_lm_pb.png
Our systems have detected unusual traffic from your computer network. Please try your request again later. Why did this happen?
IP address: — Time: 2011-02-16T11:54:31Z
URL: cache.aeresearchlab.appspot.com/img/list_lm_pb.png
А что у Вас при этом отображается? Гугл говорит, что должна быть капча.
Вообще, не ожидал столь активных действий от гугловского анти-DoS. Кто-нибудь знает когда он начинает срабатывать?
Вообще, не ожидал столь активных действий от гугловского анти-DoS. Кто-нибудь знает когда он начинает срабатывать?
А у всех последнее время все нормально с инстансами?
Несколько дней назад запустил простое fb-приложение — реально простое, большая часть вообще на статике. Включил биллинг и выбрал Always on. В памяти постоянно висят по три инстанса, но часто натыкаюсь на то, что приложение тупо не открывается — таймаут соединения до ..appspot.com
Все понимаю, что бета — но деньги-то за «always on» снимают, а никакого always on'а на практике нет.
Несколько дней назад запустил простое fb-приложение — реально простое, большая часть вообще на статике. Включил биллинг и выбрал Always on. В памяти постоянно висят по три инстанса, но часто натыкаюсь на то, что приложение тупо не открывается — таймаут соединения до ..appspot.com
Все понимаю, что бета — но деньги-то за «always on» снимают, а никакого always on'а на практике нет.
Да, последние дни замечаю тормоза.
Интересно.
У меня даже без «Always on» ни разу не было таймаута. Было в январе, что приложение на 30 мин. перестало работать, но это зафиксировано в состоянии системы.
Можно ссылку на ваш сайт (если не публичный — то можно в личку)?
У меня даже без «Always on» ни разу не было таймаута. Было в январе, что приложение на 30 мин. перестало работать, но это зафиксировано в состоянии системы.
Можно ссылку на ваш сайт (если не публичный — то можно в личку)?
+1 именно последние несколько днй тоже самое
но в систем статусе это отмечено как падение хранилища
но в систем статусе это отмечено как падение хранилища
Спасибо. Интересно. С удовольствием буду читать продолжение исследования возможностей App Engine.
Мне, например, интересно, возможен ли эффект от использования memcache для операций над Datastore типа «изменение записи». То есть 1 вариант: взяли из Datastore, изменили, сохранили в Datastore; взяли другую запись (а может ту же), изменили, сохранили в Datastore; и т.д. 2 вариант: посмотрели в Memcache, если там есть, то взяли оттуда, если там нет взяли из Datastore, изменили, сохранили в Datastore + сохранили в Memcache; и т.д.
Мне, например, интересно, возможен ли эффект от использования memcache для операций над Datastore типа «изменение записи». То есть 1 вариант: взяли из Datastore, изменили, сохранили в Datastore; взяли другую запись (а может ту же), изменили, сохранили в Datastore; и т.д. 2 вариант: посмотрели в Memcache, если там есть, то взяли оттуда, если там нет взяли из Datastore, изменили, сохранили в Datastore + сохранили в Memcache; и т.д.
Если я правильно понял вашу задачу, то она реализуется несколькими строчками кода.
Можно добавить еще один шаг: посмотрели в память инстанса, если там нет, то посмотрели в мемкеш, если там нет, то в датасторе, изменили, положили в датасторе, в мемкеш, в память инстанса. Мне тоже интересно, будет ли от этого толк.
На самом деле у меня так и есть. Использовать память инстанса есть смысл без сомнения (по крайней мере, если интенсивность использования достаточная для того, чтобы он не каждый раз грузился заново). А вот насчет использования мемкеша в случае, когда потом будет обязательная запись в хранилище создалось ощущение, что может и нет смысла. Тут надо понимать как работает хранилище, либо ставить аккуратный эксперимент.
Память инстанса плохо подходит для часто изменяемых данных — может быть несколько инстансов приложения и в каждом будет свой набор данных. В такой ситуации для тяжёлых запросов к базе лучше использовать memcache.
Справедливое замечание. О возможности существования «параллельных» инстансов надо всегда помнить.
Разумность использования всего этого так или иначе сильно зависит от особенностей приложения. Например, если если вероятность многократного рид-онли использования одних и тех же данных в процессе жизни одного инстанса велика, то использование оперативки разумно. В моем же примере, хоть инстанс и делал сейвы, я точно знал, что нет одновременно другого, работающего с теми же данными (но это экзотический случай).
Разумность использования всего этого так или иначе сильно зависит от особенностей приложения. Например, если если вероятность многократного рид-онли использования одних и тех же данных в процессе жизни одного инстанса велика, то использование оперативки разумно. В моем же примере, хоть инстанс и делал сейвы, я точно знал, что нет одновременно другого, работающего с теми же данными (но это экзотический случай).
> памяти этой всего 50Мб, до предельного возраста в 9000 запросов инстансы доживают крайне редко
а можно немного детальнее в этом месте?
а можно немного детальнее в этом месте?
После 9000 запросов к инстансу App Engine сообщает, что достигнуто максимальное количество запросов для инстанса и он будет перезапущен. Но это происходит при равномерной небольшой нагрузке, то есть сравнительно редко. Обычно, у инстансов высокие шансы отключиться при достижении размера потребляемой памяти в 70Мб — и на переменные, и для выполнения кода. Чем больше объём памяти, тем раньше инстанс отключится (иногда при этом может выдавать предложения поискать утечки памяти), при достижении объёма в 200Мб инстансы выключаются с критическими ошибками примерно такого содержания:
Exceeded soft memory limit with 200.852 MB after servicing 17 requests total
1) а откуда взята такая информация? есть где подробно почитать про рассказанное вами?
2) в таком случае точно не стоит хранить какие либо статус состояния в памяти инстанса, кстати еще где-то читал что следующий запрос от одного пользователя может попадать совершенно в другой инстанс.
2) в таком случае точно не стоит хранить какие либо статус состояния в памяти инстанса, кстати еще где-то читал что следующий запрос от одного пользователя может попадать совершенно в другой инстанс.
насчет (2) — естественно может. и с высокой вероятностью.
Кстати, хранение чего-то общего для всех — действительно проблема. Мемкеш не гарантирует, а хранилище порой дороговато выходит.
Кстати, хранение чего-то общего для всех — действительно проблема. Мемкеш не гарантирует, а хранилище порой дороговато выходит.
1. Из логов приложений и наблюдений за приложениями. Команда App Engine не успевает даже поддерживать в актуальном состоянии документацию по более общим и используемым API, так что найти информацию «от производителя» о нюансах работы инстансов вряд ли представляется возможным. К тому же, эта информация может устареть после следующей оптимизации системы.
2. Как единственное хранилище, конечно же, не стоит. Но для дублирования данных, которые хранятся в datastore память подходит очень хорошо. Ведь данные из API приходят не в готовом к употреблению формате, и объект приходится собирать на стороне приложения (этим занимается модуль db). Всё это потребляет и процессор и память, так что зачастую гораздо выгоднее просто хранить копию данных в памяти (тем более, что за неё денег не просят).
2. Как единственное хранилище, конечно же, не стоит. Но для дублирования данных, которые хранятся в datastore память подходит очень хорошо. Ведь данные из API приходят не в готовом к употреблению формате, и объект приходится собирать на стороне приложения (этим занимается модуль db). Всё это потребляет и процессор и память, так что зачастую гораздо выгоднее просто хранить копию данных в памяти (тем более, что за неё денег не просят).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кэширование в Google App Engine