2011-10-13 12 views
5

Estoy tratando de optimizar mi código, y me metí en un problema que no entiendo del todo. En cada página de mi aplicación web, habrá una lista de notificaciones muy similar al nuevo ticker de Facebook. Así, en cada petición, corro este código en el beggining:¿Por qué está aumentando mi RPC total?

notification_query = db.Query(Ticker, keys_only=True)\ 
    .filter('friends =',self.current_user.key().name()) 
self._notifications_future = notification_query.run() 

Entonces, ¿dónde encuentro un buen lugar, llamo a la función de media, que es:

notification_keys = [future.parent() for future in self._notifications_future] 
self._notifications = db.get_async(notification_keys) 

Finalmente me gustan todos fetch al final:

context.update({'notifications': self._notifications.get_result() }) 

Cada cosa funciona muy bien a excepción de lo siguiente: Si llamo a la función central en el final de la función de la solicitud, me sale esto:

punto Dumb

Dumb spot

y si yo lo llamo en lo que creo que es un lugar optimizado, me sale esto:

Smart Spot

Smart spot

Como se puede ver el uso de API se duplica haciendo esta "optimización". ¿Que esta pasando aqui?

Número de llamada 2, es el primer fragmento en ambos casos. El número de llamada 12 en mudo es el segundo fragmento, y el número de llamada 12 en el punto inteligente es el segundo fragmento. Este último cambio no tiene nada que ver con el problema, lo he probado.

pd: ¿Google me cobra por el tiempo que la consulta está "inactiva"?

ACTUALIZACIÓN

El problema parece ser sólo en el dev_server, cuando probé el mismo ejemplo (versión inteligente) en appspot, tengo esto:

consultas en la appspot

appspot

Aquí todo funciona como se esperaba, las cosas que se llaman con ejecutar() o get_async() no bloquee otras cosas. Como dije, el problema está solo en dev_server. Aún así, sería bueno ver que esta función funciona en localhost, para un perfil más efectivo.

Respuesta

1

Ahhhh. Es muy útil cuando publicas sobre el motor de aplicaciones para mencionar si tus resultados están en el servidor de desarrollo o en producción. El servidor de desarrollo no tiene las mismas características de rendimiento que los servidores de producción, por lo que no es la mejor manera de perfilar su aplicación. De hecho, creo que los índices no se usan en absoluto, y que el servidor de desarrollo tiene un único hilo, por lo que no puede manejar las solicitudes concurrentes con él. De hecho, si su aplicación hace llamadas a sí misma, it won't work at all!

+0

código y aprende, ¿verdad? – fceruti

+2

hmmm. para mí, creo que la secuencia es algo así como código, luego código un poco más, luego maldición, luego golpear mi cabeza contra la pared, luego depurar, luego codificar un poco más, luego aprender un poco :) –

3

Además de la nota de Peter, debe tener en cuenta que Appstats no tiene forma de saber cuándo se completa realmente una solicitud asíncrona, excepto cuando obtiene el resultado. Como resultado, incluso las llamadas rápidas se verán lentas si tarda mucho tiempo en solicitar el resultado.

+0

buena observación. ¡Gracias! – fceruti

Cuestiones relacionadas