none
Velocità di RICEZIONE DATI. Qualcuno sa perché è così LENTO? RRS feed

  • 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

    sabato 17 gennaio 2015 16:22

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

    lunedì 2 marzo 2015 15:27

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:

    http://blogs.msdn.com/b/mast/archive/2013/10/15/windows-azure-support-how-it-works-and-how-to-receive-help.aspx


    domenica 18 gennaio 2015 10:38
    Moderatore
  • 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

    domenica 18 gennaio 2015 13:28
  • 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?



    domenica 18 gennaio 2015 15:51
    Moderatore
  • 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

    domenica 18 gennaio 2015 17:30
  • 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

    lunedì 19 gennaio 2015 09:44
    Moderatore
  • 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

    lunedì 19 gennaio 2015 11:37
  • 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

    martedì 20 gennaio 2015 14:21
    Moderatore
  • 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

    martedì 20 gennaio 2015 15:21
  • 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



    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

    martedì 27 gennaio 2015 15:13
  • ed una opportunità la darei anche a questa soluzione

    i find the solution , but not the reason that produces this problem .

    1. So i get the backup of the problematic database.
    2. I remove the database  from the server.
    3. 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

    ref: http://www.networksteve.com/forum/topic.php/SQL_Azure_Run_extremely_slowly_than_the_on_premises/?TopicId=41516&Posts=8


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 27 gennaio 2015 16:29
    Moderatore
  • ed una opportunità la darei anche a questa soluzione

    i find the solution , but not the reason that produces this problem .

    1. So i get the backup of the problematic database.
    2. I remove the database  from the server.
    3. I create a new database in the same server from the backup.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Grazie 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

    martedì 27 gennaio 2015 17:41
  • 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.html

    Letti,
    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:

    SQLAzure 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: 16s

    Grazie 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

    martedì 27 gennaio 2015 18:30
  • 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

    mercoledì 28 gennaio 2015 13:53
    Moderatore
  • 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

    mercoledì 28 gennaio 2015 14:00
  • 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

    martedì 3 febbraio 2015 11:40
    Moderatore
  • 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

    lunedì 2 marzo 2015 15:27