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 |
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 |
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: -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
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 |
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, -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |