Oggi mi è capitato un caso molto strano su cui da tempo tutti i componenti del team avevano sotto il naso una situazione che non si riuscivano a spiegare.

Una applicazione (in futuro sarà un servizio) in .NET utilizzava un servizio per processare dei dati. Vista la natura dell’elaborazione ci aspettavamo che utilizzando molti thread saremmo riusciti a lavorare un gran numero di documenti grazie a server particolarmente prestanti.

Purtroppo questo non avveniva e le macchine erano costantemente sotto il 25% di utilizzo nonostante avessimo aumentato il numero di thread dell’applicazione.

Solo grazie ad un problema uno dei componenti del team nota una singolare situazione. I thread sull’IIS in attesa di essere smistati dal servizio di elaborazione sullo stesso server sono un numero incongruente con le nostre previsioni. Anzi, un numero costante: 2

Dopo aver riprodotto in laboratorio il medesimo comportamento ci è sembrato plausibile ci fosse una limitazione da qualche parte.

IIS non poteva sicuramente essere visto che, fosse anche solo per esperienza diretta, lo abbiamo visto con diverse centinaia di thread aperti simultaneamente.

Qualche altra ricerca ci ha portato a scoprire una limitazione ben documentata:

Two-Connection Limit

The HTTP specification indicates that an HTTP client should make a maximum of two simultaneous TCP connections to any single server. This keeps a single browser from overloading a server with connection requests when it browses to a page with, say, 120 embedded thumbnail images. Instead of creating 120 TCP connections and sending an HTTP request on each, the browser will only create 2 connections and then start sending the 120 HTTP requests for the thumbnail images on those two pipes. The problem with this approach on the middle tier is that your middle tier may have 50 simultaneous users. If you have to make a MapPoint .NET Web service call for each of those users, then you will have 48 users sitting around waiting in line for one of those two pipes to free up.

 

Direttamente da una pagina di MSDN in cui sono riportate tante altre informazioni utili riguardo a considerazioni di performance riguardo i WebServices.

Una lettura consigliatissima

La soluzione di questo problema è una banale configurazione nella configurazione della vostra applicazione (MYAPP.config)o web (web.config) che includa:

<system.net>
  <connectionManagement>
     <add address="*" maxconnection="8"/>
  </connectionManagement>
</system.net>

Dove maxconnection >2 che è il default.

Non si finisce mai d’imparare.

Ho da tempo un account Twitter ma la sua scarsa diffusione non mi ha mai spinto ad usarlo più di tanto anche se seguivo il fenomeno da un pò. Da qualche settimana le richieste di followers iniziano ad arrivare da colleghi e amici pertanto ho “riaperto il dossier” Twitter.

Quello che mancava per iniziarlo ad usare era uno strumento bello e facile da usare.

Trovato!

Blu è il più bel client che abbia mai visto ed, soprattutto, non utilizza pesantissimi motori extra come altri (Air, Flash, Silverlight) ma è sviluppato interamente in .NET 3.5 sfruttando pienamente le WPF.

Anche se non usate twitter fateci un giro per vedere come saranno le applicazioni del futuro.

L’esperienza di utilizzo, installazione compresa (unica pecca ci vuole il .NET Framework 3.5), è assolutamente diversa da tutto quello che avete visto fino ad oggi.

Da provare.

E’ stata una settimana abbastanza faticosa, quella che mi sono appena lasciato alla spalle, e con qualche lezione da imparare (oltre alle solite vagonate di merda e astio..).
Volendo, solo per amor proprio, guardare la parte mezza piena del bicchiere posso dire che la settimana è stata un buon momento per apprendere cose nuove.

Infatti questa settimana mi ha insegnato almeno 2 cose:

• MAI accelerare le procedure di rilascio di versioni apparentemente innocue di software ma attenersi scrupolosamente e metodologicamente alle tempistiche decise;
• Quando un baco si rivela dopo una Service Pack, solitamente c’è un baco che ne nascondeva un altro;

Il primo è una lezione che ormai sta diventando praticamente un dogma:

“ogni volta che si salta un passo della procedura di verifica o se ne  accorciano i tempila possibilità di incorrere in un problema è direttamente proporzionale alla complessità dell’infrastruttura più l’entità delle modifica”

La seconda è un corollario della programmazione a scarso tasso di verifiche statiche del codice.
Quello che è successo nel nostro caso è che, nel deploy della .NET 3.5 SP1, abbiamo inconsapevolemente effettuato anche la SP2 di .NET 2.0 che modificava il comportamento della form standard per il postback dei controlli aspnet.

La cosa abbastanza brutta è che il framework .NET 3.5 viene riportato come un superset del 2.0 di cui non modifica il core. Dunque si è portati a pensare che non vi sia alcuna controindicazione particolare ad installarlo qualora si renda necessario.
Peccato che al suo interno il package da me scaricato contenesse anche la Service Pack 2 di .NET 2.0 che modifica il comportamento della generazione della pagina in presenza di una form di tipo aspnetForm senza paramentro Action valorizzato.

Nel nostro caso, precedentemente alla SP, l’action veniva automaticamente ritenuto essere la stessa pagina sorgente del PostBack. Da questa nuova release il valore vuoto genera un comportamento diverso da prima e, nel nostro caso, l’action veniva popolata con una stringa presa altrove.

Il risultato è che nessun si poteva autenticare visto che mancava il giusto URL di post: non generando nessun errore di compilazione la presenza di due tag FORM ha generato un tale trambusto che il problema sembrava essere di altra natura.

Visto che la SP2 non è disinstallabile ed è installata dal package del framework .NET 3.5 sarebbe meglio sapere dall’inizio quali sono i bachi risolti.

Baco scaccia baco…..