это еще одна ошибка тайм-аута.

астое исключение, которое я получаю в журнале своего приложения ежедневно, обычно 5/6 раз в день с трафиком в 1 000 посещений в день:

db error trying to store stats
Traceback (most recent call last):
  File "/base/data/home/apps/stackprinter/1b.347728306076327132/app/utility/worker.py", line 36, in deferred_store_print_statistics
    dbcounter.increment()
  File "/base/data/home/apps/stackprinter/1b.347728306076327132/app/db/counter.py", line 28, in increment
    db.run_in_transaction(txn)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 1981, in RunInTransaction
    DEFAULT_TRANSACTION_RETRIES, function, *args, **kwargs)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2067, in RunInTransactionCustomRetries
    ok, result = _DoOneTry(new_connection, function, args, kwargs)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2105, in _DoOneTry
    if new_connection.commit():
  File "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 1585, in commit
    return rpc.get_result()
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 530, in get_result
    return self.__get_result_hook(self)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 1613, in __commit_hook
    raise _ToDatastoreError(err)
Timeout: The datastore operation timed out, or the data was temporarily unavailable.

Функция, которая вызывает исключение выше, является следующей:

def store_printed_question(question_id, service, title):
    def _store_TX():
        entity = Question.get_by_key_name(key_names = '%s_%s' % \
                                         (question_id, service ) )
        if entity:
            entity.counter = entity.counter + 1                
            entity.put()
        else:
            Question(key_name = '%s_%s' % (question_id, service ),\ 
                          question_id ,\
                          service,\ 
                          title,\ 
                          counter = 1).put()
    db.run_in_transaction(_store_TX)

В основном,store_printed_question Функция проверяет, печатался ли данный вопрос ранее, увеличивая в этом случае соответствующий счетчик в одной транзакции.
Эта функция добавленаWebHandler котсроченный рабочий, использующий предопределенныйпо умолчанию очередь, которая, как вы, возможно, знаете, имеет пропускную способность пяти вызовов задач в секунду.

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

Этот счетчик, который я храню, не так важен, поэтому я не беспокоюсь о получении этих таймаутов; в любом случае мне любопытно, почему Google App Engine не может правильно справиться с этой задачей даже с низкой скоростью, например, 5 задач в секунду, и если снижение скорости может быть возможным решением.
A счетчик на каждый вопрос, чтобы избежать тайм-аутов было бы излишним для меня.

РЕДАКТИРОВАТЬ:
Я установил ограничение скорости в 1 задание в секунду в очереди по умолчанию; Я все еще получаю ту же ошибку.

 Nick Johnson20 янв. 2011 г., 13:30
Отложенные задачи в любом смысле не «легче», чем обычные, за исключением того, что их легче писать. Под капотом они реализованы с обычными обработчиками. В любом случае это не повлияет на издержки самой транзакции.

Ответы на вопрос(2)

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

 nilsmagnus02 дек. 2015 г., 11:46
Время ожидания по умолчанию для API-вызовов составляет 5 секунд. Вы можете изменить это, настроив контекст следующим образом: ctx: = appengine.Timeout (appengine.NewContext (req), 30 * time.Second)
 murrekatt21 июн. 2016 г., 11:53
appengine.Timeout в настоящее времяcontext.WithTimeout

написать утверждение, Если у вас запущена транзакция, и вы одновременно записываете кучу материала в одну и ту же группу сущностей, вы сталкиваетесь с проблемами записи (побочный эффектоптимистичный параллелизм). В большинстве случаев, если вы делаетегруппа объектов меньше, что обычно минимизирует эту проблему.

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

Другая гораздо менее вероятная возможность (упомянутая здесь только для полноты) - планшет, на котором находятся ваши данные,быть перемещенным.

 Nick Johnson20 янв. 2011 г., 13:29
@systempuntoout Вы все еще можете получить конфликт записи для отдельных объектов, если вы вносите в них более 1QPS изменений. раздорбудем вызвать исключение тайм-аута.
 systempuntoout20 янв. 2011 г., 11:24
Группа сущностей не определена, я обновляю одну модель. Конфликт записи в группе объектов обычно вызывает другой тип исключения. Как я уже писал в своем вопросе, использование счетчика в этом случае кажется излишним.
 systempuntoout20 янв. 2011 г., 14:28
@Nick yep, конфликт записи в группе сущностей вызывает ошибку «Коллизия транзакций для группы сущностей с ключом ..».
 systempuntoout20 янв. 2011 г., 20:55
Я бы добавил, что иногда по тому же методу я получаюОшибка приложения: Ошибка приложения: 5 это еще одна ошибка тайм-аута.

Ваш ответ на вопрос