Errores más comunes de escalabilidad del sitio web

Estamos diseñando un sitio web / aplicación web donde esperamos lograr un alto número de usuarios y, en general, mucho uso. Más específicamente, tenemos la intención de utilizar PHP como lenguaje de programación / scripting y MySQL para las necesidades de bases de datos relacionales como un comienzo. Todavía no hemos descubierto si usar una base de datos NoSQL o no.

En relación con eso, queremos diseñar teniendo en cuenta la escalabilidad. ¿Cuáles son las dificultades de escalabilidad más comunes para los sitios web? ¿Cuáles son las áreas clave que debemos tener en cuenta para que el sistema pueda ser fácilmente escalable?

Yo agregaría a eso una cosa muy común: optimizar en el lugar equivocado. He visto toneladas de artículos que discuten las diferencias de nanosegundos en las construcciones de sintaxis de PHP, pero mucho menos que discuten cómo diseñar adecuadamente la infraestructura de almacenamiento en caché para una aplicación. Entonces, como ya se señaló, prueba. Pero no solo prueba - perfil y descubre exactamente quées lento, ¿está vinculado a la CPU? I / O obligado? ¿Atado a la memoria? ¿Son las consultas de la base de datos las que lo hacen caer, está leyendo los archivos, son cálculos? ¿Puedes eliminar eso o rehacerlo para que funcione más rápido? Etc. No comience con "usemos NoSQL porque es más rápido". Comience con "queremos hacer esto y aquello, ¿cuáles serían los cuellos de botella? ¿Cómo los eliminamos? ¿Cómo se comportaría si recibiéramos 100 usuarios?" Sin saber más sobre la carga de trabajo y la aplicación, es difícil decir algo concreto, pero comenzaría pensando qué puede almacenar en caché y cómo reducir el sistema de archivos / base de datos / etc. accesos y especialmente modificaciones (ya que también invalidarían los cachés).

El obstáculo de escalabilidad más común es no realizar pruebas de carga desde el principio. Si configura pruebas que simulan algo comparable a su carga esperada temprano durante el desarrollo, entonces podrá detectar y corregir cualquier impedimento tecnológico o arquitectónico a la escalabilidad antes de que sea demasiado costoso arreglarlo.

Algunos buenos ejemplos de escalado con PHP: Tumblr , Flickr , Netlog

El consejo común dado sobre la escalabilidad:

• ¡Mantenlo simple!
  No modifique en exceso ni compre soluciones sofisticadas específicas para proveedores.
• Arquitectura de nada compartido
  Mantenga su estado en la base de datos y fuera de sus servidores de aplicaciones (evite incluso los datos de sesión en el servidor). De esta manera, puede agregar fácilmente servidores de aplicaciones adicionales según sea necesario.
• Concéntrese en el almacenamiento en caché de front-end (archivo estático)
  Use un proxy inverso y luego en un CDN. Lo que no tiene que ser atendido desde el servidor de aplicaciones es menos carga en ese servidor.
• Mida el sistema real
  Monitoreo integrado para saber dónde están sus cuellos de botella. Asegúrese de poder predecir la carga futura en función de las curvas de crecimiento.
• Preste atención al diseño de
  su base de datos. Ajuste sus consultas, use memcached para evitar consultas y participe sus datos en las instancias cuando se quede sin espacio para respirar en una instancia de base de datos (controle para saber esto con anticipación).

Algunas trampas:

• NoSQL vs SQL es una pista falsa.
  Todos los grandes están ejecutando su núcleo en bases de datos SQL. Use NoSQL si está seguro de que tiene sentido, pero no lo use suponiendo que resolverá sus problemas de escala. No lo hará.
• Tenga cuidado con los ORM.
  Tienen un estado pesado en el servidor de aplicaciones (contradice la arquitectura de nada compartido) y requieren que comprenda no solo cómo ajustar las consultas SQL, sino también cómo ajustar el ORM sobre las consultas SQL (en otras palabras, solo simplifique las cosas si el rendimiento no importa). Dé preferencia a las consultas diseñadas a mano y al uso liberal de memcached en su lugar.
• Sistemas pesados ​​de plantillas / enrutamiento en el servidor. Mantenga la pila del servidor deliberadamente ligera.
• No se preocupe por el rendimiento del código línea por línea.
  Siempre puede entrar y corregir puntos de acceso más tarde (use xdebug o herramientas de creación de perfiles similares). Tener una arquitectura escalable importa MUCHO más que el rendimiento del código, así que invierta su capacidad intelectual en consecuencia.

La única forma real de saber si tienes problemas de escalabilidad es probarlo, así que prueba temprano, prueba a menudo como dice Michael Borgwardt .

Aparte de eso, una razón común por la cual los sistemas no escalan es debido a la contención de recursos. Y eso generalmente se muestra en la base de datos, tratando de leer y escribir al mismo tiempo. Por lo tanto, es posible que desee pensar en utilizar un enfoque CQRS que desconecte el lado de lectura (Consulta) del lado de escritura (Comando).

Prepárate para fragmentar todo. Si puede particionarlo en varios hosts, estará mucho más cerca de construir algo que pueda escalar.

Diseñe también para el caso de un millón de usuarios y reduzca la escala. No diseñe para 1,000 usuarios y escale.

Sinceramente, PHP y MySQL no serían mi elección para hacer esto. Intentar hacer datos fragmentados en MySQL es un dolor de cabeza.