Проблемы с лимитами GAE, почему завышенны Datastore Read Operations?

Question

[rPman]

Серьезно не работал с google app engine, но понадобился хостинг максимально надежного облачного хранилища для очень простого приложения. Тем более по расчетам я должен был вполне вписываться в бесплатные лимиты (не будет никаких проблем оплатить пару баксов в месяц, больше там не получится).



Проект примитивный:

Два объекта Datastore (один корневой с 2 полями и постоянно пополняющийся список объектов с 4 полями), одна периодически запускаемая задача, в ней открывается транзакция читается корневой объект и создается один списочный элемент (данные собираются путем одного запроса к сервису fetchurl).



Так вот в течении трех часов у меня кончаются лимиты Datastore Read Operations — 100%, при этом Datastore Write Operations — 5%

appstore dashboard:



установил штатный гугловский appstats:





Не могу понять, откуда такое повышенное количество чтений, мало того, даже статистика appstat не показывает 50т запросов Next (я использую java.jdo, никаких перечислений, никакой работы с курсорами… единственное место где могло бы считаться чтение списока связанных объектов — при добавлении, в конструкторе списочного элемента стоит строка root.addItem(this) (а в корневом объекте Root это тупо метод this.items.add(item);



И тем более непонятно!!! Даже если считать, что на один запуск задачи приходится 19 чтений и 2 записи (кстати тоже непонятно, я заполняю четыре поля плюс ключевое) то за 3 часа (задача выполняется с частотой одна в 70 секунд) должно было быть утилизировано 154 запроса * 19 чтений = 2926! Откуда 50 тысяч запросов/



Какими еще средствами можно проконтролировать биллинг google. Ведь при таких расхождениях на порядок можно попасть на хорошую копеечку.



upd. Проблема с биллингом у google для datastore типа high replication, это явно не мой косяк, потому как сотня запросов на чтение для базы с двумя!!! записями это перебор, у меня даже в коде нет такого количества вызовов. Пересоздал и перезалил приложение в режиме Master/Slave (кстати теперь он помечен как Deprecated! хитрюги), теперь appstats показывает вразумительную информацию, по 1 или 2 запроса на вызов задачи, т.е. что и должно было бы быть, так же статистика в админке GAE показывает похожие цифры (завтра оценю нагрузку точнее)

Answer 1

[theli]

Если код не представляет собой страшную коммерческую тайну то по нему было бы проще сказать.

Comments

[rPman]

Да не сильно тайна… я пока его упрощаю поэтапно, хочу разобраться, где же собака порылась. Чуть чуть позже выложу пример, если не разберусь, да и если разберусь, выложу.
Просто позже я уже работал с GAE и там обычно все упиралось в записи, но никак не чтение…

Answer 2

[xSkyFoXx]

Вполне возможно, что у Вас отображатся Low-Level Operations, а у Вас в коде происходит High-Level Operation. Т.о. получается много по квотам.

Comments

[theli]

ну это так и есть. appstats показывает только количество RPC запросов а не количество элементарных операций БД (которые и учитываются для квоты)

Answer 3

[Артур]

Если я правильно понял, что вы сделали. Это элементарно, если вы пихаете список в один объект, то чтобы добавить в него что-то, Вам его сначала нужно его прочитать весь. Отсюда и столько чтений.

Comments

[rPman]

Если это так, то у меня для GAE плохие новости,… у них криворукие программисты :)

Но проблема в том, что штатный механизм контроля за количеством запросов не показывает такой запредельной нагрузки, а соотношение запросов на чтение к запускам задачи не изменяется по мере заполнения базы (список элементов не уменьшается… если бы каждый раз читался весь список, то нагрузка росла бы экспоненциально… а у меня при перезапуске (при сбросе статистики), отношение количества запросов остается таким же.

[Артур]

Просто нужен другой подход:
— использовать не список внутри объекта, а атомарные сущности.
— и эти сущности создавать указывая родителя, т.е. тот объект, что хранил когда-то список. (скорость записи будет ~1/сек)
— если consistency не нужно, то просто создавать сущности, указывая ссылку на родителя.

Тут должен быть вывод, что не программисты гугла дураки, а то что они умно сделали. И теперь, если программист будет создавать большие объекты (что трудно поддерживать в распределенных приложениях), то он отстрелит себе ногу или кошелек. :)

Answer 4

[TipTop]

AppStats показывает 1933 RPC's на 11 запросов к /tasks/test. Получается 178 чтений БД за выполнение задачи. 50к запросов в таком режиме хватает на 4 часа.

Comments

[rPman]

не, не, не… посмотрите слева… один fetchurl = один вызов задачи… тысячи запросов справа это просто сумма всех операций datastore слева.

Больше всего меня интересует даже не почему на один вызов примитивной задачи (позже выложу пример и напишу статью) делается 19 запросов на чтение и 2 запроса на запись… а почему при такой не высокой интенсивности (один запрос за 70 секунд, точнее 60+20*rand) за три часа приложение выжрало 50т. запросов по биллингу… как не считай это расхождение с прогнозом на порядок, т.е. должно было быть ~3т.