Cómo el uso de nuestra cola de espera en línea evita la caída del sitio y de la página web: ¿cuántos usuarios simultáneos puede soportar un servidor web?

¿Por qué utilizar una sala de espera virtual basada en tasas?

¿Basada en la tasa o en la salida y entrada? Analizamos los pros y los contras.

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.



La sala de espera virtual mejor valorada de G2
G2 es el sitio web de reseñas de SaaS más visitado del mundo, donde tenemos la puntuación perfecta de 5,0 / 5 estrellas.

Lo que dicen nuestros clientes sobre Queue-Fair


pruebas de carga peticiones http cuantas peticiones aguanta un servidor web sin recursos extra del servidor

¿Cuántos usuarios simultáneos puede manejar un servidor web?

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

¿Cuál es la precisión de un sistema de colas basado en la tasa?

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.

sistema operativo número máximo de recursos del servidor web
cálculo de la cifra media de usuarios concurrentes con intervalo de confianza

¿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!


servers capacity can be exceeced with inaccurate queues 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.

Una forma fácil de calcular la tasa de colas

¿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.

calcular los niveles máximos de usuarios activos para su aplicación web

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.

confusión sobre usuarios concurrentes conexiones concurrentes sesiones concurrentes y duración media de las sesiones

Error #1: Usuarios concurrentes vs. Solicitudes concurrentes vs. Conexiones concurrentes vs. Sesiones concurrentes

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.

Si se equivoca, su sitio web se puede colapsar.

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?

la seguridad es lo primero para los recursos de su servidor cuando calcula cuántas peticiones pueden recibir sus páginas web para una buena experiencia para cada usuario

Convertir solicitudes concurrentes en usuarios concurrentes

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

  1. El número de páginas de su flujo de transacciones
  2. El tiempo medio de transacción del visitante desde la primera hasta la última página de su flujo
  3. Cuántas solicitudes componen cada página, por término medio
  4. El tiempo medio que tarda su servidor en procesar una sola petición HTTP

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:

google procesa un nginx correctamente configurado con google analytics para la subida de fotos

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).

hacer los cálculos para saber cuántas sesiones al mismo tiempo, cuántos usuarios y cuántas peticiones por segundo en su aplicación web, ya sea de servidor único o de contenido estático

Haciendo cuentas

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

Error #2: Los servidores web se vuelven más lentos con la carga

¡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.

cuanto más pesada sea la carga de sus aumentos de tráfico, más lentas serán las máquinas

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.

no se sabe cómo estimar la capacidad de los servidores para cada usuario

¿Y qué hago?

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á!

Error #3: Aumentar la tasa demasiado rápido tras la apertura de una cola

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.

ralentizar la decisión de consumir recursos del servidor
los servidores se rompen cuando se supera la capacidad de los mismos

Error #4: Cómo hacer que sus servidores se ajusten a la realidad

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.

Conclusión

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:

  1. Comience con una tasa de cola establecida en 10, o su tasa de transacción en un día más normal.
  2. Vigila la carga de tu procesador y otros indicadores de rendimiento.
  3. Espere hasta que los nuevos pedidos se registren en su base de datos sql a un ritmo igual o similar al de su tasa de cola.
  4. Pulsa CTRL-SHIFT-R en tus páginas para comprobar la capacidad de respuesta.
  5. Aumentar la tasa de colas en un 20% como máximo.
  6. Vuelva al paso 2 y espere de nuevo.
  7. Una vez que el tamaño de la cola disminuye o se incrementa de forma constante y menos rápida cada minuto, y el tiempo de espera mostrado es inferior a 50 minutos, no es necesario que vaya más rápido.
  8. Siéntese y relájese. Queue-Fair te tiene cubierto.

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.


Cientos de organizaciones líderes confían en nuestras
soluciones de colas

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

La sencilla solución a los aumentos de tráfico en Internet

Empezar a trabajar