sfoid Feb 10 2011 at 11:29

Простые вещи с непростым AppEngine

3 min

1.1K

Google App Engine*

+14

Comments 28

praan Feb 10 2011 at 11:52

xpostman Feb 10 2011 at 12:24

Ещё не открывая кат, увидев картинку в посте, я понял, о чём будет первый коммент.

sfoid Feb 10 2011 at 13:24

Все так плохо?..
Я понимаю, что дизайн программистский, что бы мне с ним сделать? Шрифты одинаковые поставить?

xpostman Feb 10 2011 at 13:42

Не, ничего плохого. Тут просто ироничный оффтопик с первых комментов: шрифт был выбран чересчур провокационный у вас =)

PS Когда по картинке становится ясно, о чём будет первый коммент, а потом зайдя под кат видишь, что первого коммента НЕТ — истинное мастерство состоит в том, чтоб этот коммент не писать :)

Mear Feb 10 2011 at 12:06

По моему в таких случаях проще пересчитывать место в рейтинге по крону, чем придумывать запутанный алгоритм.

sfoid Feb 10 2011 at 12:35

Может быть проще, но latency увеличится, а мы же в 21-ом веке живем :)

Mear Feb 10 2011 at 12:43

С одной стороны вы правы… с другой. Как увеличится у вас нагрузка при увеличении количества игроков (т.е. по сути при увеличении кол-ва мест)?

sfoid Feb 10 2011 at 13:30

При увеличении количества игроков, количество мест не обязательно возрастет. Если у всех этих новых игроков будет одинаковое количество очков (например, 0), то и место у них будет одно. Кроме того, скажем, возможно максимальное прибавление +25 очков, тогда и мест будет пересчитываться максимум 25.

qmax Feb 12 2011 at 14:17

не обязательно по крону.
можно просто ставить задачу в очередь.

Pozadi Feb 10 2011 at 12:46

И всетаки, интересно было бы увидеть нагрузку при самом простом решении, которое сразу было отброшено («налету»).

sfoid Feb 10 2011 at 13:35

Проблема не столько в нагрузке, сколько «тяжеловесности» страницы с такой операцией. Эта страница будет тормозить, периодически вылетать по таймауту. В целом на нагрузку сервера это может особо не влиять, но пользователь будет ощущать «тяжесть» открываемой страницы.

Pozadi Feb 10 2011 at 14:30

Я это и имел ввиду.
Просто в вопросах оптимизации иногда вещи, которые на первый взгляд выглядят так, будто будут томозить, на практике особо не тормозят.
Первое правило оптимизации: «Не оптимизируй!» (заранее)

samlabs821 Feb 10 2011 at 13:11

Вы должны были быть готовы к нагрузке указывая ссылку на хабре. Или это еще один метод протестировать нагрузку?

mr47 Feb 10 2011 at 13:35

Можно еще снизить нагрузку, вы не показали главное как вы выводите точнее чем, и где memcache?

Mecid Feb 10 2011 at 13:40

видно автору не знакомо понятие write behind cache

sfoid Feb 10 2011 at 13:57

memcache используется для распределения пересчета рейтинга. Как уже отметили, это называется write behind cache — данные помещаются сначала в memcache, затем другим запросом записываются в Data Storage. Алгоритм этот уже много где описан, и я не вижу смысла загромождать основной смысл статьи деталями.
Кроме memcache я также не описал, как использовал task queues и deferred API.

mr47 Feb 10 2011 at 15:08

У меня вот вопрос, а чем вам платформа «Вконтакте» (всеми гарячо любимого) не понравилась? Сразу все лезут на App Engine.

mr47 Feb 10 2011 at 15:15

В деталях весь сок. Как например в этом топике habrahabr.ru/blogs/crazydev/113446/

Mecid Feb 10 2011 at 13:39

в GAE нет таблиц.
пишите нормальный код и все будет работать, а то привыкли вместо оптимизации кода сервера добавлять.

igrishaev Feb 10 2011 at 13:49

Я, конечно, против того, чтобы писать кривой код, но почему бы вам не включить на всякий случай биллинг? Квоты резко повысятся. А порог биллинга поставьте минимальный — 1 доллар в день. Так вы и на деньги не попадете, и квоты поднимите, и не откажете посетителям, которые зашли в критический момент.

sfoid Feb 10 2011 at 14:00

Биллинг включен, на скриншотах можно видеть полосочку, обозначенную Free Quota — до нее — это бесплатная квота, после нее — оплаченная.

VovixLDR Feb 10 2011 at 15:21

Если эта Галецкая реально существует, она сейчас будет массово зафренжена, зафлужена и заспамлена.

sfoid Feb 10 2011 at 15:29

Вы переоцениваете хабр :)

TipTop Feb 10 2011 at 15:22

Просто интересно — Вы всегда сырой код испытываете в production даже без предварительных расчётов?

sfoid Feb 10 2011 at 15:31

Главное правило — отсутствие глюков/багов. Если их нет, то можно в боевых условиях тестить, почему нет? :)

TipTop Feb 10 2011 at 15:47

Хотя бы потому, что он может потреблять много ресурсов :)
Чтобы проверить код на актуальных данных не в боевом режиме, достаточно отредактировать одну строку в app.yaml. Ну а дальше AppStats, логи приложения и нехитрое умножение на возможное количество выполнений кода выявили бы проблему до появления душераздирающих скриншотов.

wickedweasel Feb 20 2011 at 03:00

Редисовские sorted sets идеально справились бы с этой задачей.

sfoid Feb 20 2011 at 05:31

К сожалению, в AppEngine его нет :)