Recentemente ho eseguito alcuni test delle prestazioni e analisi di un'applicazione ASP.NET utilizzando lo stato di sessione out-of-process, necessario quando si utilizza lo stato di sessione in una Web farm in modo che lo stato possa essere recuperato su uno qualsiasi dei server Web, ad es se successive richieste HTTP arrivano a un server diverso perché le sessioni non sono "appiccicose" o il server originale è inattivo, ecc.Possibili soluzioni a prestazioni scadenti di serializzazione
Ciò che mi ha sorpreso è che quando eseguivo i server Web a pieno carico e profilavo l'utilizzo della CPU qualcosa come il 99% del tempo della CPU è stato impiegato per serializzare e deserializzare lo stato della sessione. Successivamente abbiamo implementato un server di stato "caching" personalizzato; questo sempre serializza lo stato ma mantiene anche lo stato in memoria in modo tale che se si usano sessioni adesive lo stato non deve essere deserializzato il più delle volte. Questo ha migliorato il throughput del server di un fattore 2; Tuttavia, la serializzazione rappresenta ancora il 98% o più del tempo di CPU.
Abbiamo ottenuto ulteriori miglioramenti in termini di velocità tagliando i riferimenti di oggetti non necessari tra gli oggetti nello stato della sessione prima della serializzazione, risolvendo manualmente i riferimenti dopo la desrializzazione. Questa velocità migliorata di un altro 10-20% circa. Il ragionamento qui è che parte della perdita di prestazioni è dovuta alla serializzazione incorporata che deve percorrere il grafico dei puntatori di oggetti, che diventa un compito più complesso con più puntatori.
Continuando l'indagine abbiamo scritto routine di serializzazione personalizzate per alcune delle nostre classi piuttosto che basarci sulla serializzazione integrata di .Net. Quello che abbiamo trovato è stato che la performance era notevolmente migliorata, di un fattore di circa 50x. Sembra che la maggior parte del carico della CPU sia causata dalla serializzazione .Net, che a sua volta è lenta a causa dell'utilizzo di Reflection per percorrere i puntatori/grafici degli oggetti ed estrarre i dati del campo.
È molto allettante aumentare le nostre prestazioni di 50 volte, riducendo così i requisiti hardware del server Web di un fattore importante (e i requisiti di alimentazione di un fattore minore ma ancora significativo). Le opzioni attualmente disponibili sono:
1) Scrivi la serializzazione personalizzata. Questo è un problema dovuto alla complessità del task e al sovraccarico di manutenzione che genera, ovvero qualsiasi modifica allo stato della classe richiede una modifica alle routine di serializzazione/deserializzazione.
2) Alcune soluzioni di terze parti. Forse un prodotto che genera automaticamente il salvataggio/caricamento di stato in fase di compilazione, eliminando così la necessità di utilizzare Reflection.
Sarei molto interessato a sapere se qualcuno sa di una soluzione di terze parti, o ha riscontrato questo problema in quanto non ho trovato alcuna menzione da ricerche su Internet.
AGGIORNAMENTO: Alcuni hanno suggerito una sorta di soluzione a metà strada tra la serializzazione incorporata predefinita e le routine di serializzazione personalizzate. L'idea è di implementare la serializzazione personalizzata per le classi che influiscono maggiormente sulle prestazioni, ad es. eccessiva ISerializable. Questo è un approccio interessante e promettente; Tuttavia ritengo ancora che ci sia spazio per una sostituzione completa della serializzazione integrata senza dover scrivere e mantenere alcun codice personalizzato - questo non può essere fatto in fase di esecuzione perché Reflection è necessario per interrogare oggetti e accedere ai dati privati. Ma è teoricamente possibile post-elaborare gli assembly già costruiti e iniettare nuovi metodi come passo aggiuntivo. Alcuni profiler usano questo approccio per iniettare il codice di profilazione negli assembly dopo che sono stati compilati dal compilatore C#. Anch'io penso/leggo da qualche parte che il framework .Net supporti i metodi di iniezione in classi - quindi tutto il caos con IL è potenzialmente preso in considerazione.
Abbastanza sicuro che i metodi di iniezione di cui si parla sarebbero l'uso di classi parziali. Penso che il principio sia se due classi nello stesso namespace hanno lo stesso nome e una è contrassegnata come parziale. Una dll è prodotta incorporando metodi e proprietà di entrambe le classi. – Robert