questo è il mio primo post qui sulla Community quindi prima di tutto ringrazio gli amministratori per aver realizzato questo spazio di condivisione.
Cerco di spiegare la problematica che ci sta “perseguitando” da diverso tempo con la speranza di un feedback / suggerimento di qualcuno di più esperto a livello sistemistico per arrivare ad una soluzione
Da circa 1 anno abbiamo messo in produzione da un cliente un gestionale realizzato con Instant Developer foundation così strutturato: un’applicazione Master deployata e caricata nella wwwroot di IIS e una serie di .dll caricate all’interno della cartella FDBin.
L’ applicazione Master carica dinamicamente le .dll sulla base delle funzioni richieste dagli utenti tramite menù e bottoni disposti in altre .dll (Es. se dal menù seleziono “ordini clienti” il programma carica e visualizza la .dll corrispondente).
Da un cliente (che utilizza l’applicativo in modalità Client/Server con IIS installato su macchina Windows Server in Cloud) abbiamo questa situazione:
Da diverso tempo stiamo collaborando con i loro sistemisti per capire come mai succede che nel normale utilizzo dell’applicativo venga visualizzato il popup “Attendere prego” con tempi di attesa lunghissimi. Tanto che gli utenti ad un certo punto chiudono il Browser, riaprono l’applicativo da zero e nel giro di qualche secondo completano l’operazione che era rimasta in sospeso.
Questa cosa accade dalle 10 alle più volte in un giorno MA lo scenario è il peggiore, nel senso che non c’è un’applicativo in particolare o un’azione che genera questo messaggio. La situazione è randomica.
I principali indiziati sono stiati:
Latenza di rete: I loro sistemisti hanno verificato che la latenza della loro rete si aggira sui 4/6/12ms a nostro avviso quindi è OK.
Noi abbiamo analizzato i log di IIS e i tempi di risposta alle richieste GET/POST vanno dai 4ms ai 60ms con picchi randomici di 27000ms.
Avendo però strutturato il gestionale come descritto nelle prime righe noi vediamo una chiamata POST all’applicazione Master ma non sappiamo che cosa viene richiesto nel dettaglio.
Query o procedure non ottimizzate a Database: abbiamo verificato dalle statistiche e il db ci dice che il tempo massimo di elaborazione - considerando da Gennaio 2025 - è di circa 5 secondi.
A seguito di quanto sopra, siamo in una situazione di stallo in quanto i sistemisti dicono che la rete è OK e ha un tempo di latenza a loro dire irrisorio, noi abbiamo fatto tutte le verifiche che erano nelle nostre possibilità e non riscontriamo criticità, il cliente “pressa” perchè il messaggio di “Attendere Prego” li blocca almeno 10 volte al giorno.
Domande:
C’è un modo per tracciare in modo più significativo le richieste che i client fanno verso il Web Server ? Usando anche programmi tipo Wireshark o simili.
La latenza segnalata dai sistemisti può influire sul presentarsi dell’ attendere prego ?
Anche se non avete una soluzione o un suggerimento sarebbe ugualmente utile sapere se siamo gli unici ad essere inciampati in questa cosa.
Ciao Giulio
quello che chiedi non è affatto semplice, butto là qualche idea:
E` possibile che l’attendere prego derivi dall’utilizzo di risorse bloccate? Ad esempio più processi che provano a scrivere lo stesso file?
L’attendere prego compare più o meno simultaneamente per tutti gli utenti? o cmq rallentano tutti? se è così penserei che l’esecuzione del codice, per una delle sessioni, sia andata in loop e satura il server. Esistono strumenti come processExplorer e moduli aggiuntivi di IIS che ti permettono di avere qualche informazione in più sui processi e le risorse che stanno usando. Quelle da tenere d’occhio sono cpu, memoria, i/o disco e scheda di rete.
Magari c’è anche qualche altro processo che satura la macchina.
Se l’applicazione è a 32bit ti consiglio vivamente di passarla a 64bit.
Fai un’istallazione parallela con debug attivo e, quando il cliente segnala il problema, esegui le stesse operazioni e verifica il debug. Verifica anche il debug in situazione stabile, se la linea non è stabile i messaggi arrivano in ritardo e vengono scartati. E` un indizio.
Ci sono punti del codice dove, run time, attivi il debug? Solitamente il debug atterra le prestazioni.
Potresti attivare il Trace di InDe, in pratica registra le sessioni e ti invia il debug. Ma rallenta sensibilmente, se non ricordo male.
ot: solitamente nella Community si condividono idee/soluzioni e si innesca un confronto, per la richiesta di aiuto il canale adatto è il forum
mi auguro che tutto questo bla bla bla ti sia di qualche aiuto
Ciao Giulio, come dice Riccardo non è semplice però di sicuro puoi fare ulteriori investigazioni…
nella console del browser cosa “succede” quando c’è l’attendere prego? per esperienza dovresti avere degli errori o lato javascript client che possono causare l’errore o di mancata risposta del server
se fai F5 dopo alcuni secondi la procedura continua?
lato db ci sono lock a livello di tabelle/record durante il blocco?
il server in cloud usa conteinerizzazioni?
in sostanza in primis dovete capire se è un problema client o server e poi approfondire l’analisi, purtroppo è l’eterna battaglia tra sistemisti e developer questa
ho aperto la discussione qui sulla Community consapevole non fosse il canale più corretto in termini di assistenza con la speranza che ne potesse nascere un Topic non limitato a Instant Developer ma con suggerimenti orientati al monitoraggio delle risorse che magari nel mondo developer qualcuno già adotta anche applicati ad InDe.
Ti ringrazio per i tuoi spunti!
Posso risponderti genericamente che abbiamo già provato a fare un’analisi massiva del codice ma, come puoi immaginare, passare procedura per procedura un’intero gestionale non è cosa semplice.
Purtroppo il fatto che sia una cosa strettamente legata al feedback dell’utilizzatore non aiuta l’operazione di Debug, il fatto che questa attesa sembra non essere legata ad una procedura in particolare…..ancora meno.
Il Debug in produzione è disattivato e non ci sono punti in cui viene attivato a runtime.
Proveremo ad indagare sulla fattibilità di applicare il Trace, magari in parallelo rispetto all’applicazione ufficiale e sottoponendolo solamente ad alcuni client così da ridurre al minimo l’eventuale calo di performance di utilizzo che ricordi.
L’ applicazione è ad oggi pubblicata a 32bit, il passaggio a 64bit al netto dell’impostazione da variare lato IIS cosa comporta lato applicativo ? Potrebbe essere necessario un refactoring di qualche tipo ? Tu utilizzi 64bit sulle tue applicazioni ?
Nella console del browser non viene segnalato nulla (purtroppo).
F5….non abbiamo mai provato perchè solitamente tendiamo a non utilizzare le funzionalità tipiche del browser onde evitare che questa mossa lasci in sospeso operazioni a database o qualsiasi altra transazione, però in questo caso potrebbe essere un test interessante.
Lato database nel memento del blocco non ci sono lock di sessioni.
il server in cloud usa conteinerizzazioni ?
Ammetto la mia ignoranza in merito. La macchina dove gira IIS è sicuramente virtualizzata dal server Cloud vero e proprio in quanto so per certo che dal Server principale i sistemisti ci hanno dato l’accesso a 2 virtual machine quindi IIS non è direttamente installato sul Server Cloud.
Tempo fa lavoravo con progetti .NET e IIS. Da quello che ricordo, nel passaggio da 32 a 64 bit devi verificare (e nel caso aggiornare) la versione delle dll aggiunte all’applicazione. Per quanto rigurada la dll di chilkat InDe prova a caricare quella giusta, ma verificherei anche quella.
