Disponibile l'upgrade della ROM, dello stack radio per il nuovissimo JasJar. Vi consiglio di controllare prima la versione in Settings / Device Information prima di eseguire l'upgrade in quando l'upgrade "spiana" il device.
Questo il link http://www.clubimate.com/t-DEVICE_JASJAR_UPD.aspx: occorre iscriversi a Club iMate.
La versione nuova è
Rom version: 1.13.53
Radio version: 1.03.01
ExtROM version: 1.13.137
Sono solo 61 Mb di download :-)
Consiglio: chiudere veramente tutte le app sul desktop. A me ha dato problemi di installazione con Messenger attivo.
Visto che siamo alla versione RC ho pensato di fare qualche Stress Test (usando VSTS) su diverse pagine sincrone e asincrone per vedere se si riesce ad arrivare al miglioramento di performance a cui si arriva nella versione 1.x implementando a mano (con conseguente bagno di sangue :-))IHttpAsyncHandler. La differenza nel codice sta appunto nel non aver più bisogno di implementare IHttpAsyncHandler con tutti i "problemi", ma utilizzare l'attributo Async="true" direttamente nella direttiva Page: vi sono poi varie tecniche per gestire le operazioni asincrone da pagine, controlli, user control custom, eventi di HttpApplication e moduli custom, ma per mantenere il primo esempio semplice (e di uso comune) ho semplicemente utilizzato il pattern Event-based. La prova che pubblico per adesso si basa su una pagina che richiama un web service. Il Web Service impiega circa 2 secondi per elaborare la richiesta. Premetto che il Web Service in quanto tale non implementa logiche asincrone e accede al database in modo tradizionale (senza comandi Begin/End con ADO.NET 2.0 per capirci: sarà la mia prossima prova).
Test: 25 utenti concorrenti che senza think time bombardano la pagina. IIS e ASP.NET sono configurati con Thread Pool di default.
Pagina sincrona che chiama un solo web service in modo sincrono:
Pagina sincrona che chiama un solo web service in modo asincrono (Begin/End classico):
Pagina asincrona che chiama un solo web service in modo asincrono (Event-Based):
Ho inserito i counter più interessanti come Numero di Thread e Richieste in Coda, Request Execution Time.
Come si nota, nella pagina sincrona che chiama il WS con Begin/End il numero di richieste in coda è 14: questo perchè vi sono molti thread bloccati ad aspettare il termine delle chiamate e quindi non sono liberi di eseguire altre richieste (Begin/End in ASP.NET 1.x e 2.0 liberano il thread corrente ma impegnano un altro thread dello stesso thread pool per eseguire la richiesta asincrona). Il numero dei thread in questione è superiore a una chiamata sincrona verso il web service. Tutto questo non dovrebbe stupire: è così dal 12 febbraio 2002 quando è uscito ASP.NET 1.0.
La cosa interessante è la prova con la 2.0 che utilizza una pagina asincrona per fare lo stesso lavoro. Le pagine asincrone implementano dietro le quinte IHttpAsyncHandler e quindi si arriva a un risultato simile a quanto nelle versione 1.x richiede molte righe di codice. A parte le righe di codice da non scrivere (non è mai stato un problema per noi sviluppatori, altrimenti che ci stiamo a fare ? :-)) la cosa interessante è che siamo in una Page ! Vuol dire che possiamo lavorare come in una pagina tradizionale usando User Control, Eventi, Master Page, Theme.
Detto questo non ha senso mettere nel web.config globale async=true per tutte le pagine !
Mi sono arrivate 4 mail in due giorni per sapere se a DevCon 2005 faremo qualcosa su Visual Studio Team System. Condivido la risposta.
Certo. L'applicazione Estates Management che usiamo nel track Architettura e Implementazione è stata scritta utilizzando quasi tutte le funzionalità di VSTS, quindi il prodotto ci accompagnerà in molte demo e ci servirà per inquadrare l'architettura della soluzione. Inoltre lo useremo nel parlare di ASP.NET 2.0 mettendo in evidenza pro e contro di alcune scelte "di codice" appoggiandosi al suo motore per effettuare Stress Test.
I due Diagram di VSTS per Estates Management (AD e LDD) sono stati pubblicati in questo post: http://blogs.devleap.com/rob/archive/2005/08/20/5545.aspx