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 sitio http://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

-- 
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]

http://www.clubSmalltalk.org

Responder a