2009-05-30 12 views

Respuesta

12

Por supuesto que hay una diferencia, al igual que hay una diferencia de rendimiento entre Java y .Net. Sin embargo, va a variar ampliamente en función de lo que está haciendo la aplicación.

Hay cosas donde .Net es mucho más rápido que Mono. Hay cosas donde Mono es mucho más rápido que .Net. Hay cosas en las que funcionan aproximadamente iguales. Lo mismo ocurre cuando se comparan aplicaciones que se ejecutan en Windows o Linux. Lo mismo ocurre cuando se comparan aplicaciones que se ejecutan en IIS y Apache.

Probablemente, cualquiera puede ejecutar su aplicación lo suficientemente rápido, y verá que su rendimiento se verá impulsado por sus técnicas de programación. La diferencia de unas pocas solicitudes por segundo probablemente no sea un gran problema a menos que tenga una granja de servidores grande, en cuyo caso es muy probable que tenga los recursos para probar ambas y ver cuál es más rápida para su aplicación en particular.

+8

¿Puede dar todas las referencias o ejemplos de cosas que son más rápido/más lento? –

+0

Se informó que las operaciones de cadena eran de 5 a 10 veces más lentas en Mono: http://stackoverflow.com/questions/4755707/c-sharp-code-runs-quick-on-iis-but-slow-on-mono-how- to-improvement-it – Glenn

2

Mono chupa!

O más políticamente correcto: Mono todavía no está listo para el prime time al menos para ASP.NET aplicaciones web:

  • No hay soporte de almacenamiento en caché
  • El rendimiento es terriblemente inestable y cae después del inicio de la aplicación.

EDIT: Presupuestos agregados para mi publicación, respuesta al último comentario.

Sin embargo, para hacer una comparación justa ... Debo habilitar el almacenamiento en caché ... la adición de la siguiente línea en el encabezado del archivo aspx debería ayudarme.

<%@ OutputCache Duration="20" VaryByParam="None" %> 

Lo he hecho - no hay resultado! El rendimiento es el mismo.

Nota: después de una verificación más profunda, la implementación de la memoria caché en modo es muy limitada y deficiente, después de las comprobaciones recientes aún se mantiene en las versiones más nuevas de mono.

Ok, de todos modos lo hice algunos puntos de referencia (...) simple reloj me da alrededor de 750 páginas por segundo para la variante en caché y 650 para un no en caché. Las pruebas se realizaron bajo IIS 5.0 de doble núcleo Pentium D 3G

El mismo código ... con mod_mono (bajo Signle núcleo AMD Athlon 3000) me había dado:

  • 350 páginas por segundo.
  • La siguiente ejecución dio 300.
  • 200 siguientes
  • y al lado 150

Por lo tanto, la evaluación comparativa es imposible.

¿La referencia a la publicación aún no es aumentativa?

No mono definitivamente no está listo para el horario de máxima audiencia.

+2

Sería interesante que alguien vuelva a intentar esto en una versión más reciente de Mono. Se han dedicado muchos esfuerzos para mejorar el rendimiento y la estabilidad de Mono en los últimos tres lanzamientos, particularmente 2.4. Si el problema aún existe, sería bueno que alguien presente un error para que se solucione. – jpobst

+6

Su publicación contiene información interesante, pero se considerará como "downvoted" y no se tendrá en cuenta si usa lenguaje incendiario o argumentativo en ALLCAPS con múltiples signos de admiración. – Cheeso

+0

Puedo confirmar que Mono ahora es estable. He estado ejecutando un sitio Mono por más de un año, y con Mono 2.4 ya no tengo * ningún * problema de estabilidad. – rusvdw

0

En primer lugar, se dijo que publicar estadísticas de rendimiento para comparar implementaciones CLR (.NET vs Mono) no es posible. No estoy seguro de cuál es la fuente, pero el equipo Mono solo publicó la comparación entre las versiones Mono (1.x, 2.0, 2.2 y 2.4), así que asumo que el dicho es real. Por lo tanto, solo puede probar el rendimiento en su propio entorno.

En segundo lugar, Mono está evolucionando mucho más rápido últimamente, lo que le da la oportunidad de aumentar su rendimiento simplemente actualizando Mono runtime.

