la dimensione del traffico è dovuta alla procedura di serializzazione del servizio WCF, che trasforma le istanze delle classi in un nodo xml, accorpando tutte le informazioni per deserializzare il dato ottenendo l’istanza sul client silverlight; nel caso dei verbali le componenti della classe sono numerose, quindi è vasta la descrizione che viene inviata come traffico http (o https)
- Una strada per ottenere una riduzione del traffico è quella di bypassare la serializzazione WCF e scriversi una routine ottimizzata che serializza le entities anziché su un xml, su un flusso di dati binari; occorre anche prevedere una routine di deserializzazione con la capacità di individuare errori nel flusso e richiederne la ritrasmissione. A monte della serializzazione "custom" e dopo la relativa deserializzazione devono rimanere valide le entities del RIA service, per continuare a giovarsi delle avanzate funzionalità introdotte con Silverlight 4. Questa strada appare immediatamente onerosa in termini di effort e rischiosa.
- Un’altra strada è quella di continuare a giovarsi del servizio WCF per la serializzazione, e ridurre il traffico comprimendo a valle l’xml generato, usando un modulo di IIS (peraltro già attivo automaticamente in molte installazioni di IIS 7).
Questa ultima soluzione può sembrare un workaround, ma in realtà rappresenta la risposta migliore al problema del traffico: anche solo perché poggia su componenti software Microsoft già presenti sulle macchine, sicuramente testati e in produzione da anni.
Inoltre, questa soluzione ha il vantaggio di disassare il problema applicativo (già risolto nel caso CDS) dalle considerazioni prestazionali, permettendoci cioè di fare la cosa giusta: occuparci del design e della logica di business, senza deformare il modello per rispondere ad una problematica esterna, quale quella dell'efficienza trasmissiva, almeno un livello OSI sotto (ma probabilmente due) la nostra web-application.
Schematizziamo:
Problema: persistenza e gestione paradigma object oriented in ambiente distribuito.
Risposta: applicazione implementata sulle fondamenta di Silverlight 4 e RIA services
Problema: traffico elevato tra client e server
Risposta: compressione del solo traffico con procedure delegate ad IIS (lato server) e al browser (lato client)
Prova sul campo
Nelle prove effettuate il tempo di trasmissione di dati compressi è molto inferiore al corrispondente tempo per dati non compressi; la compressione è in carico al server, mentre l’operazione di decompressione è in carico al browser (i browser moderni gestiscono automaticamente questa funzionalità); il codice dell’applicazione non è stato toccato (non è stato nemmeno ripubblicato), ci siamo limitati a delegare ad IIS la compressione automatica dei dati xml in uscita dal servizio.
Abbiamo impostato IIS 6 sul server di test in modo che comprima automaticamente i contenuti, se nella GET del browser è impostato l’attributo
Accept-Encoding: gzip, deflateAccept-Encoding: gzip, deflate
I tempi (in connessione vpn) sono passati da 24 secondi a 5 secondi.
Link utili:
- Compressione in IIS 5:
http://technet.microsoft.com/en-us/library/bb742379.aspx - Compressione in IIS 6:
http://programmerpayback.com/2009/02/18/speed-up-your-app-by-compressing-wcf-service-responses/ - Compressione in IIS 7:
http://www.ksingla.net/2006/06/changes_to_compression_in_iis7/
Nessun commento:
Posta un commento