project management - recursos - ¿Cómo se hace la planificación de la capacidad del sitio web?

recursos de un proyecto de investigacion (6)

A menudo esto es muy difícil ya que el sistema ni siquiera está diseñado cuando el cliente solicita la respuesta a esta pregunta. Lo cual es en realidad imposible.

Como regla general, usamos 100 solicitudes por segundo por servidor. El número real variará según la aplicación y la forma en que los usuarios utilicen el sistema, pero consideramos que es una buena primera estimación.

El uso del disco para un sistema de documentos es solo el número de documentos multiplicado por el tamaño promedio. El ancho de banda es el número de solicitudes multiplicado por el tamaño promedio de las solicitudes.

Solo documenta todas sus suposiciones y dice que los requisitos de hardware se basan en esas suposiciones.

Acabo de leer el libro The Art of Capacity planning (BTW, me gustó), y en él el autor explica la importancia de medir sus servicios, conocer sus límites máximos, pronosticar sus necesidades, garantizar un despliegue sencillo, etc. Pero a través del libro explica su experiencia en Flickr, donde tiene que enfrentar todo el tiempo el mismo producto.

Muchos de nosotros, trabajamos en empresas en las que enfrentamos proyectos de pequeñas y medianas empresas para otras empresas. Tenemos que entender su negocio, sus necesidades, planificar una arquitectura, un modelo, etc., etc.

Luego, el cliente dice "Necesito apoyar a 1000 usuarios". Bueno, ¿y cuántas solicitudes por segundo es un usuario? ¿Cuánto duran sus sesiones? ¿Cuántos datos transfieren? ¿Qué operaciones ejecutan? cuanto tiempo son

A veces es posible conocer esas cifras (monitorear sus aplicaciones existentes o porque ya han realizado esas mediciones), a veces no es posible (porque no tienen un sitio web actual o simplemente es posible saberlo).

¿Cómo adivina el número de servidores, el ancho de banda, el almacenamiento, etc.? ¿Qué cifras de referencia utiliza?

Saludos.

Al desarrollar un sitio reciente de Asp.Net MVC, usé selenium para cargar la prueba de mi sitio. Básicamente, graba una selección de macros, en la que realiza tareas aleatorias.

Luego use selenio para simular una cantidad de usuarios que realizan esas macros. Probé mi sitio con decenas, cientos y luego miles de usuarios. Esto le permite encontrar puntos problemáticos en el código y en la infraestructura antes de ponerlos en funcionamiento.

Algunos puntos que debes saber para hacer esta planificación.

Cuántos usuarios al día.
Cuantos datos vas a controlar.
Cuántos datos vas a mostrar a cada usuario.
Ancho de banda promedio del usuario que pueda necesitar.
Tiempo promedio de uso de su sitio.

Los números promedio pueden darte una idea de lo que necesitas mensualmente. Por supuesto, también debe pensar en los números máximos, pero cuando procesan las computadoras y el sitio del servidor web dan ancho de banda por mes y algunos gigabytes en el disco duro, por lo que el pico no es un problema en el punto de inicio. Ahí debes pensar que si ejecutas consultas SQL que necesitan demasiada memoria RAM, o si compartes la computadora con muchos otros sitios.

Medida

Sin el sitio, sin la experiencia no tiene realmente medidas. Sin las medidas, realmente no puede estar seguro pero puede seguir algunas guías

Independientemente de lo que haga, try to make the grow of your data/features/runs linear and not logarithmic .
The speed of your site is not (only) depend from the capacity and the speed of your computer . Depende solo cuando la computadora está en sus límites. Si la computadora llega a su límite, agregue recurso adicional. Pero la velocidad debe ser cuidadosa cuando se diseña el software y el software de buena velocidad también está costando.
¿Tienes millones de datos cada día en la base de datos? necesitas más ram y disco duro
¿Tienes video y muchos archivos grandes para enviar? Necesitas más ancho de banda .
¿Tienes gente que usa el sitio para trabajar? Necesitas más velocidad y estabilidad.
¿Usted hace un sitio más de comercio electrónico? Necesitas mas seguridad con estabilidad.

