¿La ingeniería de rendimiento se considera programación de fondo?

El rendimiento general de un sistema será una función de todas sus partes, sin importar cómo las clasifique y organice. Cuando haya ajustado la parte con el mayor cuello de botella de rendimiento hasta que ya no se interponga en el camino, es lógico que lo que solía ser el segundo cuello de botella más grande ahora será el más grande, y esa será otra parte.

Si restringe artificialmente su análisis de rendimiento a un subconjunto de todas las partes (llámelas back-end, middleware, O / S, o lo que quiera), las mejoras solo se pueden hacer hasta que el cuello de botella principal pase a algo que no es preparado para sintonizar No se trata de si lo hará o no; Si está omitiendo un subsistema de la ecuación de rendimiento, definitivamente se convierte en su mayor problema a menos que salga del ajuste antes de hacerlo. Es la misma razón por la que la pieza faltante de un rompecabezas siempre será la última que buscas: solo te das cuenta de que falta cuando todas las demás están en su lugar.

Puede considerar que el rendimiento es responsabilidad de cualquier subsistema que desee, pero le aconsejaría que no lo encasillara así, es una preocupación de todo el sistema por naturaleza.

Cada capa debe diseñarse en función de cada SLA ( Front-end -> Middleware -> Back-end ). Pero, según la aplicación, el enfoque en cada capa varía.

Las aplicaciones que son ricas en UI / UX con muchas actividades de navegador tendrán un enfoque en la optimización front-end . Por ejemplo, cualquier sitio web fotográfico.

Las aplicaciones que dependen de muchos datos que las actividades de la interfaz de usuario tendrán su enfoque de rendimiento en Ingeniería de back-end . Por ejemplo, sitios web bancarios.

Algunas aplicaciones son híbridas que necesitan riqueza visual y gran procesamiento de datos. Estos se ajustarán de punta a punta. Por ejemplo, sitios web de comercio electrónico.

Pues no siempre. En realidad, hay scripts malos creados por desarrolladores front-end que dificultan el problema de rendimiento de la aplicación. En el “viejo pensamiento”, los servidores tienden a ser culpados por cualquier problema de rendimiento.

Pero no hoy, incluso con el nacimiento de node.js (que es una de las cosas “de fondo”). Vi que es cierto que el problema del rendimiento puede ser causado por una mala secuencia de comandos, ya sea del lado del cliente o del servidor.

Por lo general, sí, aunque no necesariamente, ya que las interfaces de usuario también pueden funcionar bien o mal, y en general, el rendimiento es en gran medida un problema transversal afectado por la interacción de capas más que cualquier capa individualmente.

No, la buena ingeniería de rendimiento debe abarcar de extremo a extremo (frontend, backend, infraestructura y también contenido). El backend es solo una pieza de esto. En el mundo web, por ejemplo, aproximadamente el 80-90% de los problemas de rendimiento que vemos están en la interfaz Vea la publicación de Steve Souder sobre la Regla de oro de rendimiento.

Si por lo general. Porque el rendimiento no debería tener nada que ver con la interfaz de usuario