¿Afecta SWEAR al rendimiento de XProtect?
En resumen
El impacto de SWEAR en su entorno de XProtect es mínimo.
El procesamiento hash que SWEAR realiza en los videos de seguridad no modifica ni altera ninguna de sus grabaciones y tiene un impacto mínimo en los procesadores y el uso de memoria de los servidores de XProtect. El uso de ancho de banda del sistema SWEAR genera aproximadamente medio megabyte de hashes por cada hora de video y por cámara, y después envía esos hashes a un registro respaldado por una cadena de bloques.
Explicación
Qué hace SWEAR durante la ejecución
SWEAR se integra con Milestone XProtect para añadir protección de autenticidad durante las operaciones normales de video mediante las siguientes acciones:
- Lee los datos de transmisión de las cámaras desde el flujo de trabajo de grabación
- Genera registros hash criptográficos deterministas a partir de los datos de video
- Pone en cola y carga esos registros hash mediante la API de SWEAR
SWEAR no:
- Vuelve a codificar ni transcodifica el video de las cámaras
- Sustituye los servicios de grabación o reproducción de Milestone
- Exporta video sin procesar a la infraestructura de SWEAR
Por este motivo, el efecto práctico en el funcionamiento del VMS suele ser insignificante en las operaciones cotidianas.
Por qué el impacto suele ser bajo
El coste durante la ejecución se concentra en el procesamiento hash y en el procesamiento de la cola y las cargas, no en trasladar cargas completas de video fuera del grabador. Los registros hash son pequeños, el tráfico saliente es ligero y el procesamiento se ajusta principalmente en función de la tasa de bits protegida total (cantidad de cámaras x tasa de bits por cámara).
En condiciones estables, esto suele implicar:
- Uso de CPU bajo a moderado en relación con los núcleos disponibles del servidor
- Consumo moderado de memoria de trabajo
- Tráfico de red saliente continuo y reducido exclusivamente para cargar registros hash
- Actividad de disco predecible debido a la persistencia de la cola local (ciclo de inserción y eliminación)
Cómo se ajusta el rendimiento
Según supuestos de modelado durante la ejecución (no pruebas comparativas directas sobre el terreno), el comportamiento aproximado en condiciones estables es el siguiente:
| Recurso | 10 cámaras | 50 cámaras | 200 cámaras | Factor principal |
|---|---|---|---|---|
| CPU (condiciones estables) | ~1-3% de 1 núcleo | ~5-15% de 1 núcleo | ~0.2-0.6 núcleos | Procesamiento hash + procesamiento de fotogramas/NAL |
| Conjunto de trabajo (RAM) | ~90-130 MB | ~120-180 MB | ~200-350 MB | Base del servicio + procesos por cámara + búferes |
| Tráfico de red saliente | ~1 KB/s | ~5 KB/s | ~20 KB/s | Solo solicitudes POST de registros hash a la API |
| Actividad de escritura en disco | ~3-8 KB/s | ~15-40 KB/s | ~50-150 KB/s | Ciclo de vida de la cola local duradera |
Estos valores aumentan o disminuyen según la tasa de bits y el perfil de la cámara (por ejemplo, las transmisiones 4K con una tasa de bits superior aumentan la carga de trabajo de manera proporcional).
Cuándo podría notar un impacto temporal
Es más probable que se produzcan picos breves en situaciones excepcionales, especialmente durante:
- Períodos de procesamiento de datos atrasados o de puesta al día: después de reiniciar el servicio o tras una interrupción, SWEAR procesa más rápido el trabajo histórico pendiente para volver al límite de la transmisión en directo
- Interrupciones de la API o la red: los registros pendientes se acumulan; cuando se restablece la conectividad, aumenta la actividad de carga mientras se completa el trabajo pendiente
- Períodos prolongados con el registro detallado activado: el crecimiento de los registros puede adquirir relevancia operativa en discos con capacidad limitada
Por lo general, estas condiciones son operativas y recuperables, y no corresponden al comportamiento normal en condiciones estables.
Recomendaciones prácticas para un rendimiento estable
Para que el rendimiento de SWEAR sea predecible en entornos de Milestone:
- Proteja únicamente los canales de cámara previstos
- Supervise la tendencia de la cola y el estado de las cargas en la vista de estado de SWEAR
- Mantenga rutas de red fiables hacia los puntos de conexión de la API de SWEAR
- Utilice los niveles normales de registro de producción, salvo que esté solucionando problemas activamente
- Planifique la capacidad según la tasa de bits protegida total, no solo según la cantidad de cámaras
Indicadores para solucionar problemas
Utilice estos patrones para diferenciar un estado correcto de una situación de presión:
- Estado correcto: tanto los registros generados como los cargados aumentan y la cola permanece estable
- Acumulación de trabajo pendiente: los registros generados aumentan más rápido que los cargados y la cola crece con el tiempo
- Presión o fallo de carga: los contadores de registros fallidos o atrasados aumentan reiteradamente y la cola no se vacía
Si el trabajo pendiente o los fallos persisten, compruebe el estado del servicio, la accesibilidad de la API y las condiciones del registro y el disco; después, póngase en contacto con soporte e incluya los contadores de estado actuales y el período de observación.