El objetivo es tenerlos a todos, y la prioridad en lo que primero se enfoca realmente cambia.

Planificación de la velocidad.

Performance and Capacity: Two diffident animals* . El rendimiento se basa en un trabajo más humano y la capacidad se basa en más recursos informáticos. Para acelerar, primero debe saber cómo hacer que la computadora funcione sin problemas y luego cómo los trucos generales para hacer que los programas se ejecuten rápido, especialmente el de la web, y luego realmente necesita dedicar más tiempo a la realidad. Programa después de su ejecución, para mejorarlo para el rendimiento en las áreas críticas.

Planificación para expandir.

Haga un buen diseño de software y cuide la posibilidad de expandirse en caso de que necesite más para darle a su cliente la oportunidad de comenzar con poco, y pagar más solo si lo necesita. Entonces, cuando diseñe su software, piense que lo va a usar en un grupo de servidores web, cuide la sincronización, cuide los recursos comunes, ofrezca la capacidad de obtener datos de diferentes servidores, etc.

Planificacion con limites

De acuerdo, digamos que el cliente dice que solo tiene 1000 usuarios y que no le interesó ni a expandirse, ni a velocidad, y solo necesita un sitio rentable que haga su trabajo. En este caso también lo diseñas con estos límites. ¿Qué son estos límites? No coloca decenas de controles para las sincronizaciones, y lo hace funcionar como un solo subproceso, un solo programa de agrupación. No utiliza ningún mutex, ningún control doble, ningún pensamiento que ocurre cuando tiene 2 grupos o 2 computadoras ejecutando la misma aplicación. Solo tiene en cuenta los puntos de código para cambiarlos en caso de que necesite una actualización.

Tampoco hiciste ningún código que use recursos multicomputador. Y cuando lo ejecuta, tenga cuidado de que se ejecute solo en un grupo para que funcione correctamente.

Este diseño de grupo único es más fácil de desarrollar, más fácil de depurar, fácil de controlar, fácil de actualizar el código de buggy, y cuesta menos, pero sufre de velocidad (un usuario espera el otro en un grupo de subprocesos) y no se puede ampliar Recurso, que en realidad tiene que ver también con la velocidad.

Encontrar estadísticas

Si no sabe cuántos usuarios puede tener, puede usar alexa para ver sitios similares con el suyo y el promedio de usuarios / y el promedio de visitas a la página que tienen por mes. Entonces usted puede saber el posible ancho de banda.

No compre antes de que lo necesite

Comience con su predicción de hardware, pero no vaya y alquile 2 computadoras desde el primer día. Comience con el primero, haga sus mediciones, vea cómo crecen los datos y expándalo solo cuando lo necesite.

¿Coche o fórmula uno?

Cuando se ejecutan los programas, si lo sigues puedes encontrar muchas ideas que necesitan corrección. Solo puedo decir dos de mi vida.

Después de colocar el programa en línea, nuestro cliente comienza a agregar datos. Después de algunos meses, notamos que la base de datos crece demasiado, algo que no esperábamos que ingresara la información. Pasamos casi una semana para descubrir por qué y solucionarlo, fue un error de diseño que hizo que algunos datos estadísticos crecieran logarítmicamente, lo corregimos y seguimos adelante.

Después de dos años de funcionamiento notamos que hacemos demasiadas llamadas innecesarias al servidor SQL. Lo rastreamos y encontramos nuevamente un error de diseño, lo corregimos y seguimos adelante.

En realidad, hemos encontrado y corregido muchos puntos pequeños para el rendimiento cada mes. Para mí es como la fórmula uno. ¿Decide qué automóvil tiene, una fórmula uno que necesita todo el tiempo de corrección para obtener el máximo, o un automóvil simple que solo necesita un servicio anual?

Punto de vista del cliente

