Сколько шардов в счетчике шардов Google App Engine? - PullRequest
Новая
       12

Сколько шардов в счетчике шардов Google App Engine?

11 голосов
/ 30 июня 2010

Сегодня я прочитал о закрытых счетчиках в Google App Engine .В статье говорится, что вы должны ожидать максимальную скорость около 5 / обновлений в секунду на объект в хранилище данных.Но мне кажется, что это решение не «масштабируется», если у вас нет способа узнать, сколько обновлений вы делаете в секунду.Например, вы можете выделить 10 осколков, но затем начнете задыхаться при 50 обновлениях в секунду.

Итак, как вы узнаете, как быстро приходят обновления, и как вы вернете это число обратно в числоосколки?

Я предполагаю, что наряду со счетчиком вы можете вести учет недавней активности, а если вы обнаружите всплеск, вы можете увеличить количество осколков.Это вообще как это делается?И если так, то почему это не сделано в примере кода?(Этот последний вопрос может быть без ответа.) Является ли более распространенной практикой отслеживание активности веб-сайта и обновление количества сегментов по мере увеличения трафика, в отличие от автоматического выполнения этого в коде?

Обновление: Каковы практические последствия от слишком малого количества осколков и удушья?Означает ли это просто, что веб-сайт перестает отвечать на запросы или возможно потерять счетчик обновлений из-за тайм-аутов?

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

Ответы [ 3 ]

4 голосов
/ 30 июня 2010

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

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

3 голосов
/ 30 июня 2010

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

2 голосов
/ 25 января 2012

Почему бы не добавить количество осколков, когда начинают возникать исключения?

На основании этого GAE Пример : 

try{
  Transaction tx = ds.beginTransaction();
  // increment shard
  tx.commit();           
} catch(DatastoreFailureException e){
   // Datastore is struggling to handle the current load, increase it / double it
   addShards( getShardCount() );

} catch(DatastoreTimeoutException to){
   // Datastore is struggling to handle the current load, increase it / double it 
   addShards( getShardCount() );

} catch (ConcurrentModificationException cm){
   // Datastore is struggling to handle the current load, increase it / double it 
   addShards( getShardCount() );             

}
...