Сколько черепков в счетчике черепка Google App Engine?
Я читал сегодня о счетчиках черепка в Google App Engine. В статье говорится, что необходимо ожидать истратить приблизительно в 5/обновлениях в секунду на объект в хранилище данных. Но мне кажется, что это решение не 'масштабируется', если у Вас нет некоторого способа знать, сколько обновлений Вы делаете в секунду. Например, Вы можете выделить 10 черепков, но затем начнете дросселировать при 50 обновлениях в секунду.
Таким образом, как Вы знаете, как быстро обновления происходят, и как Вы подаете то число назад в количество черепков?
Мое предположение - то, что наряду со счетчиком Вы могли вести некоторый учет недавнего действия, и если Вы обнаруживаете скачок, можно увеличить число черепков. Это обычно, как это сделано? И разве если так, почему это не сделано в примере кода? (Что последний вопрос может быть не имеющим ответа.) Это более обычная практика для контроля количеств черепка действия и обновления веб-сайта, когда трафик повышается, в противоположность выполнению его автоматически в коде?
Обновление: Каковы практические эффекты последствий наличия очень небольшого числа черепков и дросселирования? Это просто означает, что веб-сайт становится безразличным, или действительно ли возможно потерять встречные обновления из-за тайм-аутов?
Как в стороне, этот вопрос переговоры о реализации счетчиков без sharding, но одного из ответов подразумевает, что даже кэш-память должна быть черепком, если трафик интенсивен. Таким образом, эта проблема выделения черепка и настройки, кажется, важна.
2 ответа
Очевидно, что проще вручную отслеживать популярность вашего сайта и увеличивать количество шардов по мере необходимости. Я бы предположил, что большинство сайтов используют именно такой подход. Делать это программно было бы не только сложно, но и, похоже, неприемлемо накладно - вести учет всей недавней активности и пытаться анализировать ее, чтобы динамически регулировать количество используемых шардов.
Я бы предпочел более простой подход - просто немного завышать количество осколков, которые вы выбираете.
Вы правы в отношении практических последствий использования слишком малого количества шардов. Обновление сущности хранилища данных чаще, чем это возможно, что вначале приведет к тому, что некоторые запросы будут выполняться долго (пока запись будет повторяться). Если их накопится достаточно много, то они начнут выходить из строя по мере того, как запросы будут завершаться. Это, конечно, приведет к пропуску счетчиков. С другой стороны, ваша страница будет настолько медленной, что пользователи начнут уходить, что снизит нагрузку на хранилище данных :).
Чтобы ответить на последнюю часть вашего вопроса: значения вашего кэша памяти не требуют сегментирования. Один сервер кэша памяти может обрабатывать десятки тысяч запросов в секунду выборки и обновлений, поэтому ни одному достаточно большому приложению не потребуется сегментировать ключи кэша памяти.