Historias
Slashboxes
Comentarios

Entrevista con Alex Payne, uno de los desarrolladores de Twitter

editada por Yonderboy el 13 de Abril 2007, 16:32h   Printer-friendly   Email story
desde el dept. no-es-oro-todo-lo-que-reluce
Zheileman nos cuenta: «Alex Payne, uno de los desarrolladores del abrumadoramente exitoso Twitter, ha sido entrevistado recientemente, y el valor de dicha entrevista radica en la sinceridad con la que muestra el lado no tan "bonito" de Ruby on Rails, o como no es oro todo lo que reluce. Y es que en dicha entrevista deja patente el tremendo consumo de recursos de gran parte de las características de Rails que le han hecho famoso, y que para un site que ha crecido tanto como Twitter, han tenido que limitar e incluso eliminar por completo. Dichas características son los "mágicos" métodos find_by_* o el RJS ["Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both."] Si Rails "por si solo" ya es lento para cierto volumen de negocio, no quiero imaginarme cómo será cuando corre "contenida" en Java, mediante JRuby on Rails Continúa Zheileman en la página extendida.
«Yo, como actual desarrollador de una aplicación Rails, me tomo con cierta preocupación los avisos que otros colegas de oficio lanzan sobre la escalabilidad y rendimiento de Rails, y ya he empezado a optar por reducir el uso de find_by y usar más el find_by_sql, entre otras cosas. ¿Qué opináis sobre éste tema, y sobre el rendimiento de aplicaciones web en general? ¿Qué experiencias habéis tenido? ¿Y con Java para aplicaciones web 2.0 no empresariales?»

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • ¿Soy el único?

    (Puntos:3, Inspirado)
    por OeL (29351) el Viernes, 13 Abril de 2007, 16:51h (#899225)
    Tengo una duda que me corroe:

    ¿Soy el único por aquí que cree que el TWITTER es una absoluta, completa y gigantesca gilipollez, absurda e imbécil hasta el límite de la imbecilidad?

    Existen dos posibilidades:

    (1) Que desaparezca después de un tiempo efímero de gloria basada en el puro accidente del absurdo

    (2) Que continúe y sea un éxito mundial.

    El punto (2) es terrorífico y dramático: ¿Está la especie humana condenada a la estupidez?

    O sea, algo así como un 5% de personas pensantes, y un 95% descerebrados ignorantes dedicados a la intoxicación semanal como forma de diversión, y al culto al vacío-rápido-cambiar-lo-que-sea (uso de internet para poner vídeos imbéciles en el you-tube, escribir por el messenguer idioteces, y más idioteces aún por el twitter (o lo que fuere) ...

    En fin, desolador.

  • por Zheileman (10916) el Viernes, 13 Abril de 2007, 17:13h (#899236)
    ( http://jesuslaiz.com/ )
    No de si nos gusta Twitter o no...
    Yo también pienso que es un boom pasajero, y que la idea es absurda en sí misma y no mantenible en el tiempo por el usuario (éstos tienen un ciclo de vida muy corto la mayoría, se registran, lo prueban 2 dias, se cansan, y se olvidan).

    Independientemente de que nos guste o no la aplicación, la cosa iba sobre el cómo el consumo excesivo de recursos de algunos frameworks nacidos ultimamente, que en pos de la simplicidad y rapidez de codificación, sacrifican los recursos y la escalabilidad, pueden hacer que precisamente webs (aunq absurdas) como Twitter, puedan morir, literalmente, de éxito, si no escalan bien y rápido ante una crecida inmediata de usuarios/tráfico.

    Y ojo, RoR no es el único. Muchos frameworks actuales de Java por ejemplo, tienen el mismo problema.

    Supongo que hasta cierto punto, podemos poner sobre una balanza el coste de desarrollar un producto "eficiente" y "austero en recursos" en 3 meses, contra el desarrollar el mismo producto, en 1 mes, a costa de utilizar plugins, librerías, y frameworks que añaden 2 o 3 capas más a nuestro inicial producto, haciendo que ya no sea tan eficiente, ni tan austero en consumo de recursos... pero oye, fué 1 mes, y el negocio está online. La competencia hoy en día, y más en web 2.0, creo que es lo que está creando.

    La idea debe ser plasmada aquí y ahora, que sino mañana la competencia lo habrá creado y ellos se llevarán el gato al agua.
    DESPUÉS de sacar el producto al mercado, suele venir la optimización de éste y el lidiar con el escalado, si dicho producto tiene éxito, obviamente.
    Sino, a morir de éxito...

    Y tampoco debemos olvidar el bajo coste del hardware actualmente, que hace que resulte más rentable comprar 2 CPUs más, a poner un desarrollador a optimizar el código. Y aquí, estoy de acuerdo. En aplicaciones no críticas como web2.0 sociales que no salvarán la vida de nadie, ni la nuestra propia está en sus manos, más vale el negocio que la poesía del código.

    Salu2.
    --
    The sky above the port was the color of a television, tuned to a dead channel.
  • Otra vez con los mitos de Java

    (Puntos:2, Informativo)
    por poiu (7606) el Viernes, 13 Abril de 2007, 18:04h (#899249)
    ( http://www.microsoft.com/ | Última bitácora: Domingo, 06 Enero de 2008, 21:35h )

    Si Rails "por si solo" ya es lento para cierto volumen de negocio, no quiero imaginarme cómo será cuando corre "contenida" en Java, mediante JRuby on Rails.»


    Hay más de 100 lenguajes que pueden compilarse contra la JVM, y ruby es uno de ellos en su encarnación JRuby.

    Según los creadores de JRuby, una de las ventajas que tiene es conseguir que Ruby pueda funcionar más rápido. Así que ahí lo teneis, una posible solución a todos estos lenguajes interpretados es compilarlos contra la JVM para que sean más rápidos.

    Ya se que hoy día no se dice compilados/interpretados,sé que se usa otro vocabulario, pero yo llevo ya unos años y en mi epoca se decia así. No tengo ganas de buscar el termino para que algunos no os echeis encima diciendo que todos son interpretados. Espero que el resto sepa apreciar la diferencia.
    --

    No infectéis vuestra mente debatiéndoos por lo extraño de este negocio.
  • ruby2

    (Puntos:1, Informativo)
    por pobrecito hablador el Viernes, 13 Abril de 2007, 18:22h (#899253)
    Rails es suficientemente rapido con el lento ruby, pero cuando ruby2 este afuera sera tremendamente rapido.

    esta es una comparativa con la version actual:
    http://www.alrond.com/en/2007/jan/25/performance-t est-of-6-leading-frameworks/

    -------
    no se si hayan tenido el gusto de probar ruby 2, pero es realmente impresionante y rapido

    para el que quiera probarlo, se puede descargar del svn, y es facil de compilar

    segun dicen, estara listo para finales de este a#o
  • Rails es lo que es y punto.

    (Puntos:2, Interesante)
    por alvarezzz (863) <{barrapunto} {at} {cientifico.net}> el Viernes, 13 Abril de 2007, 18:58h (#899263)
    ( http://www.cientifico.net/ | Última bitácora: Martes, 22 Junio de 2004, 13:46h )
    A ver...

    ¿No hay nadie serio en este barrapunto?

    Joder, ¿dónde están los profesionales que conocía aquí hace años? y permitirme que argumente.

    Cuando uno tiene que hacer un proyecto, estudia las herramientas. A la mínima que lees por ahí te enteras del nivel de abstracción y simplicidad que tiene rails, reduciendo el tiempo de desarrollo en más de la mitad. permitir que recalque: ¡ EN MÁS DE LA MITAD !. Ahora bien, quien le haya dado por pensar que esto es gratis... telita. Duros a peseta no hay (había). Vamos que esto no es ninguna novedad.

    Así que cuando la gente hable de rails, como cuando hablan de cualquier otra cosa... que no se dejen llevar por el afan sensacionalista, que es de cajón que rails consume recursos e incluso está documentado desde hace tiempo. Me parece bien la entrevista, pero...

    Tio, si no sabes en que coño programas...

    DE QUE COÑO OS QUEJAIS

    Te quieres hacer tu blog en rails. Puta madre. Que sepas que lo harás cumpliendo estándares, con ajax, bonito, dinámico, facilmente modificable, pero cuando veas que tus visistas aumentan un 20% cada mes, vete pensando en cambiar.

    En la oficina. Aplicaciones rails para hacer pijaditas te puedes hacer miles, funcionales, y sabes que van ha hacer lo que tu quieres, y sabes lo que van a consumir.

    Ahora como está esta entrevista rails es malo.

    Sois igual que las marujas que criticais. Una panda de sensacionalistas. Pero bueno vosotros en ámbito friki, otros en ámbito político, otros en socidades de protección de derechos.

    Gracias por recordarme por que ya no leía los comentarios de /.
    Espero haber abierto los ojos a algún novato, y pedirle simplemente que saque sus propias conclusiones y que no se deje llevar por la masa, y por ser guay.

    Por cierto, barrapunto es el tecnológicamente peor feed rss que consulto.

    Un cordial saludo, y perdón por el calentón y las posibles ofensas causadas.
  • PAra los interesados en saber comentarios de algunos frameworks hechos en java bajo esta misma filosofía, pueden leer este post: No debería llamarse Grailshttp://www.groovy.org.es/home/story/44 Saludos..
    --
    Non nobis domine...
  • Un acrónimo

    (Puntos:2)
    por LPR (1796) el Viernes, 13 Abril de 2007, 20:58h (#899304)
    ( http://barrapunto.com/ | Última bitácora: Domingo, 11 Noviembre de 2007, 15:32h )
    XMPP [xmpp.org] y dos extensiones: XEP-0060: Publish-Subscribe [xmpp.org] y XEP-0163: Personal Eventing via Pubsub [xmpp.org]
    --

    --
    Linux is no longer a philosophy- it is a good piece of software. Use it if it fits your needs.
  • por DanielSan (10124) el Sábado, 14 Abril de 2007, 01:28h (#899348)
    ( http://www.guslibu.org/ | Última bitácora: Martes, 15 Julio de 2008, 06:25h )
    Me apuesto cualquier cosa a que el 99% de los usuarios de Ruby no tienen sitios web con millones de visitas diarias.

    La preocupación por el rendimiento es absurda. Los cambios de escalabilidad para adaptar un programa a unas necesidades particulares (como un gran volumen de información) se hacen cuando llega el momento, y no antes, porque sólo en ese caso tienes un conocimiento práctico real de cuáles son los cuellos de botella y es por tanto cuando realmente sabes qué cambios tienes que hacer.

    Mucha gente pierde el tiempo (y el dinero) haciendo a ciegas optimizaciones que luego no mejoran el rendimiento cuando las necesidades crecen (o no puede probarse), o sencillamente nunca se aprovechan de ellas porque el programa nunca en su vida alcanza una carga mayor.

    La estructura del programa para unas necesidades especiales cambia completamente, y preocuparse de antemano es una pérdida de tiempo y esfuerzo, porque los cambios que hagamos no sabremos si realmente nos van a servir.
  • La escalabilidad de Rails

    (Puntos:4, Informativo)
    Leí el artículo hace un par de días y me pareció que, al menos en la parte que toca a escalabilidad, está completamente equivocado, y para muestra un botón. Dice algo como que el enfoque habitual de "add more hardware" no vale porque simplemente añadir más servidores de aplicación trasladará el cuello de botella a la base de datos. Vamos a ver. En primer lugar, eso te pasará uses el lenguaje que uses y uses el framework que uses. Puede que en Rails te suceda cuando tengas (pongamos) 3 servidores de aplicación contra 1 de base de datos, y con otro framework que dé más rendimiento te baste un 2-1 o un 1-1, pero te pasará, porque no es una cuestión del lenguaje. De hecho, y esto es lo segundo, si trasladas el cuello de botella a la base de datos, _ya_ lo has resuelto a nivel de lenguaje. Ya no se trata de si Rails escala sino de si MySQL, Postgre, Oracle o lo que sea que uses escala. Que claro que escala. Replica, balancea, o haz algo que no sea quejarte.

    Se puede leer más sobre esta minipolémica absurda en http://www.loudthinking.com/arc/000608.html [loudthinking.com] (la respuesta de DHH, el creador de Rails, a la entrevista de Alex Payne) o en http://lists.simplelogica.net/pipermail/ror-es/200 7-April/007354.html [simplelogica.net] (hilo sobre el asunto en la lista de ror-es).

    Rails es lento. Como ya han dicho, el que pensase que todo lo "chulo" de Ruby y de Rails era "gratis" pecaba de ingenuo. Pero sí escala. El propio Twitter o La Coctelera [lacoctelera.com] (que es lo que más conozco) son prueba de ello. Rendimiento y escalabilidad tienen bastante poco que ver.

    Y el que un poco más arriba ha dicho que en Rails cada vez que instancias una clase ActiveRecord se hace un "SELECT * FROM table" debería leer un poco más (o no, pero entonces no opinar sobre lo que no sabe =:-P).
    --

    $ uname -a
    Linux multivac 3.4.10-5-multivac #1 Fri May 20 15:49:12 UTC 2015 mvac GNU/Linux
  • por Haroky (16038) el Sábado, 14 Abril de 2007, 16:28h (#899481)
    ( Última bitácora: Miércoles, 06 Agosto de 2008, 15:03h )
    La verdad, me extraña que se tilde de novedad algo que de Ruby se sabe des del principio. Yo creo que como todas las cosas nuevas hacen ilusión y mueven las masas hasta que se les ve el rabo. Aunque el rabo siempre haya estado ahí pero nadie quería verlo.

    Hay muchos benchmarks [dada.perl.it] en los cuales puede verse que Ruby es uno de los lenguajes más lentos, incluso si sólo hablamos de los lenguajes interpretados. Uno de los motivos por los que descarté Ruby des de un principio era precisamente esto y me quedé con PHP (y sólo por la flexibilidad que me ofrecía el ser interpretado y estar especializado en la web). Si ya con PHP tuve tentaciones de pasarme al semicompilado Java, por su filosofía y su mejor rendimiento para proyectos medios, imagináos con Ruby.

    Y lo de Ruby montado en Java es sin duda una de sus mejores esperanzas. Como también lo sería un intérprete en PHP que quedase instanciado en memoria y sirviese páginas PHP generando hilos de ejecución más ligeros, sin duda. Pero bueno, de momento está demostrando ser una elección muy válida de la que estoy orgulloso.

    Almenos han desaparecido las querellas Ruby - PHP de antaño en barrapunto, en las que ser de Ruby era "guai" y todo eran logros... hay que conocer con lo que se trabaja chicos. Si lo de "guai" de Ruby es su filosofía en la programación (yo creo que esa es su brillantez), porqué no os quedáis con Smalltalk? Ah claro! Que es un lenguaje demasiado pasado de moda y aburrido...claro. ¿Nos pasamos cuando venga la moda de lo retro en programación? ¿O por la semana fantástica del Corte Inglés?

    Bueno, perdonad. Sin acritud. Es que tanto bombo y platillo hasta ahora me ha tocado la moral.

    Un abrazo a todos
  • 2 respuestas por debajo de tu umbral de lectura actual.