Then, the customer says "I need to support 1000 users" Bueno, el cliente no sabía de programación y trató de encontrar una medida desde su punto de vista para comparar propuestas. En realidad, hay muchos más factores aquí y los 1000 usuarios no son un parámetro correcto. ¿Es 1000 usuarios por día por minuto o por mes? ¿Se necesita para apoyar el chat en vivo, se necesita para ver una gran cantidad de datos o se necesita para trabajar rápido? Entonces, tal vez depende de usted vender correctamente su programa al cliente, explicándole que el buen programa es el mismo para un usuario de un millón de usuarios, y en realidad el inicio es un costo por el desarrollo y no por el desarrollo. Los usuarios.

Ahora bien, si esta es una pregunta para planificar realmente un sitio, entonces la respuesta simple del punto final es comenzar a hacerlo, y el resto será revelado. Si esta es una pregunta porque busca respuestas para su cliente, entonces debe preguntarse: ¿por qué la Fórmula Uno se ha sentado solo para uno y su automóvil tiene capacidad para cinco? ¿O cuánto cuesta una película? o todos sabemos cómo escribir, pero ¿por qué no todos escribimos y publicamos un libro? Mi punto es que el costo realmente se obtiene del tiempo que invierte en hacer el proyecto, y los usuarios por sí mismos no pueden determinarlo.

¿Conjetura, conocimiento o predicción?

How do you make a guess about the number of servers, bandwidth, storage, etc... En realidad no adivinamos, tenemos muchos sitios, recopilamos cada día muchas estadísticas automáticamente, muchos años de experiencia, y sabemos por el contenido de El sitio, cuántos usuarios pueden tener por día y cuánto ancho de banda puede comer. También tenemos muchas bases de datos que se ejecutan en nuestros servidores y podemos ver cuántos datos utilizan. Para el 99% de nuestros sitios todos los que son números bajos. Así que esto es conocimiento y experiencia, con estadísticas reales en vivo. La predicción viene al monitorear el tráfico y el uso de ellos, tratamos de mejorarlos, de obtener más tráfico, más usuarios y de lo que archivamos intentamos predecir si necesitarán más recursos en el futuro. Además, el 99% de los sitios son grupos únicos que ejecutan presentaciones muy simples.

''* Del libro

En la práctica, no lo hacemos. Nos aseguramos de poder expandir rápidamente (devops), tener la posibilidad de utilizar menos recursos / solicitudes, comenzar con un número muy pequeño de usuarios y observar el rendimiento. La mayoría de los proyectos pequeños y medianos no quieren gastar mucho tiempo y dinero en esto. Para un proyecto grande o crítico, tiene sentido crear y ejecutar simulaciones.

Recuerde, un día de planificación cuesta tanto como una máquina adicional por un año.

Usted usa la capacidad para cubrir una serie de cualidades no funcionales del sistema y probablemente está tratando de encapsular el rendimiento , la capacidad y la escalabilidad en un solo concepto.

Comencemos con el rendimiento y, si se trata de una arquitectura basada en web, en la que está sirviendo recursos, esto es realmente sencillo y puede dividirse en 2 KPI diferentes; el tiempo de respuesta del servidor y el tiempo de carga de la página (debe denominarse tiempo de carga de recursos, ya que no todos los recursos en la web son páginas web).

El tiempo de respuesta del servidor mide el tiempo hasta el último byte para una solicitud en un recurso determinado. Tenga en cuenta que esto no incluye cosas como la negociación de contenido. Usted (o la empresa) necesita especificar el tiempo de respuesta esperado del servidor para determinados tipos de recursos. Esto se basa en una sola solicitud / respuesta, por ejemplo, una respuesta a una solicitud para cualquier recurso que se encuentre dentro del tipo de "Modelo de automóvil", no debe tomar más de 0,5 segundos, el tiempo hasta el último byte.

