Ottimizzare le prestazioni delle API in PowerShell Universal: miglioramenti chiave e risultati

PowerShell Universal consente agli utenti di creare API con PowerShell. Queste API possono servire a creare webhook, integrarsi con altri sistemi o offrire un’API REST per i suoi script PowerShell. In questo articolo vedremo alcune modifiche che può apportare per migliorare le prestazioni degli endpoint API.

In questo articolo abbiamo usato West Wind WebSurge per testare le prestazioni delle API. Questo strumento consente di inviare un certo numero di richieste a un URL e di misurarne le prestazioni. Eseguiamo un test di 60 secondi con 10 thread.

Per questo test eseguiamo una versione senza licenza di PowerShell Universal con un solo endpoint API. L’endpoint API è uno script semplice che restituisce una stringa.

New-PSUEndpoint -Url "/hello" -Method @('GET') -Endpoint {
    "hello"
}

Usiamo LiteDB per la persistenza.

Aggiornare alla 4.1.5 o successiva

La prima cosa che può fare è aggiornare a PowerShell Universal 4.1.5 o successiva. Questa versione include diversi miglioramenti delle prestazioni del sistema API. Con questa versione e le impostazioni predefinite vediamo circa il 300% di miglioramento delle prestazioni API.

Risultati:

• 4.1.4 con le impostazioni predefinite: 150 richieste al secondo
• 4.1.5 con le impostazioni predefinite: 470 richieste al secondo

Regolare le destinazioni di logging e le impostazioni del log di sistema

Per impostazione predefinita, PowerShell Universal ha log dettagliati configurati. Apporteremo le seguenti modifiche alla configurazione del logging.

Disabilitare i log di sistema dettagliati

In appsettings.json, imposti SystemLogLevel su Error anziché Verbose.

{
    "SystemLogPath": "%ProgramData%\\PowerShellUniversal\\systemLog.txt",
    "SystemLogLevel": "Error"
}

Disabilitare il logging con ambito utente per le API

Invece di inviare messaggi di log al database e al file system, disabiliteremo il logging con ambito utente per le API. Può inviare messaggi di log per funzionalità specifiche, come Apps.

New-PSULoggingTarget -Type "Database" -Properties @{
} -Feature "App"

New-PSULoggingTarget -Type "File" -Properties @{
    path = "C:\ProgramData\PowerShellUniversal\log.txt"
} -Feature "App"

È anche possibile ridurre il livello di log delle destinazioni invece di disabilitarle del tutto.

New-PSULoggingTarget -Type "Database" -Properties @{
} -Level "Error"

New-PSULoggingTarget -Type "File" -Properties @{
    path = "C:\ProgramData\PowerShellUniversal\log.txt"
} -Level "Error"

Risultati:

• 4.1.4: 980 richieste al secondo
• 4.1.5: 1.200 richieste al secondo

Impostazioni dell’ambiente

Alcune funzionalità degli ambienti di PowerShell Universal possono influire sulle prestazioni. Apporteremo le seguenti modifiche alle impostazioni dell’ambiente.

Runspace persistenti

Reimpostare lo stato del runspace richiede tempo, quindi evitarlo può migliorare le prestazioni. Tenga presente che i runspace persistenti conservano il valore di variabili, funzioni e alias definiti durante l’esecuzione dell’endpoint. A seconda dell’implementazione dell’endpoint, questo potrebbe non essere desiderabile.

Aumentare i runspace massimi

Per impostazione predefinita, PowerShell Universal crea 25 runspace per ambiente. Li aumenteremo a 100. Questo aumenterà l’uso della memoria, ma migliorerà leggermente le prestazioni.

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

Risultati:

• 4.1.4: 1.025 richieste al secondo
• 4.1.5: 1.300 richieste al secondo

Una nota sugli ambienti esterni

Sopra potrà notare che usiamo l’ambiente Integrated. È un ambiente integrato in PowerShell Universal. È un ambiente PowerShell che viene eseguito direttamente nel processo di PowerShell Universal. Anche se adattassimo gli endpoint per usare un ambiente esterno, i risultati sono simili. Questo viene eseguito in un ambiente PowerShell 7.3.7.

• 4.1.4: 1.015 richieste al secondo
• 4.1.5: 1.250 richieste al secondo

Usare la persistenza SQL

La persistenza SQL può migliorare molto la velocità effettiva delle API. Questo test è stato eseguito su un database SQL locale, con tutte le impostazioni precedenti configurate e solo sulla versione 4.1.5.

Risultati:

• 4.1.5: 2.900 richieste al secondo

Conclusione

Con queste modifiche abbiamo migliorato le prestazioni della nostra API di circa il 1.900%. Siamo passati da 150 richieste al secondo a circa 2.900 richieste al secondo. La persistenza SQL ha dato il maggiore aumento di prestazioni. Combinata soprattutto con le modifiche al sistema di logging, può ottenere un incremento significativo.

Ci scriva per feedback o domande sui forum.

Pronto a iniziare a creare? Scarichi PowerShell Universal.