Preguntas más frecuentes sobre QPS
QPS se define como consultas por segundo. En el caso de los licitadores externos, QPS se usa para describir el número total de solicitudes de puja que se pueden enviar por segundo. La implementación de QPS se realiza a través del campo qps_limit
, en el bidder_instance
objeto . Esto permite al licitador externo establecer un tráfico máximo que se va a enviar a por centro de datos.
El propósito de QPS para los licitadores externos es asegurarse de que los servidores del licitador no reciben más tráfico del que pueden procesar. No está pensado para ser la cantidad óptima de tráfico. El licitador puede recibir tráfico inferior al qps_limit
valor, según el inventario disponible, la configuración de los perfiles del licitador y el rendimiento de su licitador. Por ejemplo, esta es una configuración de instancia del licitador:
{"id": 12345,
"active": true,
"datacenter_id": 6,
"port": 80,
"hostname": "dsp.goodstuff.com",
"qps_limit": 1000}
Esta instancia está configurada para recibir un máximo de 1000 solicitudes de puja por segundo.
Echemos un vistazo al tráfico disponible para este licitador:
Figura 1
Esto es lo que se envía a este postor:
Figura 2
A medida que el inventario disponible fluctúa (debido al comportamiento normal de navegación web humana), las solicitudes de puja enviadas al licitador también fluctúan de forma similar. Dado que este licitador ha establecido el qps_limit
valor en 1000, el tráfico se limita a ese valor y esto se refleja en la figura 2.
La figura 1 muestra que el tráfico fluctúa de un mínimo de 50 000 a un máximo de 175 000. La figura 2 muestra que el postor ha recibido de un mínimo de 400 a un máximo de 1000 (el qps_limit
valor).
Hay 7 métricas clave que se usan para determinar las solicitudes de puja finales enviadas. En las dos tablas siguientes se detallan estas métricas y cómo se usan.
Tabla 1
Métricas de la interfaz de usuario del licitador | Description |
---|---|
Solicitudes de puja: intento | Número de intentos de realizar una única solicitud de puja. |
Solicitudes de puja: disponibles | Número de subastas que están disponibles para un postor, independientemente de si ese licitador las filtra o no. |
Solicitudes de puja: perfil filtrado | Número de subastas que el perfil de un postor filtró |
Solicitudes de puja: enviadas | Número de intentos que una solicitud de puja envió correctamente |
Solicitudes de puja: volumen filtrado | Número de subastas que no enviaron una solicitud de puja debido a la limitación |
Otro: pct de error de conexión | Porcentaje de bid_requests que se anularon debido a la imposibilidad de conectarse al licitador. |
Tiempo de espera: % de tiempo de espera | Porcentaje de bid_requests que agotó el tiempo de espera |
Tabla 2
Métricas | ¿Cuándo se cuenta? |
---|---|
Solicitudes de puja: intento | Después de todo el filtrado, pero antes del filtrado QPS |
Solicitudes de puja: disponibles | Después del filtrado del lado de la venta antes de aplicar los perfiles del licitador |
Solicitudes de puja: perfil filtrado | Después del filtrado del lado de la venta y después de que los perfiles del licitador excluyeron la subasta |
Solicitudes de puja: enviadas | Una vez que hayamos enviado correctamente la solicitud al licitador. |
Solicitudes de puja: volumen filtrado | Una vez que un licitador es apto y sus perfiles incluyen la subasta, pero los perfiles tienen límite establecido (passthrough_percent campo) |
Otro: pct de error de conexión | El licitador es apto para pujar y no responde a una solicitud de puja porque no se pudo establecer una conexión. |
Tiempo de espera: % de tiempo de espera | El licitador es apto para pujar y no responde dentro del límite de tiempo |
Antes de calcular el valor Bid requests - Sent (Solicitudes de puja: enviado), merece la pena revisar cómo determinamos qué solicitudes de puja están disponibles.
Los vendedores tienen controles que pueden limitar qué licitadores pueden recibir tráfico. Cuando un vendedor bloquea a los miembros compradores de un postor en las Reglas de calidad del anuncio, ese postor no recibirá solicitudes de puja de ese vendedor. Los vendedores también pueden usar un perfil de visibilidad para impedir que las solicitudes de puja se envíen a un postor.
La métrica Timing – Timeout % consta de tres componentes:
- El licitador ha enviado una respuesta a la oferta, pero la respuesta de la oferta no se recibió a tiempo para ser elegible para la subasta.
- El licitador no ha enviado una respuesta a la oferta a la subasta.
- El licitador ha enviado una respuesta a la oferta y es elegible para la subasta, sin embargo, la respuesta de la oferta llegó hacia el final del tiempo máximo permitido. Hay solicitudes de puja que han estado esperando para enviarse que se agotarán el tiempo de espera, ya que el adserver ha determinado que el postor no puede responder a tiempo.
Este es un ejemplo de una solicitud de puja que se agotó el tiempo de espera en una conexión determinada, ya que solo se puede enviar una solicitud de puja en una conexión determinada a la vez (con un tiempo máximo predeterminado permitido de 100 ms):
- Tiempo 0 ms: solicitud de puja 1 enviada a su postor
- Tiempo 1 ms: solicitud de puja 2 en cola
- Tiempo 1,5 ms: solicitud de puja 3 en cola
- Tiempo 99 ms: respuesta de la oferta 1 recibida
- Tiempo 100 ms: solicitud de puja 2 enviada
- Tiempo de 102 ms: se agotó el tiempo de espera de la solicitud de puja 3 antes de que se enviara la solicitud.