Mi idioma de elección es Ruby, pero sé por Twitter que Ruby no puede manejar una gran cantidad de solicitudes. ¿Es una buena idea usarlo para el desarrollo de socket? o ¿Debería usar un lenguaje funcional como erlang, haskell o scala, como hicieron los desarrolladores de Twitter?¿Es una buena idea usar ruby para la programación de socket?
La empresa para la que trabajo usa Ruby para nuestro sitio web. Hasta ahora hemos manejado un poco más de 34,000,000,000 de visitas. No tenemos problemas manejando alrededor de 10,000,000 visitas por día. Los éxitos máximos han superado los 40,000,000 de aciertos por día.
La escalabilidad depende de muchos factores. Nuestras bases de datos hacen un porcentaje desproporcionadamente alto de escrituras en comparación con las lecturas, por ejemplo. Si bien la mayoría de los sitios web hacen aproximadamente el 90% de las lecturas al 10%, estamos más cerca del 50% -50%. Mi punto es que la escalabilidad se ve afectada por muchos factores. Si tiene una base de datos limitada, como suele ser el caso de las aplicaciones web, no importará qué idioma use, lo estará esperando en su base de datos.
Hay mucho en qué pensar si está tratando de manejar grandes escalas. Sharding bases de datos, memcached, etc. etc. etc. etc. El lenguaje que utiliza para su aplicación es solo un aspecto, y a menudo, aunque no siempre, un pequeño aspecto de la escalabilidad.
Ruby puede ser una buena opción para ti, pero hay mucho que me gusta en otros idiomas. Erlang se esfuerza por facilitar la recuperación de errores, por ejemplo.
Si el rubí es tu idioma favorito, sí, es una buena idea. Siempre es mejor usar lo que sabe y lo que le gusta
¿por qué downvoting? explique – luc
La clave es tener una biblioteca de bajo nivel en C/C++ que haga multiplexación de socket por usted. La multiplexación de socket es lo que hace que un servidor TCP procese verdaderamente multiusuario. tales bibliotecas en C (que es lo que quieres) podrían ser libevent/libev ... y en C++ boost :: asio. Python se ha retorcido y lo hace detrás de escena.
Si obtiene una biblioteca de este tipo y la usa en ruby, debería poder implementar la mayoría de los programas de socket bastante bien. Esto es especialmente cierto en los campos UNIX que favorecen los procesos múltiples a los multi-threading.
twisted no hace ninguna de las cosas que afirma que hace, utiliza conectores simples de python, simplemente hace todo en un hilo, que con procesadores multi-core la norma NO es el camino a seguir actualmente. Lea también este artículo acerca de cómo ASIO no es el camino a seguir tampoco. http://www.metabrew.com/article/rewriting-playdar-c-to-erlang-massive-savings/ –
La multiplexación de socket a menudo requiere estructuras de datos especiales en el servidor. Esto a menudo se vuelve a implementar una y otra vez para cada servidor. Estas estructuras de datos tienden a ser prio-colas (montón), árboles rojo-negro y listas vinculadas. Si twisted no se basa en una biblioteca de bajo nivel, tiene que usar la tabla hash predeterminada de python para implementar el código de espacio de usuario para la multiplexación de socket sin bloqueo. Respondió a mi publicación de bajo nivel con su visión ingenua de alto nivel de las cosas. El artículo que ha citado no habla de cómo Erlang y ASIO implementan el plexo de socket, por lo tanto, está completamente fuera del tema. –
Mientras que puede obtener un mejor rendimiento de un lenguaje funcional como Erlang, la idoneidad de Ruby dependerá realmente de lo que intente lograr. Por ejemplo, cuántas solicitudes va a manejar es, probablemente, la primera pregunta, si los beneficios de rendimiento de usar Erlang no hacen mucha diferencia, use algo con lo que se sienta cómodo, ¿por qué aprender un nuevo idioma si no es necesario?
No estoy seguro de que las "lecciones" que el equipo de Twitter haya aprendido sobre Ruby (más específicamente, Rails) y la escala se apliquen a su proyecto. Están buscando MUCHO más tráfico de lo que la mayoría de la gente razonablemente puede esperar ver.
En cuanto a los enchufes y Ruby, echa un vistazo a I like Unicorn because it's Unix. Es una lectura bastante interesante sobre hacer tomas en Ruby.
+1 para el enlace interesante al artículo de unicornio. Gracias por eso. – ChrisInEdmonton
@Chris: si te gusta ese artículo, mira esta lista de seguimientos - http://jacobian.org/writing/star-is-unix/ – Telemachus
Al menos tiene la opción de quedarse en su idioma de alto nivel favorito si usa un lenguaje rápido y simultáneo como Haskell, Erlang o Scala. Con Ruby, los cuellos de botella de rendimiento significarán cambiar a C compilado (o Haskell, o ...) para la velocidad de todos modos.
Ruby tiene la ventaja de tener marcos de frontend buenos.
Me gustaría proporcionar un poco de contexto primero. Soy bastante activo con la comunidad de Scala, y I elegiría Scala sobre Ruby para cualquier proyecto.
Por lo tanto, una vez dicho esto, mantente con Ruby a menos que en realidad golpees la barrera. Si Ruby es el idioma que eliges, es posible que nunca seas feliz con las opciones que mencionas, especialmente las que están tipadas estáticamente.
Podría ser bueno aprender un nuevo idioma, tener algo a lo que recurrir si necesita una alternativa. En tu caso, recomendaría Clojure o Erlang. Scala es un buen lenguaje de OO estáticamente estátizado con ventajas de programación funcional. Podría ser más fácil aprender que los demás, pero las personas que realmente les gusta la escritura dinámica no se convierten fácilmente en tipeo estático.
En cuanto a Haskell, es uno de los idiomas más increíbles (y mucho más compatible y popular que las alternativas igualmente increíbles), y puede abrir su mente como ninguna otra cosa. También es difícil de dominar.
También he usado Ruby para muchos proyectos, aunque recientemente me mudé a Scala y me gusta bastante. Una cosa de la que he escuchado cosas buenas (pero nunca lo intenté) sobre cuestiones de red en Ruby es EventMachine. Utiliza el Patrón de Reactor como retorcido y parece bastante sólido.
Habiendo escrito recientemente (en realidad sigue haciéndolo ahora), un proyecto que usa conectores con Ruby y Java, diría que no. La implementación de ruby socket está mal documentada a menos que planee escribir un servidor de chat de bloqueo básico. Encontré que escribir en C o Java era más simple, Ruby envuelve las conexiones nativas y te queda un poco preguntándote cómo demonios usarlo ahora. Anteriormente escribí un montón de código de socket en Windows, Linux y otras plataformas en C, con menos estrés.
Mi código de Ruby ahora es muy pequeño y funciona bien, llegar a ese punto fue un verdadero dolor.
¿Tienes un Github Repo en la programación del socket? Si lo haces, por favor, házmelo saber. Estoy buscando desarrollar aplicaciones de chat. Gracias – TheMouseMan
"Sé por Twitter que Ruby no puede manejar una gran cantidad de solicitudes". Probablemente no deba tomar decisiones tecnológicas en función de la situación específica de una empresa extremadamente atípica. –
Hmm. ¿No deberías saber por Twitter que Ruby * puede * manejar una gran cantidad de solicitudes? Twitter es uno de los sitios web más populares en internet (# 14 según Alexa). Cualquier problema de escalabilidad que tenga probablemente sea mucho más allá de lo que experimentará, y ocurrirá sin importar el lenguaje y el marco que use. El hecho de que Twitter haya aumentado tanto y tan rápido dice que están haciendo bien las cosas, incluso si a veces tienen algunos problemas. –
¿Realmente desea escribir código en el nivel de socket, o simplemente usar una biblioteca/marco que hace uso de sockets? – Jim