PowerShell Universal permite a los usuarios crear API con PowerShell. Estas API pueden usarse para crear webhooks, integrarse con otros sistemas o ofrecer una API REST para sus scripts de PowerShell. En este artículo, veremos algunos cambios que puede aplicar para mejorar el rendimiento de los endpoints de API.
En este artículo, hemos usado West Wind WebSurge para probar el rendimiento de las API. Esta herramienta permite enviar un número de solicitudes a una URL y medir su rendimiento. Ejecutamos una prueba de 60 segundos con 10 threads.
Para esta prueba, ejecutamos una versión sin licencia de PowerShell Universal con un solo endpoint de API. El endpoint de API es un script sencillo que devuelve una cadena.
New-PSUEndpoint -Url "/hello" -Method @('GET') -Endpoint {
"hello"
}
Usamos LiteDB para la persistencia.
Actualizar a la 4.1.5 o posterior
Lo primero que puede hacer es actualizar a PowerShell Universal 4.1.5 o posterior. Esta versión incluye varias mejoras de rendimiento del sistema de API. Con esta versión y la configuración predeterminada, vemos alrededor de un 300 % de mejora en el rendimiento de las API.
Resultados:
- 4.1.4 con la configuración predeterminada: 150 solicitudes por segundo
- 4.1.5 con la configuración predeterminada: 470 solicitudes por segundo
Ajustar los destinos de registro y la configuración del registro del sistema
De forma predeterminada, PowerShell Universal tiene registros detallados configurados. Aplicaremos los siguientes cambios a la configuración de registro.
Deshabilitar los registros detallados del sistema
En appsettings.json, establezca SystemLogLevel en Error en lugar de Verbose.
{
"SystemLogPath": "%ProgramData%\\PowerShellUniversal\\systemLog.txt",
"SystemLogLevel": "Error"
}
Deshabilitar el registro de ámbito de usuario para las API
En lugar de enviar mensajes de registro a la base de datos y al sistema de archivos, deshabilitaremos el registro de ámbito de usuario para las API. Puede enviar mensajes de registro para características concretas, como Apps.
New-PSULoggingTarget -Type "Database" -Properties @{
} -Feature "App"
New-PSULoggingTarget -Type "File" -Properties @{
path = "C:\ProgramData\PowerShellUniversal\log.txt"
} -Feature "App"
También es posible reducir el nivel de registro de los destinos en lugar de deshabilitarlos por completo.
New-PSULoggingTarget -Type "Database" -Properties @{
} -Level "Error"
New-PSULoggingTarget -Type "File" -Properties @{
path = "C:\ProgramData\PowerShellUniversal\log.txt"
} -Level "Error"
Resultados:
- 4.1.4: 980 solicitudes por segundo
- 4.1.5: 1.200 solicitudes por segundo
Configuración del entorno
Ciertas características de los entornos de PowerShell Universal pueden afectar al rendimiento. Aplicaremos los siguientes cambios a la configuración del entorno.
Runspaces persistentes
Restablecer el estado del runspace lleva tiempo, así que evitarlo puede mejorar el rendimiento. Tenga en cuenta que los runspaces persistentes conservan el valor de las variables, funciones y alias definidos durante la ejecución del endpoint. Según la implementación de su endpoint, esto puede no ser deseable.
Aumentar el máximo de runspaces
De forma predeterminada, PowerShell Universal crea 25 runspaces por entorno. Lo aumentaremos a 100. Esto incrementará el uso de memoria, pero mejorará ligeramente el rendimiento.
New-PSUEnvironment -Name "Integrated" -Version "7.3.6" -Path "Universal.Server" -Variables @('*') -PersistentRunspace -MaxRunspaces 100 -Description "An environment for running scripts directly in the PowerShell Universal server."
Resultados:
- 4.1.4: 1.025 solicitudes por segundo
- 4.1.5: 1.300 solicitudes por segundo
Una nota sobre los entornos externos
Arriba verá que usamos el entorno Integrated. Es un entorno integrado en PowerShell Universal. Es un entorno de PowerShell que se ejecuta directamente en el proceso de PowerShell Universal. Incluso si ajustáramos los endpoints para usar un entorno externo, los resultados son similares. Esto se ejecuta en un entorno de PowerShell 7.3.7.
- 4.1.4: 1.015 solicitudes por segundo
- 4.1.5: 1.250 solicitudes por segundo
Usar persistencia SQL
La persistencia SQL puede mejorar mucho el rendimiento de las API. Esta prueba se realizó contra una base de datos SQL local, con todos los ajustes anteriores configurados y solo en la versión 4.1.5.
Resultados:
- 4.1.5: 2.900 solicitudes por segundo
Conclusión
Con estos cambios, hemos mejorado el rendimiento de nuestra API en alrededor de un 1.900 %. Hemos pasado de 150 solicitudes por segundo a unas 2.900 solicitudes por segundo. La persistencia SQL produjo el mayor aumento de rendimiento. Combinada sobre todo con los cambios del sistema de registro, puede lograr un incremento significativo.
Envíenos comentarios o preguntas en los foros.
¿Listo para crear? Descargue PowerShell Universal.

Adam Driscoll