xmlrpc cpu usage

[dahool]

Consume bastante CPU y lleva alrededor de 1 seg por ejecución.

Habría que analizar como optimizar esto.

No es la generación de ngram lo que jode ya que sólo se usa cuando genera el alias, no en el update. Los updates están consumiendo bastante.

[mschonaker]

Mandarlas a una task asíncrona?

[dahool]

Por lo pronto se me ocurre minimizar la cantidad de info que se pasa del entity al bean (por ejemplo, no es necesario levantar los ngrams)

[mschonaker]

Yo decía postergar la operación completa. Guardarla parcial (sin todos los ngrams) y después traerla para agregarlos, me parece que consumiría más CPU todavía.

[dahool]

Es posible, tendríamos que analizarlo. También me gustaría aprovechar los batch commits del datastore.

"The put(), get(), and delete() methods accept java.lang.Iterable Entity objects (for put()) and Key objects (for get() and delete()). This performs the action on multiple entities in a single datastore call. The batch operation groups all the entities/keys by entity group, then performs operations on each entity group in parallel.

A batch call to the datastore is faster than making separate calls for each entity because it only incurs the overhead of one service call, and, if there are multiple entity groups involved, the work for each entity group is performed on the server side in parallel."

[mschonaker]

Taba pensando que a lo mejor el xmlrpc gasta CPU buscando el player dónde agregar. A lo mejor si el plugin mandara el id (el del mismo server) encontraríamos más rápido que la búsqueda por texto. Pero capaz que no. Habría que ver...

[dahool]

No entendí a que id te referis?

Creo que habría que probar como se porta si quitamos xmlrpc del medio y enviamos los datos por REST

[mschonaker]

conteo de requests por server? porque si hay un plugin b3 fallando, podemos saber cuál es

[mschonaker]

esto me parece que está funcando bien. lo cerramos?

[dahool]

Sip, por el momento no parece generar inconvenientes.