Как стать автором
Обновить

Комментарии 24

Если пишите на питоное — python-geoip — отзывы неплохие. Однако учтите, что база в 1.1 метр кэшируется в памяти (память на инстанс — 100 метров).

По поводу записи в базу — да, действительно не все так просто. Батчи нужны только для ускорения, все операции после rpc выполняются последовательно. (Исключение для entity groups — там параллельно по возможности, однако надо правильно применять entity groups, иначе будут проблемы производительности). И если один объект пишется в базу 40мс, 1000 запишутся за 4 секунды. То же распростаняется и на процессорное время.

Вопрос почему столько CPU жрет — ответ: При записи объекта пишутся в параллели еще и все индексы (прямые и обратные) — т.н метаданные на каждое поле модели + индексы также занимают место на диске. Решение: Если индекс по полю не нужен, делать это поле unindexed. Но без индекса как известно не сделать запроса по полю, посему нужно правильно выбирать архитектуру модели.

Если пишите на java — для geoip нужно также закешировать эту базу, например ehcache, и работать с ней из кеша, 1.1 метр это не много. Это самое верное.
Спасибо! Буду думать :-)
Я ошибся — 1000 запишутся за 40 секунд, что превысит лимит ожидания инстанса в 30 секунд и тут же возникнет исключение TimeoutException от rpc (хранилище перед записью определяет, за сколько оно сможет последоватьно записать обьекты, если время больше фиксированного — скинет респонс с исключением). Посему лимит у батчей — 500 объектов.
Время записи еще зависит от размера объекта. По опыту сумарное время, дозволительное от хранилища — 25 сек, что соотвествует записи ~600-800 объектам с минимальными метадаными. Статистически это около 50-100-200 объектов.
Да, думать уже думал. GeoIP.dat нельзя загрузить на GAE (ограничение на размер файла 1мб)
статика — 10мб. 1мб на rpc-запросы, читайте внимательнее доки.
> Too long (max 10485760 bytes, file is 13380569 bytes)

0 не заметил :-)
Ну вобщем-то всеравно мало.
Куда ж больше-то на статику :) Можете упаковать в тот же зип, потом распаковать в память. Не проверял, однако если в 30 секунд уложитесь на все про все, скорее всего сработает.
Наслаждайтесь, уже давно существует code.google.com/p/google-file-service/

загрузка до 10мегабайт!!!
Как оказалось, надо больше 10 метров. Но вообще это поделка кривая, т.к в яве пока нет AsyncAPI. Как результат — частые таймауы и пр.
Вообще с помощью асинхронных запросов в питоне можно достать и более 10 метров в инсантс, аж до максимальных 100. Однако придется их делать 100, ибо ограничение на rpc — 1 метр. И ессно уложиться в 30 секунд надо на все про все.

Ну и сам потом responce — не более 10 метров. Вообще стоит подождать blobstore, а не ориентироваться на эту поделку.
Откуда информация, что память на инстанс 100 метров?
Ну в яве можно в переменных среды посмотреть максимально доступную память, в питоне на тестах видно. Да и сами разработчики подтвердили давно уже.
НЛО прилетело и опубликовало эту надпись здесь
ежели честно, лень по 3м гугл.группам искать, но 3 раза точно видел от nick_johnson и jason_google. Ну и вообще это видно на тесте с ehcache (по 10 метров добавляя за запрос). Подходит к 90 метрам, потом еще запрос — получаем OutOfMemory, инстанс этот умирает, при следующем запросе рождается новый. Раньше был баг, что при переполнении инстанс висел еще 5 минут, выдавая исключение, сейчас исправили и он умирает. Проверял это задавая рандомное значение в конструкторе, как только инстанс новый рождался — появлялось новое значение.
НЛО прилетело и опубликовало эту надпись здесь
А, я знаю кстати, с чем вы возможно перепутали — долго шли разговоры, сколько можно в memcache положить, и думали что предел как раз 100 метров. Однако это не так, можно теоретически и гораздо больше, однако это совсем ненадежно, и сколько в реале можно — даже сами разработчики не знают, их долго пытали в чате как-то. Т.е говорят пользуйтесь на всю катушку без всяких ограничений, однако сколько вам удасться положить и какая надежность этих данных, несмотря на установленные таймауты — мы не знаем, и совсем не гарантирем, что положив объект на 30 мин, он там столько и пролежит. Однако вероятность есть, неопределенная :)
НЛО прилетело и опубликовало эту надпись здесь
Мда, а почему бы просто не запрашивать по API готовый внешний сервис, кэшируя ответы?
Они как правило платные, с бесплатными часто гемор, тормоза и лимиты.
Что-то гложут меня смутные сомнения что на коленке сделаешь что-то более доступное чем ipinfodb.com/ip_location_api.php например.
GAE конечно даст территориальную неопределенность и все такое, но скорость конечному пользователю вряд-ли будет другая.
Дык есть задача — «Сделать определение города пользователя по IP для GAE приложения». Зачем пользоваться нестабильным интернетом внешним сервисом, когда можно своей базой. Скорость будет примерно одинаковой, зато надежность выше. Что такое «территориальную неопределенность» в контексте поставленной задачи, я так и не понял :)
s/неопределенность/распределенность/

GAE так GAE, в принципе можно продавать сервис потом таким же. :)
Лично мой город не определяет (не говорю уж о том, что у меня московский ip и другие сервисы определают Мск) 95.30.33.225
эээ
IP address: 95.30.33.225
Country: Russian Federation
State/Province: Moscow City
City: Moscow
У меня Кемерово)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации