Principale utente con più risposte
Velocità di RICEZIONE DATI. Qualcuno sa perché è così LENTO?

Domanda
-
Ciao a tutti,
ho alcune applicazioni WinForm che usano SQLAzure come fonte dati (testuali/numerici), tutto bene tranne che per la velocità con la quale i dati arrivano al client. è di una lentezza incompresibile.
Diciamo che conosco abbastanza come funziona l'ICT e ho fatto due test:
Usando Monitoraggio Risorse ho notato che l'uso della rete, durante il load dei dati nel DataSet era un po' scarsino: sui 28KB/s!
Verificando la geo-location dell IP del SQLAzure server ho visto che un TACEROUTE mi porta a Seattle, ma nei registri ufficiali indica che è in Olanda (plausibile visto che il mio SQLAzure server è WestEurope).
Facendo una paio di test con speedtest.net su Amsterdam e su Seattle ho visto che il ping della connesione 1433 era compatibile con Amsterdam con la quale ho un DL di 9.6Mb/s che ovviamente è moolto maggiore dei 28KB/s raggiunte come DL da SQLAzure.Il server è un livello Basic (con un altro server di livello S0 ho toccato al massimo i 6KB/s!, sempre WE).
Cortesemente qualcuno sa dirmi perchè e/o se c'è un modo di aumentare la velocità di DL dei dati da SQL AZURE?
Grazie in anticipo.
Davide
PS: Per la mia esperienza, a naso, direi che la lentezza non è dovuta a problemi di linea o tecnici, o c'è un "limitatore" o c'è qualcosa migliorabile dal lato software client.
PS2: ho provato anche con SQL Management Console, sia con pacchetti piccoli che grandi, e le velocità di caricamento della stesso query sono identiche a quelle riscontrare con i SW WinForm.
PS3: Ho verificato l'uso dei DTU e lato server le % d'uso sono rimaste sotto al 20-30%
Davide Dolla
Risposte
-
rieccomi.
Ho fatto un po di analisi e un paio di test, ero collegato ad una rete Microsoft guest, e devo dire che a Roma la stessa identica query ci metteva 3 secondi!
Mentre tornato ad Imperia (capoluogo di provincia in Liguria) il tempo è tornato a 19 secondi!!!!
Quindi probabilemnte il problema è la rete di TELECOM ITALIA.
Roma-Imperia: 3s-19s.Quindi è palese che in Italia la penetrazione di Azure, e degli altri sertvizi cloud-based, sia ancora rallentata, oltre che da fattori sociali, anche da TELECOM ITALIA.
Non commento .... ma sicuramente sarà impossibile chiedere lumi a TELECOM ITALIA, visto che la legge in Italia lascia libere le TLC di fornire connettività minima e di bassa qualità pagata con soldi veri.
Sarebbe divertente pagarli con soldi che laggano o che hanno meno valore :)Mi sa che per usare SQL remoti dovremmo aspettare che ci siano linee Internet degne del 2015 ... quindi forse le avremo nel 2030.
Grazie a tutti per aver contriubito.
PS: se avete un amico o parente in TELECOM fatemelo sapere ... che in Italia è l'unica strada pratica per risolvere i problemi.Davide Dolla
- Proposto come risposta Edoardo BenussiMVP, Moderator lunedì 2 marzo 2015 15:36
- Contrassegnato come risposta Davide Dolla lunedì 2 marzo 2015 15:38
Tutte le risposte
-
Windows Azure SQL presenta comunque delle differenze di prestazioni rispetto ad un SQL Server dedicato perché si tratta di un servizio condiviso. E' vero che anche per i piani non Premium avviene una distribuzione delle risorse tra gli host per garantire l'equità, ma solo con i database Premium è possibile avere delle prestazioni garantite.
Qui trovi un approfondimento:
http://msdn.microsoft.com/library/azure/jj879332.aspx
Quindi bisognerebbe capire se il collo di bottiglia può stare direttamente sull'host che ospita i tuoi database. Se non al livello di risorse hardware, in fatto di connettività (i test eseguiti con i server di speedtest.net lasciano il tempo che trovano).
Ad esempio il sistema di QoS potrebbe limitare le tue prestazioni perché rileva un utilizzo eccessivo delle risorse.
Se sei assolutamente sicuro che non possa trattarsi di un problema di query potresti valutare anche l'utilizzo dell'assistenza a pagamento per far eseguire una ricerca più approfondita delle cause:
- Modificato Fabrizio-GMVP, Moderator domenica 18 gennaio 2015 10:56
-
Fabrizio,
grazie per la reply.
Le tue considerazioni sono corrette, ma:
- Nessun QOS, ho una lina ADSL 20MB (12 effetivi) di Telecom ed è completamente a mia disposizione.
- La query è banale (select mono tabella di tutte le 3000 righe!) e l'uso DTU, sia con SQL Basic e sia con un D0 e/o un D1, rimane sotto il 20% (Basic)
- Ho provato su due DB che sono in due host diversi: stesso risultato, anzi su uno è ancora più lento.Pare che sia SOLO la velocità dello stream dei dati dal server al Client.
Il che mi pare strano in quanto la parte shared delle risorse assegnate al server in base al livello NON contempla limitazioni d'uso/velocità della LAN.
Non penso che siano molti che usino app WinForm e una base dati Azure, ma spero di poter trovare risposte senza dover attivare il supporto MS, anche perché non penso che sia un problema di Azure.
Ho fatto una prova con una chiavetta USB (TIM) e ha avuto qualche picco più alto (100-300KB/s), ma nell'uso normale non è cambiato molto. Solo un pelino più veloce.
Lato SW faccio solo una Fill di un DataSet con System.Data.
Secondo te/voi c'è un modo di capire dov'è il collo di bottiglia?
La mia impressione attuale è che:
- ci sia qualche limitazione di banda da qualche parte (non sulla parte di WAN/LAN gestibile da me)
- oppure lato SW c'è qualcosa di ottimizzabile (anche se dovrei aver seguito le indicazioni)
Grazie per ogni contributo al thread.
Davide.
Davide Dolla
-
La mia impressione attuale è che:
- ci sia qualche limitazione di banda da qualche parte (non sulla parte di WAN/LAN gestibile da me)
- oppure lato SW c'è qualcosa di ottimizzabile (anche se dovrei aver seguito le indicazioni)
Grazie per ogni contributo al thread.
Davide.
Davide Dolla
Si, è quello che penso anch'io. Nella risposta precedente non mi riferivo ad un tuo sistema di QoS interno ma a quello utilizzato da Microsoft per il bilanciamento delle prestazioni negli host (quindi si tratterebbe del primo punto che hai citato). Tuttavia questo sistema potrebbe anche avere questo comportamento a causa del secondo punto (non perfetta ottimizzazione del tuo software), il che spiegherebbe il perché lo hai riscontrato anche utilizzando servizi presenti su host diversi. In effetti in realtà ho già sentito casi di prestazioni ridotte con query molto estese, forse viene eseguito proprio da Azure con lo scopo di preservare le risorse.
Non so come funziona esattamente il tuo software, ma non potresti ricevere dei dati filtrati invece di ottenere sempre tutti i valori?
- Modificato Fabrizio-GMVP, Moderator domenica 18 gennaio 2015 15:54
-
Conoscendo MS non penso che abbiano messo una lmitazione alla banda e poi per velocità così ridicole.
Soprattutto considerando il target dei clienti AZURE che ha una connettività nazionale molto superiore alla nostra.Ho verificato e erroneamente ho usato un solo HOST per fare i test, ma questo non cambia la questione:
- Una volta che SQL ha effettuato la query (che può essere la parte pesante ed è l'unica influenzata dalle performance che si hanno acquistato) il server inizia a spedire uno stream di byte che contiene la risposta.
- Questa viene intepretata dal DataRead che popola il DataSet e poi continua l'esecuzione dell'app.
- Le mie applicazioni possono usare indifferentemente SQL locale o Azure ed usano lo stesso codice: la differenza è che in locale, per la stessa identica query su stesso identico DB, ho una performance di 18.879r/s (righe/secondo) che su AZURE scendono a 232r/s :(
Ovvero la stessa semplice query richieste ad un SQLAzure è più lenta del 98.77%, o se vogliamo la velocità scende all' 1.23%, rispetto ad un server SQL Express in locale!
Mi pare un po' troppo basso, visto anche che il traffico di ritorno della query è di circa 1MB.Non penso che questo possano essere le performances che Microsoft voglia dare ai suoi clienti, so quanto ci tengano, ci deve essere qualcosa che mi sfugge. Spero che qualcun'altro si sia imbattuto e abbia risolto un problema simile ... speriamo legga il post :)
Non so come funziona esattamente il tuo software, ma non potresti ricevere dei dati filtrati invece di ottenere sempre tutti i valori?
Uso un banale DataReader con una SqlConnection su SQLAzure e con il comando SQL composto da mio codice.
Capisco cosa vuoi dire ed in effetti il sw fa piccole query mirate per alcuni dati il problema è che impiegano dai 65 ai 400ms e per migliorare la UX (UserExperience) uso delle tabelle-cache dei dati più comuni (Clienti, CAP, comuni, ecc) in modo da non rendere insusabile il sw.Fabrizio ti ringrazio per il tuo interessamento, se nel frattempo qualcuno non posterà qualche idea la settimana prossima disturberò qualche contatto in MS per vedere che ne dicono e ovviamente se troverò una soluzione la posterò.
Davide
PS: giusto per condividere un po di real-life ti metto un po di dati che ho rilevato durante i test: tLoad è il tempo trascorso (calcolato con uno StopWatch) tra la richiesta ed i dati pronti nella DataTable.
OrdineDett tLoad:384ms[0] 8r in 20,8333r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = 'fbe24a17-a5db-45a9-86ca-956adb9f5344' OrdineDett tLoad:72ms[0] 1r in 13,8889r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = 'b416b239-4afd-498f-b5ec-d871be442201' OrdineDett tLoad:124ms[0] 1r in 8,0645r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '879ad770-ad6d-4a76-9e73-a40bc5f32147' OrdineDett tLoad:489ms[0] 2r in 4,09r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '8f9bc1c6-e3b1-4582-a938-98448f3ce156' OrdineDett tLoad:664ms[0] 11r in 16,5663r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '8185e0f5-fd53-4004-989b-f6f7d3a2748f' OrdineDett tLoad:615ms[0] 14r in 22,7642r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '72453eb6-622a-4c0f-883a-5025432e0574' OrdineDett tLoad:575ms[0] 4r in 6,9565r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '043bd749-fec4-49d0-83db-682835cbe263' OrdineDett tLoad:576ms[0] 7r in 12,1528r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '0c93ddeb-b541-4236-a992-91b48ff982db' OrdineDett tLoad:586ms[0] 2r in 3,413r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '786a2ec9-5d5e-4018-a2c4-d8b4778eb1d1' OrdineDett tLoad:626ms[0] 8r in 12,7796r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '0feac278-ff26-413a-9c8b-0600e9a5b4fd' OrdineDett tLoad:175ms[0] 5r in 28,5714r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = 'bab6c610-7ed1-4537-b8b2-9709b2ec51f3' OrdineDett tLoad:578ms[0] 1r in 1,7301r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '0ba9fb56-5a2b-468c-8975-e9ce5487e7c6' OrdineDett tLoad:615ms[0] 1r in 1,626r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '85af94f7-e6b1-4f07-9466-a5a69fba5785' OrdineDett tLoad:569ms[0] 11r in 19,3322r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '49f52830-8c71-4092-8a0b-3f85d4a788b9' OrdineDett tLoad:858ms[0] 1r in 1,1655r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '0a2c3848-ce22-47c4-9c68-d8335fbc3b57' Ordine tLoad:101ms[4] 6r in 59,4059r/s SELECT [dbo].[Ordine].[ID], [dbo].[Ordine].[data], [dbo].[Ordine].[statoOrd], [dbo].[Ordine].[idAgente], [dbo].[Ordine].[idCasa], [dbo].[Ordine].[numOrdCasa], [dbo].[Ordine].[nr_Doc], [dbo].[Ordine].[idCli], [dbo].[Ordine].[COD_CLIENT], [dbo].[Ordine].[data_Reg], [dbo].[Ordine].[dtPagato], [dbo].[Ordine].[TOT_NETTO], [dbo].[Ordine].[fImporto_Sconti], [dbo].[Ordine].[impNetto], [dbo].[Ordine].[impBaseProvv], [dbo].[Ordine].[provvLorda], [dbo].[Ordine].[provvAgz], [dbo].[Ordine].[provvAgt], [dbo].[Ordine].[provvAgtPerc], [dbo].[Ordine].[TOT_CART], [dbo].[Ordine].[TOT_BOTT], [dbo].[Ordine].[PAGA], [dbo].[Ordine].[T_CONS], [dbo].[Ordine].[notePiePagina], [dbo].[Clienti].[ESERCIZIO], [dbo].[Clienti].[PROVINCIA], [dbo].[Clienti].[COMUNE], [dbo].[Clienti].[CAP], [dbo].[Ordine].[fCodAgMolinari], [dbo].[Ordine].[lastUpdatedOn], [dbo].[Ordine].[lastUpdatedByTxt] FROM [dbo].[Ordine] LEFT OUTER JOIN [dbo].[Clienti] ON [dbo].[Clienti].[ID] = [dbo].[Ordine].[idCli] WHERE ((([dbo].[Ordine].[data] BETWEEN '20141201 00:00:00' AND '20150131 23:59:00'))) AND ( statoOrd = 14) OrdineDett tLoad:241ms[0] 1r in 4,1494r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '8b2ac425-8b66-4fec-94fb-686101d8d153' OrdineDett tLoad:624ms[0] 2r in 3,2051r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '5c68be66-c400-409d-b9ce-769bfd5d1307' OrdineDett tLoad:713ms[0] 1r in 1,4025r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '0c366d84-b55d-4b50-9404-9eb092da4294' OrdineDett tLoad:629ms[0] 4r in 6,3593r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = '55c0431f-8eb7-4695-8726-c6c99bb8f482' OrdineDett tLoad:861ms[0] 1r in 1,1614r/s SELECT [dbo].[OrdineDett].* FROM [dbo].[OrdineDett] WHERE ordineID = 'f9c45b89-7280-4b46-90f5-6f389cc6e17e'
Nota: le performance numeriche da me indicate sono da prendere con beneficio d'inventario in quanto sono dati calcolati su un piccolo campione e servono giusto a dare un'idea della velocità operativa.Davide Dolla
- Una volta che SQL ha effettuato la query (che può essere la parte pesante ed è l'unica influenzata dalle performance che si hanno acquistato) il server inizia a spedire uno stream di byte che contiene la risposta.
-
hai provato a fare delle select con SSMS dalla stessa rete su cui gira l'applicazione verso il db di SQL Azure per vedere i tempi di risposta ?
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org -
Sì, certamente
stesse identiche query fatte da SSMS danno tempi quasi identici.
Anche cambiando dimensioni della lunghezza del pacchetto TCP (1024-4096) i tempi non cambiano :(Anche per i risultati di questo test, che eilimina completamente eventuali errori di coding, che ho aperto questo thread.
Se non riesco a capire il perché di questa "lentezza" sarà difficile per noi spingere su soluzioni che usano SQLAZure come base dati remota per applicazioni locali (sia WinForm che WinApp).
Un test per capire se c'è qualche limitazione di banda (applicata da qualche ISP) sulla porta 1433 sarebbe quello di creare un WebService che chieda lui i dati a SQL e li giri al client WCF ... ma prutroppo per ora non ho tempo di provarlo. Qualcuno l'ha mica già provato?
Davide Dolla
-
Sì, certamente
stesse identiche query fatte da SSMS danno tempi quasi identici.
per essere certo di aver capito bene lo riscrivo:
le medesime query eseguite mediante l'applicazione winform e mediante SSMS hanno gli stessi tempi di risposta. ho capito bene ?
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org -
Assolutamente SI
Per scrupolo, odio ragionare su "lucciole" (ovvero delle false basi di partenza), ho rifatto ora un test, qui puoi vedere che i tempi riportati da SSMS sono in linea 19sec, anzi più lento, con i 14.6s registrato dal mio codice di debugging.
Inoltre oggi ho avuto modo di provare una situazione simile (SQL 2008 remoto collegato in VPN e WinForm locale) da un cliente a Monaco (VPN tra due nodi ADSL in città) e devo dire che era quasi come stare in locale!
Quindi ritengo che ci sia qualcosa che rallenti il traffico, magari quello che gira sulla porta 1433, piuttosto che problemi lato SW.
Any suggestion :) ?
Davide Dolla
-
Effettivamente i tempi sembrano un po' eccessivi anche se nella query c'è una "distinct" e un "order by".
Io eseguirei la stessa query direttamente dal portale azure e indagherei sul piano di esecuzione.
----------------------------
Pasquale Ceglie
- Modificato Pasquale Ceglie martedì 27 gennaio 2015 09:59
-
Grazie per i suggerimenti,
ma il DISTINCT e l'ORDERBY influenzano solo la velocità di esecuzione della query e NON la trasmissione del risultato. Infatti ho usato una query banale apposta.
Idem per quanto riguarda provare a fare la query con il portale ... il problema non è il tempo di esecuzione della query, almeno in questo caso, ma il TEMPO di trasferimento del risultato al client. (dove non dovrebbero influire i DTU)
Quindi usando il portale avrei sì dei tempi migliori, ma in una situazione alterata rispetto a quella reale Client-Server.PS: ho comunque notato notevoli riduzioni di performances di SQL Azure anche usandolo come base dati per un App WEB istanziata su Azure. Mi sa che questo giro MS non abbia fatto bene i conti della UX, soprattutto per i piccoli.
Davide Dolla
-
mi sa che a questo punto sia opportuno leggere questi:
http://www.keepitsimpleandfast.com/2012/01/analyze-performance-between-sql-azure.html
ma soprattutto
http://searchsqlserver.techtarget.com/tip/Speed-up-execution-times-in-Microsoft-SQL-Azure
http://www.troyhunt.com/2013/12/working-with-154-million-records-on.html
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org- Modificato Edoardo BenussiMVP, Moderator martedì 27 gennaio 2015 15:39
-
ed una opportunità la darei anche a questa soluzione
i find the solution , but not the reason that produces this problem .
- So i get the backup of the problematic database.
- I remove the database from the server.
- I create a new database in the same server from the backup.
After this all queries fetch results in zero time.
The problem solved , but the reason is unknonw.
(one think is that the database maybe has some "garbage" becouse we had made development on this database and we change indexes and table so many times )
Thanks for your help
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org -
ed una opportunità la darei anche a questa soluzione
i find the solution , but not the reason that produces this problem .
- So i get the backup of the problematic database.
- I remove the database from the server.
- I create a new database in the same server from the backup.
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]orgGrazie Edoardo,
ora mi leggerò i link.
Ma la "soluzione" trovata da questo utente mi pare solo un workaround per problematiche, serie direi, di SQLAzure.
Come last resort proverò pure questa, ma dopo aver tentato strade che diano più risposte al why.
Davide Dolla
-
mi sa che a questo punto sia opportuno leggere questi:
http://www.keepitsimpleandfast.com/2012/01/analyze-performance-between-sql-azure.html
http://searchsqlserver.techtarget.com/tip/Speed-up-execution-times-in-Microsoft-SQL-Azure
http://www.troyhunt.com/2013/12/working-with-154-million-records-on.htmlLetti,
ma purtroppo Troy parla dello storage in table e non è questo il caso, SearchSQLServer parla di cose generiche che conosco a fondo.Mentre il primo è un interessante articolo su come fare un cronometraggio sulle perfomances ... proverò e condividerò i risultati.
Il nodo del problema è la velocità di download del risultato della query.
Infatti, seguendo le indicazioni del primo link ho rifatto le prove e riporto qui sotto i risultati:
QUERY:
PRINT 'Query: Cashflow entries to be allocated 1' SET STATISTICS IO ON SET STATISTICS TIME ON SELECT DISTINCT isnull(notaInEvidenza+ '***' ,'') + RAG_SOC as descr, ID, note, PAGA, BANCA, idAgente, noteVettore, RAG_SOC FROM [dbo].[Clienti] WHERE [dbo].[Clienti].[ID]<> '10000000-0000-0000-0000-0000000000000' ORDER BY RAG_SOC SET STATISTICS IO OFF SET STATISTICS TIME OFF PRINT '----------------------------------------------------------------------'
Messaggi:
Query: Cashflow entries to be allocated 1
(Righe interessate: 3407)
Table 'Clienti'. Scan count 2, logical reads 397, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 24 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
----------------------------------------------------------------------
Statistiche Client:
Come si nota dalle stats, prova 6 e 7, il maggior tempo "perso" è nella trasmissione dei dati ... che sono 1.102KB!
Tempo di attesa delle risposte del server (tempo di elaborazione della query lato server): 110ms
Tempo di elaborazione client (scaricare i dati): 15.689ms
Tempo della query: 16sGrazie Edoardo per avermi dato un tip che mi permette di esporre il problema in tutta la sua evidenza tecnica e che permette anche di eliminare false piste quali "ottimizzazione del codice", seguire tutte le BP, bla bla.
IL PROBLEMA c'è, ed è dimostrato dal fatto che con una linea vuota da 20Mbs (dove ho raggiunto anche gli 1.2MB/s) la velocità di trasferimento dei TDS è stata di: 70KB/s! (dimostrato senza ombra di dubbio dalle statistiche client)
Io sono pronto anche a fare altri test usando client in altre posizioni geografiche ... ma qualcuno sa indicarmi un posto tipo UserVoice dove poter innescare un thread direttamente con mamma MS?
Magari il passaggio di pacchetti TDS viene rallentato da qualche parte ... oppure SQL Azure è lento a trasferire i dati (ipotesi improbabile)?
Grazie a tutti per la collaborazione.
Secondo voi se posto in qualche gruppo in inglese ho più probabilità di trovare qualcuno di MS che segue SQLAzure?
Davide Dolla
-
adesso vedo se c'è qualche altra strada da percorrere, nel frattempo io ti consiglierei di fare una prova con la tua applicazione che esegue la query mettendo la tua applicazione su un web role/worker role/ virtual machine che sia all'interno del medesimo datacenter dove si trova il database.
ciao.
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org -
Grazie Edoardo,
ho già un WebRole, che espone un'altra applicazione completamente diversa (monitoraggio impianti fotovoltaici medio-grandi), che prima usava una BizEdition ed ora lo sto provando su una S0 e lì la prima query è velocissima ... poi arriva il collo di bottiglia dei DTUs ... ma questa è un'altra storia e forse un'altro thread.
Quindi lato interno, a parte i DTUs, direi che non ci sono problemi, la questione penso sia nella tratta SQLDatacenter-Client.
Io fine febbraio avrò modo di porterne parlare direttamente con Microsoft Italia, quindi non smuovere le montagne ;). Ovvio che se ne riusciamo a venire a capo prima, meglio :)
Grazie ancora e buona ricerca.
Davide
Davide Dolla
-
a questo punto o aspettiamo fine febbraio o provi a rifare il database come suggerito sopra.
ti chiedo solo di aggiornare il thread quando avrai trovato la soluzione, grazie.
ciao.
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org -
rieccomi.
Ho fatto un po di analisi e un paio di test, ero collegato ad una rete Microsoft guest, e devo dire che a Roma la stessa identica query ci metteva 3 secondi!
Mentre tornato ad Imperia (capoluogo di provincia in Liguria) il tempo è tornato a 19 secondi!!!!
Quindi probabilemnte il problema è la rete di TELECOM ITALIA.
Roma-Imperia: 3s-19s.Quindi è palese che in Italia la penetrazione di Azure, e degli altri sertvizi cloud-based, sia ancora rallentata, oltre che da fattori sociali, anche da TELECOM ITALIA.
Non commento .... ma sicuramente sarà impossibile chiedere lumi a TELECOM ITALIA, visto che la legge in Italia lascia libere le TLC di fornire connettività minima e di bassa qualità pagata con soldi veri.
Sarebbe divertente pagarli con soldi che laggano o che hanno meno valore :)Mi sa che per usare SQL remoti dovremmo aspettare che ci siano linee Internet degne del 2015 ... quindi forse le avremo nel 2030.
Grazie a tutti per aver contriubito.
PS: se avete un amico o parente in TELECOM fatemelo sapere ... che in Italia è l'unica strada pratica per risolvere i problemi.Davide Dolla
- Proposto come risposta Edoardo BenussiMVP, Moderator lunedì 2 marzo 2015 15:36
- Contrassegnato come risposta Davide Dolla lunedì 2 marzo 2015 15:38