Condividi tramite

Procedure consigliate per le prestazioni on/off

  • Articolo

Piattaforma

Clienti- Windows Vista | Windows 7
Server- Windows Server 2008 | Windows Server 2008 R2

Descrizione

Gli stati di alimentazione del sistema (o S-states), come definito nella specifica ACPI (Advanced Computer Power Interface), vengono chiamati in modo colloquiale sugli stati on/off perché la transizione di stato S più comune è un computer che si accende e disattiva. Le diverse transizioni di stato on/off in un sistema che esegue Windows Vista o Windows 7 sono di avvio, sospensione (ACPI S3), ibernazione (ACPI S4) e arresto.

Buone prestazioni durante queste transizioni on/off non solo migliora la qualità percepita di un computer, ma influisce anche notevolmente sui modelli di utilizzo giornaliero del computer e sull'affidabilità del sistema. I clienti possono diventare frustrati dai sistemi che richiedono troppo tempo per l'avvio o l'arresto. I sistemi mobili con lunghe transizioni di sospensione e ibernazione possono esaurire inutilmente la durata della batteria. I tempi di arresto più lunghi possono anche influire negativamente sull'affidabilità dei sistemi mobili. Ad esempio, aumentano il rischio di tagli di alimentazione imprevisti.

Le estensioni di sistema, ad esempio driver, applicazioni e servizi, possono avere un impatto significativo sui tempi di transizione su/off. Questa sezione illustra alcune delle procedure consigliate che gli sviluppatori di applicazioni e servizi possono seguire per evitare ritardi durante l'avvio, lo standby e l'arresto e per garantire un'esperienza utente post-avvio e post-ripresa reattiva. Per altre informazioni su come identificare i problemi di prestazioni on/off usando Windows Performance Toolkit e implementare le raccomandazioni seguenti per l'applicazione o il servizio, fare riferimento ai white paper nella sezione "Collegamenti ad altre risorse".

Procedure consigliate

  • Usare Windows Performance Toolkit per misurare le prestazioni durante tutte le transizioni on/off.
  • Eseguire test in modo controllato ed eseguire confronti con una baseline valida:
    • Ottenere una misurazione di base in un sistema con il minor numero possibile di estensioni di sistema
    • Aggiungere applicazioni e servizi uno alla volta
    • Testare le regressioni inaccettabili nei tempi di transizione on/off
  • Evitare di usare il codice gestito per le applicazioni nel percorso di avvio critico.
  • Assicurarsi che tutte le applicazioni rispondano rapidamente alle notifiche di arresto (WM_QUERYENDSESSION e WM_ENDSESSION messaggi).
  • Ridurre i ritardi nel percorso di arresto dei servizi e delle applicazioni riducendo al minimo l'attività di CPU, disco e rete in risposta alle notifiche di arresto.
  • Evitare ritardi nell'elaborazione della notifica di sospensione (WM_POWERBROADCAST messaggio).
  • Rispondere rapidamente agli eventi di ripresa e ridurre al minimo l'utilizzo della CPU, del disco e della rete post-ripresa.
  • Ridurre l'utilizzo delle risorse dell'applicazione dopo l'avvio.
  • Non avviare le applicazioni dalla chiave RunOnce in ogni avvio.
  • Convertire tutti i servizi non essenziali per avviare o attivare l'avvio della richiesta per rendere disponibili le risorse di sistema durante l'avvio.
  • Evitare di usare gruppi di ordini di carico per esprimere le dipendenze del servizio.
  • Assicurarsi che tutti i servizi in esecuzione segnalano questo stato appena possibile durante l'avvio per evitare di bloccare Service Control Manager (SCM).
  • Evitare di usare il codice gestito per i servizi nel percorso di avvio.
  • Non consentire ai servizi di acconsentire esplicitamente a ricevere notifiche di pre-arresto e arresto (SERVICE_CONTROL_PRESHUTDOWN e SERVICE_CONTROL_SHUTDOWN codici di controllo) a meno che non sia assolutamente necessario.
  • Assicurarsi che tutti i servizi che hanno scelto di ricevere le notifiche di arresto rispondano rapidamente a SCM.
  • Verificare che i servizi non acconsentono a ricevere notifiche di sospensione, a meno che non sia assolutamente necessario.
  • Assicurarsi che tutti i servizi rispondano rapidamente per riprendere gli eventi e ridurre al minimo l'utilizzo della CPU, del disco e della rete post-ripresa.