¿Cómo se maximiza el rendimiento del servidor?

Question

He estado tratando de entender el rendimiento y la escalabilidad, y me gustaría saber qué hacen los desarrolladores/administradores de sistemas para mejorar sus sistemas. Para estandarizar las respuestas, sería de ayuda si usted podría tomar su mejor oportunidad de responder a cualquiera de los siguientes:

1. Perfil - Edición de revistas en Joomla; bolsa de empleo en CodeIgniter + OpenID + AJAX
   • Rendimiento - Como máximo por segundo por servidor ?
   • Hardware - Servidor, enrutador, disco, LAN?
   • Software - Lighttpd, Memcache, barniz, Nginx, calamar, Libra, LVS, eAccelerator, etc.
   • Servicios - Amazon S3, Akamai, Google Compute, etc.
   • configuración - estáticos hash, módulo Upstream, Memcache durante x minutos después de n solicitudes, deshabilitar solicitudes de registro de imágenes, etc.
   • Otro - ¿Algo más? (Ejemplo, las tablas normalizadas malas para los sitios con mucha lee)

Editar: vuelva a tener en cuenta antes de cerrar esta pregunta asitisimportant a los desarrolladores web para buscar a estas cosas. Un programador podría modificar el punto y coma de su código, pero aún así perder ante un mal codificador que escribe para memcached o logra armar un CDN a través de Google App Engine.

Answer 1

No tengo tiempo para responder a su pregunta bullet by bullet. =) Pero puedo recomendar una estrategia general para separar las preocupaciones y no unir los recursos del servidor cuando no hay una necesidad inmediata. mod_proxy (y cualquier equivalente) es tu amigo. Hace que sea fácil lanzar hardware a los problemas de rendimiento que se muestran. Por supuesto, no tiene que factorizar el sistema a la perfección desde el principio (ya que es realmente difícil anticipar dónde aparecerán los cuellos de botella reales). Pero cuando encuentras problemas Recuerda a tu amigo

Answer 2

Nuestro sistema: No puedo decirle mucho al respecto, pero es una gran aplicación SaaS que sirve a muchos clientes que pagan.

---

Cada pieza de trabajo de rendimiento/capacidad que hacemos está hecho con mucho cuidado - no podemos probar cosas para ver si funcionan.

Inicialmente se realizarían algunos análisis del rendimiento y la capacidad actuales, si podríamos seguir trabajando de todos modos.

Si fuera posible, reproduciríamos los problemas de rendimiento en un sistema que no sea de producción en el que pudiéramos crear un perfil del código y realizar cambios experimentales. No siempre podemos usar exactamente el mismo hardware que la producción (la producción tiene una gran cantidad de servidores de muy alta especificación; dev tiene solo unas pocas cajas de prueba de rendimiento dedicadas a las especificaciones de producción).

Si el problema no se puede analizar de manera significativa en un entorno no productivo, enviaremos algunos instrumentos a nuestro código en producción (después de pruebas cuidadosas para garantizar que la instrumentación no afecte al sistema). Esta instrumentación se enviaría "off" y se activaría selectivamente para recopilar datos suficientes.

Una vez que tenemos un análisis preciso de un problema, buscamos soluciones posibles, y tal vez desarrollamos prototipos, estos podrían ser probados para la corrección funcional.

Normalmente elegimos la opción menos arriesgada si hay varias.

El proceso de liberación normal sería entonces siguió - un montón de pruebas, revisiones de código, etc.

Si procede, el cambio podría ser enviado con un "interruptor de revertir", que permitió que se apaga en la producción rápidamente si había un problema.

Existen muchas mejoras de rendimiento potencial que hemos identificado, la mayoría de las cuales no desarrollaremos hasta que ocurra un problema (a menos que hagamos una refactorización no relacionada de esa pieza de software de todos modos).

Answer 3

No hay un plan maestro concreto para la optimización del rendimiento (como comenzar primero en el software "xyz").

Enfoque general:

1. Identificar (! Medir) de su entidad más improveable por los medios de mejora en el tiempo/invertido
2. optimizarlo
3. Repita