En tercer lugar, utilice una actitud diferente para juzgar un producto de código abierto. Para los productos de código cerrado, no puede hacer nada más que pedirle a su proveedor que mejore el rendimiento o que brinde su apoyo sobre cómo ajustar sus aplicaciones. Para los proyectos de código abierto, tiene acceso a la base de códigos y puede adaptarla a sus necesidades y solucionar los problemas de sus propias aplicaciones.

Como mencionó jpobst, incluso si no puede solucionar los problemas usted mismo, puede ponerse en contacto con los chicos de Mono.

+0

Usted escribió, "se dijo que publicar estadísticas de rendimiento para comparar CLR no es posible". Y "supongo que el dicho es real". Sin fuente, ¿por qué asumir? ¿Por qué no simplemente le pides a los tipos Mono que publiquen una comparación, y si no lo hacen, por qué no? Sé por qué Microsoft no publicará, no hay nada que ganar. Si ganan la comparación de perf, ¿y qué? Ellos * deberían * ganar. Si pierden, wow, cosas malas. – Cheeso

+0

Otra investigación muestra la fuente, http://www-sop.inria.fr/members/Manuel.Serrano/publi/jot04/jot04.html#footnote-footnote1888, puede consultar las últimas líneas. –

1

He ejecutado aplicaciones mono en mod_mono. Desde una usabilidad, funciona bien, aunque no hice ningún punto de referencia. Todavía IIS es realmente un entorno increíblemente conveniente en el que trabajar. Dada la opción, todavía alojaría mi servidor web en IIS y usaría clientes mono de Linux para conectarme a él.

6

Con respecto a la sugerencia de lextm de que publicar los resultados de las comparaciones de perf es "imposible", el End-User License Agreement (aka EULA) for Windows Vista Ultimate lo permite, con condiciones.

MICROSOFT .NET BENCHMARK TESTING. El software incluye uno o más componentes de .NET Framework 3.0 ("Componentes .NET"). Puede realizar pruebas internas de referencia de esos componentes . Puede divulgar los resultados de cualquier prueba comparativa de esos componentes , siempre que cumpla con con las condiciones establecidas en http://go.microsoft.com/fwlink/?LinkID=66406. Sin perjuicio de cualquier otro acuerdo que pueda tener con Microsoft, si publica dichos resultados de pruebas comparativas, Microsoft tendrá derecho a revelar los resultados de pruebas comparativas que realice de sus productos que compiten con el .NET aplicable Componente, siempre que cumpla con las mismas condiciones establecidas en http://go.microsoft.com/fwlink/?LinkID=66406.

Las condiciones, como los leo, son obligaciones de información razonables: el código fuente que utilizó para hacer la prueba, las versiones de software que prueba, la fecha en que realizó los ensayos, la configuración y optimizaciones que ha realizado, etc.

The EULA for Windows Server 2003 incluye las mismas disposiciones. No pude encontrar el EULA para Windows Server 2008 (la última versión), pero asumo que las disposiciones de evaluación comparativa permanecen.

Addendum: Si busca en el EULA para Windows7, probablemente encontrará una cláusula de no evaluación comparativa, o más exactamente una cláusula de no publicación; esto se debe a que Win7 todavía está en prelanzamiento. Cuando se lance oficialmente, se espera que estén presentes las condiciones estándares de publicación de referencia.

En el pasado, Microsoft tenía una política más restrictiva sobre este tema. Básicamente: necesita nuestro permiso (Microsoft) para divulgar las comparaciones de rendimiento. Esta política se ha relajado, incluso retroactivamente, para .NET v1.0 y v1.1, según the link in the above EULA.

+0

Buenos hallazgos :) –

2

Aquí hay un buen benchmark donde alguien probó la diferencia entre Windows/IIS vs Linux/Apache/Mono (mod_mono). Lo suficientemente loco mod_mono (el plugin mono de apache) fue significativamente más eficiente. De acuerdo, estoy seguro de que en ciertas circunstancias sería diferente, pero teniendo en cuenta qué tan bajo perfil tienen Linux y Apache, además del gran trabajo que han hecho los mono, es lógico que Linux/Apache/Mono sea una mejor opción. Ahora que ya se ha dicho, con suerte con el nuevo ASP de fuente abierta, veremos algunos servidores Linux .Net muy avanzados pronto (preparados y listos para la nube).

graph of the performance comparison