Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

Analizando la lentitud de las aplicaciones web

Entrada escrita por monster y editada por nettizen el Viernes, 12 Julio de 2013, 09:39h   Printer-friendly   Email story
desde el dept. no-diga-lento-diga-güeb
Vía el blog de Herb Sutter, un interesante análisis sobre por qué las aplicaciones web son lentas en general, llegando a desesperar en dispositivos móviles. Si bien el artículo tiene una extensión considerable, los temas planteados creo que son muy interesantes: desde cómo se ha vendido una falsa sensación de mejora espectacular en el rendimiento de javascript, que se vincularía mayormente a una mejora del hardware gracias a la Ley de Moore, hasta una visión demoledora de los efectos del uso de 'recolección de basura' (GC) en el rendimiento, especialmente en casos de memoria limitada, pasando por el ya clásico debate código nativo/'runtimes'. Todo ello repleto de datos, referencias y comparativas que no tienen desperdicio. Para los que no se atrevan con un texto tan largo, ahí va un 'adelanto': la diferencia de rendimiento entre el mismo código ejecutado de forma nativa en un PC o interpretado con un JIT en un dispositivo móvil puede rondar un factor de 50 (es decir, 50 veces más lento).

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Soy desarrollador

    (Puntos:1, Inspirado)
    por pobrecito hablador el Viernes, 12 Julio de 2013, 16:15h (#1342560)
    Soy desarrollador y un inmenso problema con los usuarios es que piden N mil funcionalidades. Cada vez que sale una nueva versión de un software, en los foros, revistas especializadas, blogs, hacen la misma pregunta: ¿qué nuevas funcionalidades trae? y para muchos es ¿que nuevos efectos especiales tiene? El mercado pide mas y mas funcionalidades.

    Las consecuencias son programas cada vez mas gordos, que consumen enormes cantidades de memoria, llenos de funcionalidades, efectos visuales, inseguros y lentos.

    Cuando hay escándalo por alguna vulnerabilidad entonces se arregla eso pero lo paga el desempeño. Un ejemplo: las comunicaciones deben estar cifradas para mayor seguridad, lo que muchos ignoran es que cifrar y luego descifrar toma buen tiempo para la máquina, los mensajes cifrados son mucho más largos que los mensajes sin cifrar, luego tardan más tiempo en transmitirse.

    En Velocidad + Seguridad + Facilidad de uso + Funcionalidad , usted sólo puede escoger dos para ampliar y el costo es gran detrimento de los otros dos.
    [ Responder ]
  • por monster (49083) el Jueves, 11 Julio de 2013, 12:52h (#1342481)
    ( Última bitácora: Jueves, 11 Julio de 2013, 09:30h )
    En el momento en que ambos se utilizan para ejecutar la misma aplicación, deja de ser comparar cosas diferentes, y de eso mismo se está hablando: Si tu quieres que tu aplicación web funcione bien tanto para quien la use desde un PC como desde un móvil, tienes que tener en cuenta que la diferencia de rendimiento es espectacular, primero por las diferencias en los micros y luego por la propia penalización de los JIT y la gestión automática de memoria. Piensa en cosas como Google Docs, Office 365 y compañía.

    Si te has leído el artículo, además de alguna de las múltiples referencias que tiene al respecto, habrás comprobado que la penalización de la gestión automática de memoria es real, con diferentes algoritmos puedes variar algo la curva de la penalización respecto a la memoria disponible pero nunca eliminarla, por lo que la acusación de mala implementación es infundada.

    En cualquier caso, el autor proporciona datos. Si no estás de acuerdo lo entiendo, pero si pretendes convencer al menos presenta tú también datos que respalden tu punto de vista.
  • Re:Odiosas

    (Puntos:2)
    por penabad (43736) el Viernes, 12 Julio de 2013, 10:59h (#1342535)

    Si un día hay un fallo gordo a nivel global, que Dios nos pille confesados.

    (off-topic)

    Esto me recuerda la serie Revolution, donde se "va la luz" del planeta. Uno de los protagonistas, que había tenido un Boeing propio, dijo "I used to work for a company named Google..."

    Por lo demás, de acuerdo contigo. La dependencia cada vez es mayor

  • Re:Odiosas

    (Puntos:2)
    por Lock (3731) el Viernes, 12 Julio de 2013, 12:21h (#1342541)
    ( http://barrapunto.com/ )
    Ya, pero un cliente-servidor tradicional depende de tu red local. Depende de tí que esté levantada.

    Pasaron a depender de redes locales conectadas por los antiguos canutos vpn entre redes. Dependía de los servicios de un contrato carísimo que tuvieses conexion. Y se podían experimentar caídas de un día.

    Ahora dependes directamente de tu conexion de internet a los servidores que sean. Y el servicio también puede soportar caídas importantes pero la letra pequeña va a ser dependiente de tu gasto, y normalmente no se comprueba o se contrata con el proveedor más barato que tambien suele ser el menos fiable y menos rapido para corregir problemas.

    Pero el problema es que ahora TODO necesita una conexión a internet, cuando antes sólamente algunas cosas necesitaban conexión a redes no locales.

    La diferencia es que ahora casi todos los procesos administrativos y operativos de una empresa dependen de internet. Antes solo dependían algunos procesos.

    Es como si ahora digo que si fallan los cajeros de los bancos me muero, y tu me dices que siempre hubo que sacar dinero de los bancos y que no es para tanto.

    --
    ¿¿PETER?? ¿Demostenes? Y actualmente Lockpeter
    • Re:Odiosas de Lock (Puntos:2) Viernes, 12 Julio de 2013, 14:34h
      • Re:Odiosas de Lock (Puntos:2) Lunes, 15 Julio de 2013, 11:48h
        • Re:Odiosas de Lock (Puntos:2) Martes, 16 Julio de 2013, 11:48h
        • 1 respuesta por debajo de tu umbral de lectura actual.
      • 1 respuesta por debajo de tu umbral de lectura actual.
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • Re:Odiosas

    (Puntos:1, Inspirado)
    por pobrecito hablador el Viernes, 12 Julio de 2013, 13:00h (#1342542)
    pues eso es por que no hay una gestion adecuada de las TI en tu empresa, o no lo consideran algo "vital".

    Hay tecnologia para que las aplicaciones web funcionen en "local" y luego cuando recuperen la conexión se sincronicen con el servidor, pero mas basico que todo eso, esta contratar la conexión a internet con dos o mas proveedores, con un SLA decente.
    Pero si eso no es viable economicamente, verdad que si se va la luz la gente no se lleva las manos a la cabeza? pues lo mismo.

    Por otro lado, lo de "lo haciamos todo en local" me suena a usuarios asilvestrados que hacen lo que quieren con su pc... vamos, un desastre en cuanto a seguridad, mantenimiento, y una fuente de quebraderos de cabeza increible.
    Si me dejaran, las restriciones ideales para mis usuarios en el uso del pc llegaria a atarles las manos a la espalda.
  • por pobrecito hablador el Sábado, 13 Julio de 2013, 19:56h (#1342693)
    Desde el momento en el que la gente quiere jugar a superjuegos y ver video HD en una tablet o un smartphone, todas estas cosas importan, y mucho.

    Bien, me imagino que seras desarrollador en Java o C#. Yo no tengo nada en contra de estos lenguajes. Soy de los que opinan que cada lenguaje es para lo que es. Python es el mejor compañero si eres un administrador de sistemas o un tester, C# si quieres hacer GUIs rapidos en Windows, etc.

    Bien, el problema, si te has leido el articulo, es que una tablet o smartphone tienen recursos muy limitados, y hay que mirar con mucho cuidado como los usas. Ni Java ni C# te lo va a permitir, puesto que abstraen esto para aumentar la productividad del programador.

    Hablas de que el problema no es del Garbage Collector. Me puedo equivocar, pero me parece que no sabes como funciona un garbage collector. La "basura" se queda en la memoria durante X tiempo hasta que el garbage collector, de manera no determinista, decide eliminar las referencias no usadas. Si tienes mucha basura, es memoria que estas ocupando, pero que no usas. Del mismo modo, si tienes mucha basura el garbage collector puede necesitar bastante tiempo en funcionar.

    Y no solo eso. El articulo habla de la memoria, que seguramente sea el recurso mas importante. Pero hay otros recursos que un programa utiliza como sockets, mutex, pipes, etc. Esos tambien son gestionados por el garbage collector, y la verdad, me da panico que un garbage collector deje un socket abierto, o se encarge de gestionar un mutex.

    Bien, hace poco en el trabajo se me pidio que hiciera una pequeña utilidad para nuestro testers. Hice la prueba de implementarlo en Java y en C++. En C++ consumia algo mas de 1MB de memoria, mientras que en Java se requeria unos 100MB. Ademas de eso, en C++ corria significativamente mas rapido que en Java. Mas rapido quiere decir que nuestros testers pueden realizar sus pruebas mas rapido, aumentar la productividad, y poder ser mas competitivos.
  • 4 respuestas por debajo de tu umbral de lectura actual.