¿Cuántos fragmentos en un contador fragmentado Google App Engine?

Question

Leí hoy sobre sharded counters in Google App Engine. El artículo dice que debe esperar un máximo de aproximadamente 5/actualizaciones por segundo por entidad en el almacén de datos. Pero me parece que esta solución no 'escala' a menos que tenga alguna forma de saber cuántas actualizaciones está haciendo por segundo. Por ejemplo, puede asignar 10 fragmentos, pero luego comenzará a asfixiarse con 50 actualizaciones por segundo.

Entonces, ¿cómo sabes qué tan rápido están llegando las actualizaciones, y cómo se vuelve a introducir ese número en la cantidad de fragmentos?

Supongo que junto con el contador puede mantener un registro de la actividad reciente, y si detecta un pico puede aumentar la cantidad de fragmentos. ¿Es así como se hace? Y si es así, ¿por qué no se hace en el código de muestra? (Esa última pregunta puede no ser contestada.) ¿Es una práctica más común monitorear la actividad del sitio web y actualizar los conteos de fragmentos a medida que aumenta el tráfico, en lugar de hacerlo automáticamente en el código?

Actualización: ¿Cuáles son los efectos prácticos de tener muy pocos fragmentos y ahogo? ¿Significa simplemente que el sitio web deja de responder, o es posible perder actualizaciones de contador debido a los tiempos de espera?

---

Como un aparte, this question habla de implementar contadores sin fragmentación, pero una de las respuestas implica que incluso Memcache debe ser fragmentado si el tráfico es alto. Por lo tanto, este tema de asignación y ajuste de fragmentos parece ser importante.

Answer 1

Es claramente más simple controlar manualmente la popularidad de su sitio web y aumentar la cantidad de fragmentos según sea necesario. Supongo que la mayoría de los sitios toman este enfoque. Hacerlo programáticamente no solo sería difícil, sino que parece agregar una cantidad inaceptable de sobrecarga para mantener un registro de toda la actividad reciente e intentar analizarla para ajustar dinámicamente la cantidad de fragmentos que está utilizando.

Preferiría el enfoque más simple de equivocarme un poco en el lado alto con la cantidad de fragmentos que elija.

Tiene razón acerca de las consecuencias prácticas de tener muy pocos fragmentos. Actualizar una entidad de almacenamiento de datos con mayor frecuencia que lo que inicialmente provocará que algunas solicitudes tarden mucho tiempo (mientras las escrituras lo vuelven a intentar). Si tienes suficientes de ellos se acumulan, entonces comenzarán a fallar a medida que las solicitudes expiren. Esto sin duda dará lugar a los contadores perdidos. Por el lado positivo, su página será tan lenta que los usuarios deberían comenzar a abandonar lo que debería aliviar la presión en el almacén de datos :).

Answer 2

Para abordar la última parte de su pregunta: sus valores de Memcache no requerirán fragmentación. Un único servidor de Memcache puede manejar decenas de miles de QPS de recuperaciones y actualizaciones, por lo que ninguna aplicación plausiblemente grande va a necesitar fragmentar sus claves de Memcache.

Answer 3

¿Por qué no aumentar la cantidad de fragmentos cuando comienzan a producirse excepciones?

En base a esta GAE Example:

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());    

}