Los tiempos de carga de la página llevan las cosas un paso más allá. Dada una solicitud de un recurso, cuánto tiempo lleva cargar ese recurso, junto con los recursos dependientes. Realmente tiene más significado cuando se encuentra en el contexto de una página web. La web está llena de incógnitas, lo que lo convierte en un área gris, ya que todo esto entra en juego (la red, el cliente, la negociación de contenido), por lo que necesita una respuesta dada una red fija / estabilizada y un cliente ( Hay todo tipo de herramientas para lograrlo. También debe definirse siempre como un promedio, sin introducir problemas de concurrencia (todavía no estamos pensando en la capacidad).

Una vez que haya especificado ambos, puede comenzar a determinar la capacidad inmediata de su sistema, es decir, cuántas solicitudes de recursos por segundo puedo realizar de manera eficaz (como se especificó anteriormente). Hay un montón de herramientas para ayudarte a definir esto. Esto le dará una medida inmediata de la capacidad. Notarás que uso el término de inmediato porque a menudo el negocio podría dar la vuelta y decir, genial, pero qué pasa si necesitamos aumentar esta capacidad.

Por lo tanto, pasamos a la tercera escalabilidad no funcional (nb, hay más de 3 cualidades no funcionales de un sistema, que incluyen disponibilidad, confiabilidad, validez, facilidad de uso, accesibilidad, extensibilidad y capacidad de administración). Dada una cierta capacidad, ¿en cuánto puedo aumentarla de forma eficaz? También hay formas de aumentar la capacidad, pero la mayoría de los sistemas por diseño generalmente tienen un cuello de botella en algún lugar que crea una restricción.

which figures of reference do you use?

En realidad, solo hay una figura que debe ser examinada, y luego extrapolada en: datos. Todas las cifras se derivarán de los requisitos de datos.

Pequeño ejemplo : un billón de solicitudes por hora para un número binario de 8 bytes no bloqueará nada y podría ejecutarse desde los servidores web más simples. La razón de esto es que el tiempo de solicitud será en fracciones de milisegundos. Hay 1000 (ms / s) * 60 (s / m) * 60 (m / h) * 24 (h / d) = 86.4 millones de milisegundos en un día, lo que significa que incluso si cada solicitud tomó un milisegundo completo del 1 millón aún estaría disponible ya que la velocidad requerida para obtener los 8 bytes estaría en el rango de 8kb / s.

Versión de la vida real : mirar los datos determinará los requisitos, y los datos que se están recuperando están casi siempre en una base de datos. El diseño de la base de datos (aunque sea conceptualmente) puede ayudar a determinar cuántos datos se utilizarán. Hay múltiples requisitos en la vida real. Se debe examinar la capacidad máxima de la base de datos, o sistema de archivos. Esta capacidad se puede calcular mirando la cantidad de espacio que requerirá cada fila de una tabla, sumando el espacio total consumido por cada columna (es decir, un ID de tipo int con longitud 6 tomará 6 bytes o espacio). Después de sumar cada columna de una fila de una tabla, para cada tabla en la base de datos, será fácil saber cuánta memoria requerirá cada colección de tablas (generalmente las tablas están vinculadas a través de claves externas). Después de considerar el consumo de memoria de la tabla, los usuarios deben ser examinados para determinar los requisitos. Lo que interesa principalmente es la cantidad de tablas a las que accederá cada usuario por sesión (sin datos, será una estimación, lo mejor es sobrestimar). Como ya sabemos, o tenemos una buena idea, cuál es el tamaño de las tablas de la base de datos, podemos asumir cuánta memoria de servidor necesitará el usuario. La comparación de este uso de memoria con la cantidad de usuarios esperados ayudará a determinar qué servidor usar, o cuántos. Lo siguiente para determinar es cuántas tablas se insertarán (de nuevo, en promedio, o con algunos datos de prueba recopilados) en la base de datos como resultado de las acciones del usuario. Esto es muy especulativo y es mejor hacerlo con pruebas. Sin pruebas, las suposiciones deben ser sobreestimadas. Basándose en la cantidad de filas que cada usuario insertará, será posible extrapolar el tamaño de la base de datos y los requisitos de ancho de banda. Estos se determinarán a través de la expansión de los requisitos de datos de un usuario, a los requisitos de n usuarios por t tiempo. Los datos requeridos por n usuarios permitirán ver los requisitos de ancho de banda en el tiempo t, y también determinarán cómo n usuarios crecerán la base de datos a lo largo del tiempo t.