Prestazioni (Service Broker)
Le prestazioni di un'applicazione di Service Broker sono in genere determinate da due fattori:
Numero dei messaggi in arrivo entro un periodo di tempo specificato.
Velocità di elaborazione dei messaggi da parte dell'applicazione.
Il monitoraggio di questi due fattori è fondamentale per ottenere informazioni sulle prestazioni dell'applicazione.
Service Broker dispone di un set di contatori delle prestazioni in grado di offrire informazioni sulle proprie attività. Gli errori gravi vengono inoltre registrati nel log degli errori di SQL Server e nel log eventi applicazioni di Windows. Per ulteriori informazioni sui contatori delle prestazioni, sulle viste a gestione dinamica e sugli eventi di traccia per Service Broker, vedere Monitoraggio (Service Broker).
Ottimizzazione di una stored procedure di Service Broker
In linea di massima l'ottimizzazione di una stored procedure che utilizza Service Broker è analoga all'ottimizzazione di qualsiasi altra stored procedure, salvo alcune considerazioni aggiuntive.
Utilizzare innanzitutto la clausola WAITFOR. I messaggi arrivano raramente a intervalli stimabili. Anche in un servizio in cui i messaggi arrivano pressoché alla stessa frequenza con la quale la stored procedure li elabora, è possibile che in alcuni momenti non vi siano messaggi disponibili. La stored procedure deve pertanto utilizzare la clausola WAITFOR con l'istruzione RECEIVE o GET CONVERSATION GROUP. Senza WAITFOR queste istruzioni restituiscono immediatamente il controllo all'applicazione quando non vi sono messaggi disponibili nella coda. A seconda dell'implementazione della stored procedure, può verificarsi un ciclo all'interno dell'istruzione, con un inutile consumo di risorse, oppure la stored procedure può venire chiusa solo per essere riattivata subito dopo, consumando ancora più risorse.
Per ovviare all'impossibilità di stimare gli intervalli tra i messaggi, utilizzare la clausola WAITFOR con l'istruzione RECEIVE o GET CONVERSATION GROUP. Se l'applicazione è in esecuzione continua come servizio in background, evitare di specificare un timeout nell'istruzione WAITFOR. Se l'applicazione viene attivata da Service Broker o viene eseguita come processo pianificato, impostare un timeout breve, ad esempio 500 millisecondi. Un'applicazione che utilizza l'istruzione WAITFOR è in grado di gestire correttamente gli intervalli non stimabili tra i messaggi. In modo analogo, un'applicazione attivata e quindi chiusa dopo un breve timeout non consuma risorse quando non vi sono messaggi da elaborare.
Service Broker garantisce che solo un'istanza dell'applicazione alla volta riceve messaggi per conversazioni che condividono lo stesso identificatore del gruppo di conversazioni. Si consiglia di progettare le applicazioni in modo che utilizzino la funzionalità di blocco del gruppo di conversazioni per la sincronizzazione. Se l'applicazione mantiene informazioni sullo stato, considerare la possibilità di utilizzare l'identificatore del gruppo di conversazioni per identificare lo stato della conversazione. Elaborare più messaggi di un gruppo di conversazioni nella stessa transazione. In genere, tuttavia, in una transazione specifica è opportuno elaborare solo i messaggi per un unico gruppo di conversazioni. In questo modo si garantisce che più istanze dell'applicazione siano in grado i elaborare i messaggi, anche quando il numero di gruppi di conversazioni è relativamente limitato.
Evitare inoltre di utilizzare la funzionalità di memorizzazione dei messaggi. La gestione di una tabella di log separata per il salvataggio delle informazioni più importanti di un messaggio consente prestazioni migliori. Utilizzare la memorizzazione dei messaggi solo se per l'applicazione sono necessari i messaggi esattamente come sono stati inviati e ricevuti.
Terminare quindi le conversazioni al completamento dell'attività. Service Broker mantiene informazioni sullo stato di ogni conversazione attiva. La quantità di tali informazioni per una conversazione specifica è limitata. Tuttavia, le prestazioni di un'applicazione che non termina le conversazioni possono man mano ridursi.
Infine mantenere brevi le transazioni. Se, ad esempio, il modello di conversazione per il servizio comporta un numero elevato di messaggi nello stesso gruppo di conversazioni, la limitazione del numero di messaggi elaborati in ogni transazione può migliorare nel complesso la velocità effettiva.
Vedere anche