Hola: Si, nosotros tenemos un log de SQL, pero podes poner un Log de request o lo que sea, siempre visible en desarollo porque a veces no te das cuenta y en un do: te fuiste a los caños.
Saludos GallegO El día 27 de abril de 2011 14:54, [email protected] <[email protected]> escribió: > Hola, > Si detallas un poco mas ese tool que usan tal vez puedan surgir mas > respuestas. Pasar de LAN a WAN en muchos esquemas de persistencia > suele ser traumático y la latencia es el mayor problema siempre. La > solución mas común y tradicional es que las cosas se ejecuten en > server usando proxies y no muevas muchas cosas al cliente, pero suele > no ser posible. En mi caso, usando persistencia a una base relacional, > terminé por trasladar ciertos procesos en el server y otros en el > cliente. Eso que le llamás mini-request, son mensajes y hay que tratar > de evitarlos. > Algo que me sirvió en su momento fue debuguear el sistema con una > latencia ficticia, esto lo hice simplemente metiendo un retardo en un > método (el que justamente buscaba en la base); y luego a partir de ahi > entontrar los verdaderos cuellos de botella del sistema. En mi caso el > sistema estaba muy factorizado (porque era viejo), y por eso los > puntos problemáticos eran pocos y los arreglé con redundancias y otras > chanchadas. Casi siempre el tema pasa por preguntarle poco a la base y > traer mucho en cada mensaje. Por ejemplo, si tenés que traer una > colección de 1000 clientes y a cada uno le preguntas su Domicilio, y a > cada Domicilio le preguntás su Cuidad, tendrás 1 + 2000 consultas, que > en una latencia de WAN de unos 200ms da mas de 6 minutos. Pero si te > traes y cacheas a todas las ciudades, luego los domicilios y luego los > clientes, son 3 consultas (0.6 segundos!). > > Saludos, > Diego > > On 27 abr, 12:12, German Morales <[email protected]> wrote: >> Hola, >> >> Me auto-contesto con la (probable) solucion: >> Diego Gomez Deck ya habia hecho algo al respecto en su ST2JS. Y me explicó >> que hace una especie de paquete multi-mensaje (dependiendo de una >> clasificacion de methods que reconoce como synchronos o asynchronos) para >> ahorrar llamadas. >> >> De todas formas, pregunte en el support del producto, y me aclararon que en >> realidad el problema es distinto. >> No se trata de mensajes a objetos remotos, sino de un traversal de objetos >> que van haciendo (los objetos se van cargando/copiando localmente, quedan en >> un cache local), y que se hace a medida que necesitan, es decir a medida que >> cada object quiere usar otro relacionado, y que entonces va de a uno por >> uno, y esto es lo que dispara los miles de mini-requests. >> >> Y si, lo que sugieren es usar algun remote desktop, vnc, etc. >> >> Saludos, >> >> German >> >> 2011/4/26 GallegO <[email protected]> >> >> >> >> > German: >> >> > El único consejo es hacer pocos request. Las mismas herramientas de >> > desarrollo/debug web te orientan como una de las cosas más >> > importantes. Quizás puedas obtener info de todas las reglas a tener en >> > cuenta en este sitiohttp://developer.yahoo.com/yslow/ >> >> > Cómo hacer pocos request con objetos distribuidos, ni idea. Se me >> > ocurre que por ahi traer copias locales de grafos enteros de los >> > objetos sea más optimo. Quizas este todo mal hecho no? y no debería >> > ser necesario mandar mensajes por la red todo el tiempo. Fijate el >> > ejemplo que vos mencionabas de una página web. Hay cosas que hay que >> > hacerlas en el cliente y otras en el servidor, balancear bien esa >> > parte no me parece tan difícil. Ahora, si dejas todo librado a la >> > magia de la "transparencia" quizás se te compliquen las cosas. También >> > te puede pasar lo mismo en cualquier aplicación web si te zarpas de >> > ajax no?. >> >> > La verdad opino porque me interesó el thread más que nada y no te doy >> > ninguna solución, solo reflexiones. Yo también observe en otras >> > aplicaciones distribuidas (en Smalltalk) esos mismos problemas que >> > mencionas. >> >> > Mientras, si es posible quizas puedan utilizar Citrix o algun RDP con >> > la aplicación, no se si en el caso de Uds. es admisible >> >> > Snif... jeje >> >> > Saludos >> > GallegO >> >> > El día 26 de abril de 2011 10:11, German Morales >> > <[email protected]> escribió: >> > > Hola! >> >> > > Ya muchas veces se hablo del tema de objetos distribuidos, pero no >> > recuerdo >> > > comentarios con respecto a dependencia de redes lentas, en especial de >> > mala >> > > "latencia". >> > > El tema viene asi: en donde trabajo estamos usando un tool (comprado, no >> > > tenemos fuentes ni nada), que esta hecho (investigando un poco los >> > > internals...) con VisualWorks. >> > > El programa usa un server que, en nuestro caso, esta en Europa, mientras >> > que >> > > el cliente intenta accederlo desde Argentina. >> > > Si bien tenemos un acceso de red quizas aceptable para otros usos, en el >> > > caso de este tool es totalmente inusable. >> >> > > Con "otros usos", me refiero a programas que estan pensados para ser >> > > distribuidos en redes lentas. Por ej una pagina web: el contenido baja en >> > > pocas llamadas al server (una para el HTML, mas para CSSs, images, etc.). >> > > Luego hay una pausa o interaccion de usuario (nada de trafico), y luego >> > > otros pocos pedidos "de a bloques grandes", y asi. En resumen, pocos >> > > requests grandes. >> >> > > Por el contrario, los objetos distribuidos (al menos como parece que los >> > usa >> > > este tool) tienden a mandar un request por cada envio de mensaje. Es >> > decir: >> > > miles de mini-requests. Y esto es lentiiiiiisimo cuando el problema no es >> > el >> > > server sino la latencia de la red. >> >> > > De metido nomas, quiero sugerirle a los autores del tool ideas para que >> > su >> > > aplicacion ande bien (me dejan mal parado a mi querido Smalltalk... :-( ) >> > > (ideas que podrian ser ignoradas, es mas bien una curiosidad mia). >> > > El tema seria, si se puede aplicar algun "clever refactor", de forma que >> > > ande rapido en redes lentas sin escribir la aplicacion de nuevo. >> >> > > Saludos! >> >> > > German >> >> > > -- >> > > To post to this group, send email to [email protected] >> > > To unsubscribe from this group, send email to >> > > [email protected] >> >> > >http://www.clubSmalltalk.org >> >> > -- >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> >> >http://www.clubSmalltalk.org- Ocultar texto de la cita - >> >> - Mostrar texto de la cita - > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
