Objetos Distribuidos, pero en red lenta

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Objetos Distribuidos, pero en red lenta

German Morales-3
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

Sebastian Calvo
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
<[hidden email]> 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 [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

German Morales-3
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 <[hidden email]>
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
<[hidden email]> 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 [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

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

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

dcoronel32@gmail.com
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 <[hidden email]> 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 <[hidden email]>
>
>
>
> > 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
> > <[hidden email]> 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 [hidden email]
> > > To unsubscribe from this group, send email to
> > > [hidden email]
>
> > >http://www.clubSmalltalk.org
>
> > --
> > To post to this group, send email to [hidden email]
> > To unsubscribe from this group, send email to
> > [hidden email]
>
> >http://www.clubSmalltalk.org- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

German Morales-3
Diego,

Si, yo sugeri hacer algo de eso, y me contestaron que "en algunos casos raros pero importantes sabemos que queremos cargar todos los elementos de una collection, asi que podriamos pedir muchos objetos en un solo mensaje. Sin embargo, eso traeria solo mejoras menores, en comparacion con usar algun remote desktop".
Parece que esa (remote desktop) sera mi solucion por el momento :-S.

Gracias,

German

2011/4/27 [hidden email] <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
>
>
>
> > 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
> > <[hidden email]> 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 [hidden email]
> > > To unsubscribe from this group, send email to
> > > [hidden email]
>
> > >http://www.clubSmalltalk.org
>
> > --
> > To post to this group, send email to [hidden email]
> > To unsubscribe from this group, send email to
> > [hidden email]
>
> >http://www.clubSmalltalk.org- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

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

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

Sebastian Calvo
In reply to this post by dcoronel32@gmail.com
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, [hidden email]
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>
>>
>>
>> > 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
>> > <[hidden email]> 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 [hidden email]
>> > > To unsubscribe from this group, send email to
>> > > [hidden email]
>>
>> > >http://www.clubSmalltalk.org
>>
>> > --
>> > To post to this group, send email to [hidden email]
>> > To unsubscribe from this group, send email to
>> > [hidden email]
>>
>> >http://www.clubSmalltalk.org- Ocultar texto de la cita -
>>
>> - Mostrar texto de la cita -
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>
> http://www.clubSmalltalk.org

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

Paolo Loran
Hola Diego, no se si te interesará pero en otros lenguajes como Ruby on Rails o PHP se utiliza la paginación.
En Rails es mediante un plugin que permite paginar cualquier colección de elementos obtenidos de un modelo, consultando a través de transacciones, limitado por cierta cantidad de elementos a la BD, por ejemplo limitarla a 10 o 30 porque podria ser el maximo que vería en el navegador el usuario.
 
Ejemplos que tal vez te sirvan:
Ajax + Rails => http://dev.nozav.org/rails_ajax_table.html
Te adjunto una captura para que veas como se veria.
PHP + MySQL => http://www.cristalab.com/tutoriales/paginacion-con-php-y-mysql-c79063l/
 
Saludos.
poli

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

paginate.jpg (73K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

dcoronel32@gmail.com
In reply to this post by German Morales-3
Remote Desktop tiene sus propios problemas, para mi peores. Porque
tenés duplicada la estuctura de hard (en el server está corriendo cada
cliente) o porque tu aplicación no tiene intregración local. Yo vi
muchos productos (de mi competencia) que terminan funcionando asi,
porque casi todos se pensaron para LAN. Igualmente si no contás con
tiempo, tal vez sea lo mas apropiado.

Diego

On 27 abr, 17:18, German Morales <[hidden email]> wrote:

> Diego,
>
> Si, yo sugeri hacer algo de eso, y me contestaron que "en algunos casos
> raros pero importantes sabemos que queremos cargar todos los elementos de
> una collection, asi que podriamos pedir muchos objetos en un solo mensaje.
> Sin embargo, eso traeria solo mejoras menores, en comparacion con usar algun
> remote desktop".
> Parece que esa (remote desktop) sera mi solucion por el momento :-S.
>
> Gracias,
>
> German
>
> 2011/4/27 [hidden email] <[hidden email]>
>
>
>
> > 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 <[hidden email]> 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 <[hidden email]>
>
> > > > 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
> > > > <[hidden email]> 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 [hidden email]
> > > > > To unsubscribe from this group, send email to
> > > > > [hidden email]
>
> > > > >http://www.clubSmalltalk.org
>
> > > > --
> > > > To post to this group, send email to [hidden email]
> > > > To unsubscribe from this group, send email to
> > > > [hidden email]
>
> > > >http://www.clubSmalltalk.org-Ocultar texto de la cita -
>
> > > - Mostrar texto de la cita -
>
> > --
> > To post to this group, send email to [hidden email]
> > To unsubscribe from this group, send email to
> > [hidden email]
>
> >http://www.clubSmalltalk.org- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos, pero en red lenta

dcoronel32@gmail.com
In reply to this post by Paolo Loran
Hola,
Lo de paginar se puede hacer a muchos niveles, pero el problema acá no
es el tamaño de la colección sino la cantidad de consultas. Incluso en
esa imagen que mandás, si le subís la latencia y traes a los objetos
por demanda (como explicaba Germán), se vería muy lento, por ejemplo
podría tardarte un segundo por renglón.

Diego


On 29 abr, 13:46, Paolo Loran <[hidden email]> wrote:

> Hola Diego, no se si te interesará pero en otros lenguajes como Ruby on
> Rails o PHP se utiliza la paginación.
> En Rails es mediante un plugin que permite paginar cualquier colección de
> elementos obtenidos de un modelo, consultando a través de transacciones,
> limitado por cierta cantidad de elementos a la BD, por ejemplo limitarla a
> 10 o 30 porque podria ser el maximo que vería en el navegador el usuario.
>
> Ejemplos que tal vez te sirvan:
> Ajax + Rails =>http://dev.nozav.org/rails_ajax_table.html
> Te adjunto una captura para que veas como se veria.
> PHP + MySQL =>http://www.cristalab.com/tutoriales/paginacion-con-php-y-mysql-c79063l/
>
> Saludos.
> poli
>
>  paginate.jpg
> 72 KVerDescargar

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

http://www.clubSmalltalk.org