En realidad, no pudimos encontrar ninguna ventaja en el método "uno sale, uno entra". En pocas palabras, el problema con ese enfoque es que cuando los usuarios son visitantes de sitios web de comercio electrónico, el servidor web no sabe cuántos usuarios concurrentes tiene en cualquier momento. Es un obstáculo. He aquí el motivo.
Más adelante en este artículo, también te contamos cómo utilizar una sala virtual basada en tasas para proteger tu sitio también.
Tradicionalmente, los servidores de comercio electrónico se aprovisionan para soportar un número máximo de usuarios concurrentes, y la carga suele definirse de esta manera. Existe un problema al utilizar este enfoque para ejecutar una cola de un sitio web, un problema que resolvemos con las tarifas.
El problema surge porque los visitantes sólo utilizan realmente el servidor web mientras su navegador carga cada página web.
Por ejemplo, supongamos que un sitio de comercio electrónico vende entradas. Desde el inicio del viaje del visitante hasta el final del mismo (la sesión del usuario) hay seis páginas, ya que el visitante
El proceso completo de la transacción dura una media de cinco minutos.
Supongamos, de nuevo por ejemplo, que cada minuto llegan 100 visitantes a comprar entradas, y que el tiempo medio para completar el proceso es de cinco minutos. En un momento dado, hay 500 personas en el proceso de transacción al mismo tiempo, y el servidor debe estar aprovisionado para soportar 500 usuarios concurrentes.
Uno podría pensar que uno podría crear un Contador de Usuarios Concurrentes que se incrementa cada vez que un nuevo visitante llega a la página de inicio, y se decrementa cada vez que un visitante completa la transacción, y que esto le diría cuántos usuarios maneja un solo servidor en cualquier momento, pero esto no funcionará.
No funcionará porque no todos los visitantes completan la transacción. La gente cambia de opinión, o se distrae, o se va y vuelve más tarde. Como el servidor web sólo interactúa con los visitantes cuando sus navegadores cargan las páginas, no tiene forma de saber cuándo ha ocurrido esto, ni a quién.
En su lugar, para determinar que un visitante ya no forma parte del proceso de transacción, el servidor único tiene que esperar a ver si no llegan más peticiones de página de ese visitante y entonces cerrar la sesión de ese visitante. El tiempo de espera debe ser siempre mucho más largo que el tiempo medio de la transacción (digamos 20 minutos en este ejemplo) ya que algunos visitantes tardan mucho más que otros en completar su transacción.
Se podría añadir la posibilidad de disminuir el contador de usuarios concurrentes cada vez que se agote la sesión de un visitante, pero esto da resultados muy pobres.
Si el 10% de los 100 visitantes que llegan cada minuto no llegan a completar su transacción, los que sí la completan estarán activos durante cinco minutos de media y los que no la completan se considerarán activos durante al menos 20 minutos siempre (en realidad, el tiempo de espera de la sesión más la duración media de la sesión es más probable cuando se consideran sesiones múltiples).
Son 90 * 5 + 10 * 20 = 650, y el servidor informará de 650 usuarios simultáneos, aunque en realidad esté menos ocupado.
Además, hasta 10 * 20 = 200 de esos usuarios concurrentes no están usando realmente el sitio y están en el proceso de cierre, lo cual es más del 30% de los usuarios concurrentes reportados, aunque sólo es el 10% de los visitantes que no completan la transacción.
Ahora digamos que uno desea añadir una cola a este sitio web, controlada por nuestro Contador de Usuarios Concurrentes. Una vez que el sitio está en la capacidad, entonces un individuo que está en la parte delantera de la cola sólo se pasará al sitio una vez que el contador disminuye. Esto se denomina cola de salida-entrada. Lo que ocurrirá es que el 30% de las veces, una persona al frente de la cola estará esperando a que alguien que no va a completar su transacción termine de no completar su transacción.
También existe el trabajo de integración técnica adicional y la carga en el sitio web de crear y ejecutar el contador, y compartir esa información con el sistema de colas. Si el mecanismo de compartición o recuento se cae o se rompe, la cola se atasca. Y lo que es peor, si el servidor único está tan ocupado que no puede actualizar el servidor de colas para indicarle que deje pasar a la siguiente persona, la cola también se atasca.
Todos estos problemas se solucionan fácil y sencillamente enviando a los visitantes de la parte delantera de la cola a un ritmo constante y fijo, en este caso 100 visitantes por minuto.
De este modo, no es necesario medir el número real de usuarios concurrentes, ni la compleja integración con el sitio web de venta de entradas, ni el riesgo de que la cola se atasque.
Por eso inventamos y patentamos en 2004 la sala de espera virtual basada en tarifas para sitios web con mucho tráfico.
‘Me quita TODO el estrés. Queue-Fair funcionó a la perfección, fue muy fácil de configurar y el soporte fue superior, una clase magistral de soporte. La experiencia fue muy fluida y nos dio mucha confianza de antemano. En años anteriores, nuestro sitio web siempre se bloqueaba, lo que resultaba muy estresante para todos los implicados. Queue-Fair resolvió este problema, nuestro sitio web no se bloqueó. Todo funcionó, tal y como dijo nuestro consultor de incorporación. Con Queue-Fair estamos seguros de que los días venideros serán aún mejores.’
‘Queue-Fair es estupendo para nuestro gran evento de venta al por menor en línea. Su uso resultó muy intuitivo y funcionó a la perfección. Queue-Fair proporciona continuidad y aumenta la confianza para la experiencia en línea del cliente. Definitivamente tenemos planes para Queue-Fair en el futuro para eventos en los que esperamos un enorme aluvión de tráfico y participación en grandes eventos de venta al por menor.’
‘Una solución de sala de espera virtual fabulosa con un equipo de asistencia increíble. Queue-Fair es perfecto, muy fácil de instalar y configurar. Para el stock de cantidad limitada que queremos vender - y no sobrevender - la experiencia del cliente ha mejorado completamente. Se acabaron las ralentizaciones del sitio y los problemas para añadir productos a las cestas. Perfecto. Gracias a Queue-Fair, sentimos que teníamos el control en nuestro día comercial clave , el Viernes Negro. A la empresa le gusta mucho. Queue-Fair ha tenido mucho éxito, funciona realmente bien. El soporte ha sido brillante - cada pregunta ha sido respondida super rápidamente. Tenemos muchos eventos próximamente en los que también queremos utilizar Queue-Fair.’
‘Una solución excelente para la gestión de grandes flujos de tráfico El equipo es muy profesional y atento a las necesidades del cliente. La plataforma es fácil de integrar. Queue-Fair nos ayuda a gestionar los picos inesperados, garantizando que nuestro sitio web siga funcionando durante los picos de demanda.’
‘Brillante. Tuve una noche de insomnio preocupada por si el sitio web volvía a bloquearse después de la última vez que intentamos realizar nuestra popular promoción sin Queue-Fair. Estoy encantado de haber encontrado su solución. Gracias por vuestra capacidad de respuesta; es muy de agradecer que nos hayáis configurado esto en menos de un día y que haya funcionado perfectamente. Espectacular. Un material precioso. Dorado. Gracias de nuevo; esto significa el mundo para mí. Voy a dormir bien esta noche. Legendario.’
‘Sencillo y fácil de usar, con un gran servicio de atención al cliente. Es fácil personalizar Queue-Fair en su marca. Queue-Fair protege los eventos de nuestros clientes de un stampeed durante en período de venta.’
‘El personal de Queue-Fair hizo todo lo posible para ayudarnos a implantar su sistema de colas en un día. Con más de 25.000 personas en la cola, nos ayudaron a gestionar el tráfico durante nuestros picos de trabajo. Queue-Fair hace lo que tiene que hacer: poner a la gente en cola a un precio competitivo. Estamos contentos con el sistema Queue-Fair y seguiremos utilizándolo en futuros eventos.’
‘Resolvimos nuestro problema de sobrecarga extrema en el sitio web con Queue-Fair. Estamos muy contentos y queremos seguir con ellos en el futuro, ¡el servicio y la asistencia son excelentes! ¡Muy fácil, y el personal extremadamente servicial! Todo ha ido muy bien con la implementación. No hay nada que no nos guste de esta empresa.’
‘¡Brillante! Estamos muy contentos y satisfechos con Queue-Fair, es maravilloso tener este nivel de apoyo. El servicio funciona a la perfección: vendimos miles de entradas en muy poco tiempo y Queue-Fair nos ayudó a gestionar el tráfico durante los picos de trabajo. Estamos recomendando Queue-Fair a nuestros socios de servicio también. ¡Estoy muy contento!’
‘La comunicación y la facilidad de uso de la plataforma de Queue-Fair hacen que el producto sea realmente excepcional. Necesitábamos una cola para un evento especialmente concurrido en nuestro sitio web, y pude verlo en tiempo real, hacer cambios de forma eficaz y asegurarme de que nuestro sitio web no se iba a colapsar. Siempre que tuve preguntas o necesité apoyo, fueron muy útiles. Definitivamente recomiendo la plataforma y el servicio.’
‘Todo ha funcionado perfectamente. Lo utilizaré cada vez que tengamos un pico de tráfico para no perder ninguna visita. Queue-Fair es la solución más barata del mercado. Se instala en pocos minutos. Gran soporte y muy buena reactividad. Fácil de editar páginas. El mejor precio por su dinero que usted puede conseguir para manejar su evento crítico, yo era capaz de manejar más de 10.000 visitantes pico de tráfico de programa de televisión sin problemas.’
‘Estamos muy contentos de contar con Queue-Fair como socio de la Sala de Espera para los tres grandes eventos de lanzamiento del iPhone. ¡Nuestro sitio web no se cayó! Incluso superamos nuestro objetivo de ventas, ¡gracias a Queue-Fair! La plataforma Queue-Fair es muy fácil de usar y los informes de datos nos proporcionaron información muy útil para nuestros futuros proyectos. Estamos muy contentos de contar con ellos como socio :) Queue-Fair será sin duda nuestra única recomendación de Sala de Espera a nuestros queridos amigos. ¡Más potencia Queue-Fair! ¡Buen trabajo!’
Si sabe cuántos usuarios concurrentes maneja un servidor web, y el tiempo medio de transacción o la duración de la visita, desde la primera página de su flujo de transacciones hasta la página de confirmación del pedido, puede convertir esto en una tasa de cola utilizando la Ley de Little, dividiendo el número de usuarios por la duración, así:
Tasa de colas = Usuarios concurrentes / Tiempo de transacción
Queue-Fair enviará visitantes a su sitio web al ritmo que usted especifique - tenemos, con mucho, la IA de colas más precisa en el negocio para asegurar que el número de visitantes que usted quiere cada minuto es el número de visitantes que usted recibe cada minuto, contabilizando automáticamente las personas que no están presentes cuando se llama su turno, así como las personas que regresan tarde.
¿Cómo se traduce esto en el número de usuarios simultáneos? Por supuesto, no todos los visitantes que llegan a su sitio web tardarán el tiempo medio exacto en completar su transacción, pero obtendrá un número muy constante de Usuarios Concurrentes con Queue-Fair, debido a la Ley de los Grandes Números.
Por ejemplo, digamos que tiene una tasa de cola de 100 visitantes por minuto. Enviaremos 100 visitantes a su sitio web cada minuto en un flujo constante - eso es lo que hacemos y somos asombrosamente buenos en ello. Digamos también que la gente utiliza su sitio web durante una media de cinco minutos, y que el 70% de ellos tarda entre 4 y 6 minutos desde que pasa por la cola hasta que realiza su última solicitud de página (independientemente de que complete o no una transacción). Eso supone una desviación estándar de un minuto a cada lado de la media. Estadísticamente hablando, eso significa que por cada visitante que tarde cinco minutos y medio, habrá otro que tarde cuatro y medio, y estas variaciones en las duraciones de las visitas individuales a lo largo de múltiples sesiones tienden, por tanto, a anularse entre sí cuando se cuentan muchas de ellas de cualquier manera. La Ley de los Grandes Números dice que esta anulación es cada vez más exacta cuanto mayor es el número de personas implicadas.
¿Cómo de exacto, exactamente? Podemos resolverlo con un poco de estadística. El tamaño de la muestra es de 5 * 100 = 500, que es el gran número en cuestión. Ese es el número de personas que estás contando. Esto significa que el error estándar en la media del tiempo de la transacción es 1 (la desviación estándar, 1 minuto) dividido por la raíz cuadrada del tamaño de la muestra (por tanto, la raíz cuadrada de 500) según la fórmula estadística del error estándar en la media, lo que da un error estándar en la media del tiempo de la transacción de 0,044 minutos, es decir, sólo 2,7 segundos, que es menos del uno por ciento.
Esto significa que con una tasa de cola de 100, y un tiempo de transacción de 5 minutos más o menos para cada visitante individual, debería esperar entre 495 y 505 usuarios concurrentes en su sitio alrededor del 70% del tiempo, por lo que las matemáticas dicen que el uso de una cola basada en la tasa proporcionará una carga muy constante en sus servidores web como se desea.
Pero, ¿son exactas las matemáticas? Hay algunas sutilezas aquí - por ejemplo, el tamaño de la muestra que estamos elevando al cuadrado no siempre es exactamente 500 cada vez que se cuentan los usuarios concurrentes (es decir, en cualquier momento dado), y también una distribución normal (gaussiana) puede dar tiempos de transacción negativos que no ocurren en la vida real. Así pues, utilizamos un simulador visitante por visitante, segundo por segundo, para realizar mediciones y comprobar este tipo de cálculos, y eso nos dice que con las cifras anteriores, deberías esperar entre 493 y 507 visitantes el 70% de las veces, ¡así que las matemáticas se mantienen notablemente bien! La medición de los datos también nos dice que su sitio tendrá 500 ± 15 usuarios concurrentes al menos el 95% del tiempo.
¡Eso es probablemente más estable que la precisión con la que su servidor web puede medir el número de personas que utilizan su sitio! Y lo mejor de todo es que, aunque no tengas ni idea de cuál es el tiempo medio de transacción o la desviación estándar de tus visitantes, estas cantidades matemáticas existen, las conozcas o no, y obtendrás una carga estable de todos modos.
El resultado es que Queue-Fair proporcionará el número de visitantes por minuto que desee con una precisión casi perfecta, lo que se traduce en un número muy constante de usuarios concurrentes en su sitio, y una carga estable del servidor web sobre la que tiene un control total.
¡Hurra!
Y ahora una advertencia. Vale la pena señalar que la estabilidad del número de usuarios concurrentes en su sitio - y por lo tanto la estabilidad de la carga de su servidor - depende críticamente de la precisión con la que su proveedor de Sala de Espera Virtual le envíe el número de visitantes que desea cada minuto, y esto es por lo tanto un factor clave cuando usted elige una plataforma de Sala de Espera Virtual. Porque proporcionamos la Sala de Espera Virtual más precisa del mundo, nadie impide que sus servidores se inunden mejor que Queue-Fair.
¿Qué pasa si no sabe cuántos usuarios concurrentes puede manejar un servidor, o el tiempo de transacción? Puede mirar la página que probablemente sea su cuello de botella - normalmente la que es el resultado de hacer clic en un botón "Comprar ahora". Utilice Google Analytics para encontrar los visitantes únicos mensuales de esa página, o cuente sus pedidos mensuales. Divida esto por 30 * 24 * 60 = 43.200 que es el número de minutos en un mes (aproximadamente). Esa es la media de visitantes por minuto durante todo el mes. Multiplíquelo por tres. Esa es su media de visitantes por minuto durante el horario comercial (aproximadamente). Duplique esta cifra. Esa es probablemente una cifra segura para la Tasa de Cola a utilizar.
Por ejemplo, supongamos que procesa 100.000 pedidos al mes, es decir, 100.000 clics en el botón "Comprar ahora". Esto supone 100.000 / 43.200 = 2,31 pedidos por minuto. Es de esperar que la mayoría de estos pedidos se realicen durante el día, y que sus servidores estén más tranquilos por la noche, así que multiplíquelo por 3 y obtendrá 7 pedidos por minuto como estimación aproximada de lo ocupado que está su servidor durante el horario comercial. Si la cifra resultante es inferior a 50: habrá picos y caídas en la demanda, así que si su servidor no es notablemente lento en las horas punta, multiplíquelo por 2 para obtener 14 usuarios activos por minuto. Si la cifra es superior a 50: los picos y caídas minuto a minuto serán menores en comparación, y no es seguro duplicarla. El número que obtengas es probablemente una cifra segura para la tasa de colas para empezar y corresponde a cuántas solicitudes por segundo puedes gestionar con seguridad; siempre puedes aumentarla si ves que tus sistemas siguen respondiendo al rendimiento de los usuarios finales a esa tasa.
Si sus pedidos tienen un sello de tiempo, también puede mirar el máximo de pedidos que tomó en un solo minuto en el último mes - pero utilícelo con precaución ya que no sabrá cuántos pedidos puede haber dejado caer durante este minuto debido a la ralentización de sus servidores, así que reduzca esto en un 20%.
En el resto de este artículo se analizan otras formas de calcular la tasa de cola.
Vale la pena señalar que hay al menos dos definiciones de "Usuarios Concurrentes" en el uso común.
Utilizamos la definición "el número de personas que participan en un flujo de transacciones en un momento dado". Ese es el número clave que necesita saber para establecer la tasa de cola. Es el número de usuarios que están viendo su sitio en este momento. El número de Sesiones Concurrentes suele ser algo mayor que el número de conexiones concurrentes o usuarios concurrentes, porque algunas de las sesiones están en proceso de agotamiento, aumentando la duración media de la sesión.
Contrasta esto con el número de Peticiones Concurrentes, que es el número de peticiones HTTP que están siendo procesadas por su servidor web en cualquier momento. De forma muy confusa, muchos técnicos se refieren a cuántas peticiones concurrentes cuando dicen cuántos usuarios concurrentes.
Luego están las Conexiones Concurrentes (o conexiones TCP concurrentes al mismo puerto del servidor en su tarjeta de interfaz de red), que es el número de Sockets TCP/IP abiertos en el puerto de su servidor o servicio backend en cualquier momento. Cuando se realizan solicitudes de páginas, los navegadores dejan por defecto la conexión abierta por si la página realiza más solicitudes o el usuario va a otra página. Esto reduce el número de peticiones por segundo para abrir nuevas conexiones TCP/IP, haciendo que el proceso del servidor sea más eficiente. Los tiempos de espera para estas conexiones concurrentes varían según el navegador, desde 60 segundos hasta nunca cerrar. Su servidor también puede cerrar automáticamente las conexiones después de un periodo sin actividad. En los servidores web de Linux puede obtener un recuento de las conexiones concurrentes al mismo puerto del servidor con este comando: netstat -aenp | grep ":80 |:443 " | wc -l
que puedes probar si tienes curiosidad. De nuevo, algunas personas llaman a esto "Usuarios Concurrentes" también, cuando realmente significa conexiones concurrentes.
De hecho, si le pides a tu proveedor de alojamiento que te diga el número máximo de Usuarios Concurrentes que maneja tu servidor web (cuántos picos de tráfico), probablemente te dará una cifra de Sesiones Concurrentes, Peticiones Concurrentes o Conexiones Concurrentes, por la sencilla razón de que no conocen tu tiempo medio de transacción, el número de páginas en tu flujo de transacciones, o cualquier otra información que les permita decirte cuántos usuarios simultáneos maneja tu servidor web. Todos estos números tienen valores diferentes.
Si pide a su proveedor de alojamiento o a su equipo técnico información sobre los niveles máximos de tráfico, es muy importante que aclare si se refiere a Usuarios Concurrentes, Sesiones Concurrentes, Peticiones Concurrentes o Conexiones Concurrentes.
He aquí la razón. Cada página es una única petición HTTP, pero todas las imágenes, scripts y otros archivos que provienen de tu aplicación web y que el navegador utiliza para mostrar la página también son peticiones HTTP.
Imaginemos que su equipo técnico le ha dicho que el servidor soporta 500 usuarios concurrentes, pero en realidad quieren decir 500 solicitudes concurrentes. Con su tiempo de transacción de 5 minutos, utiliza la fórmula anterior y asume que su sitio puede soportar 100 visitantes por minuto.
¿Puede? No.
A medida que la gente pasa por el flujo de transacciones, sólo están haciendo peticiones a sus servidores mientras se carga cada página. Esto afecta a la cantidad de tráfico por segundo o de usuarios activos que su servidor puede manejar. Del tiempo de transacción de cinco minutos, son sólo unos segundos para un usuario medio. Por lo tanto, podría pensar que 500 solicitudes concurrentes significa que puede manejar muchos más usuarios concurrentes, pero puede estar equivocado. ¿Puedes ver ahora cómo entender la capacidad de tu sitio web en términos de cuánto tráfico o número total de usuarios activos es un asunto tan complicado?
Para calcular el número máximo de usuarios concurrentes a partir del número total máximo de solicitudes concurrentes, también necesita saber
Probablemente ya conozcas 1) y 2) - en nuestro ejemplo son 6 páginas y 5 minutos. Puede contar fácilmente las páginas que ve mientras realiza una transacción. Si no conoce el tiempo medio de la transacción, Google Analytics puede decírselo, o puede comprobar los registros de su servidor web.
Para 3) y 4), el navegador Firefox puede ayudar. Haz clic con el botón derecho en una página de tu sitio, elige Inspeccionar elemento y la pestaña Red. A continuación, pulsa CTRL-SHIFT-R para actualizar completamente la página. Verás los tiempos de carga de la red para cada elemento de la página en la lista. Debes asegurarte de que puedes ver los tamaños de transferencia en la columna Transferido, ya que de lo contrario los archivos podrían ser servidos desde una caché, lo que puede estropear tus cálculos. Es posible que veas que algunos scripts y otros recursos provienen de servidores distintos al de tu sitio, por lo que puedes escribir el nombre de dominio de tu sitio en el cuadro de filtro de la izquierda. Para ver la columna de duración, haz clic con el botón derecho del ratón en cualquier cabecera de columna y selecciona Tiempos -> Duración en el menú emergente. Su pantalla debería tener el siguiente aspecto:
La pestaña de red de Firefox para esta página, mostrando la duración y el número de solicitudes de queue-fair.com
Los archivos utilizados en la visualización de sus páginas pueden provenir de diferentes sitios, por lo que también debe utilizar el filtro de la parte superior izquierda para mostrar sólo los de su sitio - pero sólo si está seguro de que esos archivos de otros sitios no son la razón de la carga lenta de la página, o parte de su cuello de botella.
Firefox cuenta las peticiones en la parte inferior izquierda de la pantalla y muestra 36 peticiones HTTP sólo para esta página.
Debe hacer esto para cada página de su flujo de transacciones: cuente el total y divídalo por el número de páginas para encontrar el número medio de peticiones HTTP para cada página, número 3) de nuestra lista. Ahora puedes ver por qué el número de peticiones hijo para cada página HTML es un factor clave para la cantidad de tráfico que tu servidor web puede manejar.
Para el número 4), tienes que mirar la columna de Duración y encontrar la media de todas las peticiones HTTP de todas tus páginas. Si no está seguro, asuma medio segundo - hay mucha incertidumbre en esto de todos modos (ver abajo).
Pongamos algunos números de ejemplo. Ya hemos dicho que hay seis páginas dinámicas en el flujo de proceso del servidor de ejemplo, que es 1), y que el tiempo medio de transacción es de cinco minutos, que es 2). Supongamos 36 peticiones HTTP por página para 3), y medio segundo para el tiempo de procesamiento del servidor para cada petición HTTP, que es 4).
Con estos números, un servidor que puede manejar 500 peticiones concurrentes puede manejar 500 / (0,5 segundos) = 1000 peticiones HTTP por segundo, lo que supone 60.000 peticiones HTTP por minuto, cuando está completamente al límite.
Durante el tiempo de transacción de cinco minutos, puede manejar 5 * 60.000 = 300.000 peticiones HTTP. Parece mucho, ¿verdad?
Pero, para cada visitante, hay seis páginas con una media de 36 peticiones HTTP cada una, por lo que son 6 * 36 = 216 peticiones
Así, la capacidad de 300.000 peticiones HTTP puede , en teoría, manejar 300.000 / 216 = 1.389 usuarios concurrentes
¡Eso es genial! Pensábamos que sólo podíamos tener una tasa de colas de 100, pero 1.389 / 5 minutos = 278 visitantes por minuto, ¡así que podemos tener una tasa de colas mayor!
Bueno, probablemente no. En primer lugar, sus visitantes no enviarán solicitudes a intervalos de medio segundo exactamente, como se supone en el cálculo anterior. Y lo que es más importante, habrás medido tus datos de entrada cuando el sitio no está ocupado. La basura entra, la basura sale.
Cuando el sitio está ocupado, el servidor tarda más tiempo en procesar las peticiones - lo habrás notado en otros sitios cuando las cosas están ocupadas, que esperas más tiempo por las páginas. Esto aumenta el tiempo medio que el servidor tarda en procesar una sola petición HTTP (4), lo que disminuye el rendimiento máximo. Así que toma los 278 visitantes por minuto y los reduce a la mitad. Luego, vuélvelo a reducir a la mitad. Probablemente, lo más realista es que tengas unos 70 visitantes nuevos por minuto a máxima carga.
Otros factores de confusión son el almacenamiento en caché, lo que significa que los navegadores de sus visitantes no necesitan hacer cada una de las peticiones para cada una de las páginas - esto tiende a significar que el servidor necesita menos recursos y puede aumentar el número de nuevos visitantes por minuto que su servidor puede manejar. Los equilibradores de carga que distribuyen la carga entre varios servidores y el hecho de servir contenido estático en lugar de páginas dinámicas también pueden acelerar el proceso de su servidor, ya que cada servidor necesita menos recursos.
También verá que no todas las páginas tardan lo mismo en completarse, ya que algunas requieren menos recursos que otras para producirse y servirse. Las búsquedas en la base de datos, las consultas de búsqueda y las actualizaciones son las que más tardan, por lo que habrá un cuello de botella en algún punto del proceso en el que la gente se acumule, esperando a que se procesen los datos de la tarjeta de crédito y se almacenen los pedidos, o esperando a que se compruebe la disponibilidad. Todo flujo de transacciones tiene un paso más lento, por lo que siempre hay un cuello de botella en alguna parte, y siempre hay un valor máximo de respuesta a la pregunta de cuántos usuarios concurrentes puede manejar un servidor web, y puede haber varios límites. En ese caso, usted quiere establecer su tasa de cola lo suficientemente baja para asegurar que su servidor tiene capacidad de tiempo de cpu para procesar suficiente gente concurrentemente para el paso más lento de su proceso para que la gente no se acumule allí. De lo contrario, su servidor web puede detenerse literalmente.
Nuestra experiencia es que, al iniciar su primera venta, todo el mundo sobrestima la capacidad de sus servidores para hacer frente a grandes volúmenes de tráfico.
Todo el mundo.
Determinar con precisión la duración media de la sesión y el rendimiento del usuario final durante periodos de tráfico lento o punta no es tarea fácil. Lo mejor que puede hacer es ejecutar una prueba de carga adecuada, con clientes "falsos" que realicen el proceso de pedido durante la prueba de carga exactamente como lo harían en la vida real, realizando las mismas solicitudes HTTP en el mismo orden, con las mismas esperas entre páginas durante la prueba de carga que en la vida real, y vigilar la carga del procesador, el rendimiento de E/S y los tiempos de respuesta a medida que aumenta el número de visitantes virtuales. Puedes utilizar Apache JMeter para esto (también nos gusta K6 para cargas más ligeras o máquinas más lentas), pero sea cual sea la herramienta que utilices, lleva mucho tiempo e imitar el comportamiento de cada usuario exactamente de la manera correcta es complicado (especialmente con las complejidades del almacenamiento en caché). Incluso así, toma tu número máximo y redúcelo a la mitad.
A falta de ello, hay que pecar de precavido.
Usted puede cambiar fácilmente la tasa de cola para cualquier cola Queue-Fair en cualquier momento utilizando el portal Queue-Fair. Comience con 10 visitantes por minuto, o su tasa de transacciones en un día más normal, vea cómo va por un tiempo después de que sus entradas salgan a la venta, y si todo se ve bien, la carga de su procesador es baja, su base de datos sql está bien y (sobre todo) sus páginas responden cuando presiona CTRL-SHIFT-R, auméntelo en no más de un 20 por ciento, espere un poco, y repita. Pronto encontrará la tasa real que necesita durante este "equilibrio de carga" (¿ve lo que hicimos allí?), y recuerde, desde el punto de vista de la experiencia del cliente, está bien aumentar la tasa de cola, ya que esto hace que las esperas estimadas que sus clientes en la cola están viendo se reduzcan, y todo el mundo está feliz de ver un tiempo de respuesta que ofrece una espera estimada más corta.
Lo que se quiere evitar es establecer la tasa de cola demasiado alta y luego tener que bajarla, ya que esto a) significa que las personas que utilizan el sitio experimentan cargas de páginas lentas, y b) hace que las esperas estimadas aumenten. ¡Toda la gente en su cola suspirará!
Recuerde que tendrá un cuello de botella en alguna parte de su proceso de pedido -cada transacción tiene un paso más lento- y allí se acumularán varias sesiones. Lo que no quiere hacer es llegar a un minuto de la venta de entradas, ver que la carga del procesador de su servidor está muy por debajo de su número máximo, y aumentar la tasa. Sus visitantes probablemente no han llegado hasta el botón "Comprar ahora". Usted quiere esperar hasta que su base de datos sql esté reportando nuevos pedidos a la misma o similar tasa que su tasa de cola y hacer sus mediciones y pruebas de respuesta entonces. Recuerde que cada vez que aumente la tasa, los visitantes adicionales tardarán el mismo tiempo en llegar a su cuello de botella, por lo que no podrá evaluar con precisión el rendimiento de su servidor con la nueva tasa hasta que haya transcurrido ese tiempo.
Ya hemos hablado de cómo es mejor aumentar la tasa de cola gradualmente una vez que la cola se ha abierto. Probablemente seas consciente de que tus servidores tienen un límite que no puede ser superado sin que el sistema se cuelgue y puede que incluso seas consciente de cuál es el límite - pero lo que puede que no sepas es que cuando la carga se está acercando a este límite, normalmente hay muy pocas señales - a menudo sólo algunos errores o advertencias, o una carga del procesador por encima del 80%.
Cuando los servicios web fallan, tienden a "romperse" o agarrarse muy rápidamente. Normalmente, esto se debe a que, una vez que el sistema ya no puede procesar las solicitudes con la misma rapidez con la que llegan, se acumulan colas internas de procesamiento. Tu sistema tiene entonces que hacer el trabajo de procesar, gestionar y almacenar sus colas internas además de las peticiones, y eso es lo que hace que los servidores se colapsen. Muy rápidamente. Una vez que esto sucede, tus servidores pueden responder durante un tiempo con una página de error, pero esto no te ayuda porque los visitantes que la vean pulsarán inmediatamente Actualizar, agravando la carga.
Incluso antes de eso, si los visitantes tardan más de un segundo en ver tus páginas, pulsan Actualizar. Cuando un visitante pulsa Actualizar, su servidor web no sabe que el visitante ya no está esperando la respuesta a la solicitud original. Si se reciben tanto la solicitud original como la de actualización, el servidor web procesará ambas. Esto significa más trabajo para tu servidor web, respuestas aún más lentas para todos tus visitantes, y más gente pulsando refrescar, resultando en un círculo vicioso que colapsa tu servidor web incluso antes de que empiece a enviar respuestas de error.
Por lo tanto, no fuerces tus servidores más de lo necesario. Ir a por ese último 20% de capacidad de tiempo de cpu no suele merecer la pena el riesgo. Si el tamaño de la cola que se muestra en el Portal Queue-Fair (la figura y la línea amarilla de espera en los gráficos) está disminuyendo o incluso sólo aumentando más lentamente, minuto a minuto, y el tiempo de espera que se muestra es de 50 minutos o menos, entonces usted está procesando los pedidos lo suficientemente rápido y la cola eventualmente se vaciará y dejará de mostrar las Páginas de Cola automáticamente, sin que usted tenga que hacer nada, y sin que tenga que decirle a su jefe que lo presionó demasiado y lo rompió. Al final lo conseguirás siempre que la velocidad del Frente de la Cola sea mayor que el número de Entradas cada minuto (ambos se muestran en el Portal Queue-Fair) - el punto de inflexión suele ser al menos a los pocos minutos de cada evento. Si está vendiendo un producto de cantidad limitada, probablemente se agotará antes de que se alcance el punto de inflexión.
La buena noticia es que si accidentalmente establece la tasa de cola demasiado alta y sus servidores se rompen, Queue-Fair puede ayudarle a volver a funcionar rápidamente - sólo tiene que poner la cola en espera hasta que sus servidores estén listos para manejar los visitantes de nuevo. En el modo de espera, las personas en la cola ven una página especial de espera que puedes diseñar antes de tu evento en línea. No se deja pasar a nadie de la parte delantera de la cola cuando está en Espera, pero los nuevos visitantes de Internet pueden seguir uniéndose a la cola en la parte de atrás, para ser puestos en cola de forma justa una vez que se despeje el bloqueo, lo que ocurrirá muy rápidamente porque Queue-Fair está protegiendo su sitio de la demanda. La Página de Espera es una experiencia de usuario superior a la de poner la Tasa de Cola realmente baja, especialmente si la actualizas para decir a los visitantes a qué hora esperas que se reabra la Cola, lo cual es fácil de hacer con el editor de la página del Portal, incluso cuando cientos de miles de personas ya están en la cola - y en el modo de Espera puedes incluso dejarlos pasar de uno en uno con el botón único de Queue-Fair de Admitir a Uno si lo necesitas mientras tu sistema se recupera de su golpe.
Por lo tanto, si sus servidores necesitan hacer una pausa durante su evento, la página Hold es justo lo que necesita para ello, y además ayudará a sus servidores a recuperarse más rápidamente.
En este artículo hemos explicado por qué una cola basada en la tasa es siempre el camino a seguir, y hemos dado dos métodos para calcular la tasa que necesitas, pero a menos que hayas hecho pruebas de carga de visitantes virtuales completas y precisas en todo tu flujo de transacciones, y estés realmente super extra mega seguro de ello, nuestro consejo es siempre el mismo:
Si vende un producto de cantidad limitada, tampoco necesita prestar atención al paso 7.
Esto es para la primera cola, cuando no se conoce la tasa de cola máxima que puede soportar el sistema. Para las colas posteriores, una vez que haya medido la tasa de cola que su sistema puede soportar realmente, podría utilizar la misma cifra de nuevo, pero sólo si nada ha cambiado en su sistema. En la práctica, es probable que su sistema esté en constante desarrollo y modificación, y puede que no sepa cómo han afectado los cambios recientes a su tasa de cola máxima, así que ¿por qué no empezar con la mitad de la cifra medida anteriormente y repetir el proceso anterior?
Así es como se utiliza Queue-Fair para hacer que su venta sea agradable y segura, y recuerde, siempre es mejor prevenir que curar.
Inventado y patentado en 2004, Queue-Fair es la sala de espera virtual original, que proporciona una gestión de colas en línea para sitios web y aplicaciones de gran actividad.
2024 The Fair Queue People Ltd. - Todos los derechos reservados.
Forma parte de la familia de soluciones de colas Orderly - OrderlyQ - OrderlyStats - WeQ4U
