[jdbc][MS SQL Server] strano problema con prestazioni

[sottovento]

Cari colleghi
mi e' stato richiesto di dare un'occhiata ad una pagina web intranet realizzata attraverso una servlet poiche' terribilmente lenta (oltre 40 secondi per visualizzare).
La pagina ha bisogno di 6 query (indipendenti l'una dall'altra) per ottenere tutti i dati necessari.
Le query vengono effettuate in sequenza ed i tempi sono:
query 1: 14113 ms
query 2: 7764 ms
query 3: 16247 ms
query 4: 2587 ms
query 5: 9272 ms
query 6: 205 ms
Totale preparazione pagina:50188 ms

Ovviamente i tempi cambiano leggermente ad ogni esecuzione.

Visto che le query sono indipendenti, ho pensato di lanciarle tutte in esecuzione simultaneamente in 6 thread diversi.
Il thread principale dovra' quindi aspettare che tutti i 6 thread finiscano l'esecuzione per raccogliere i dati e preparare la pagina.
Cosi' ho fatto, sincronizzando ovviamente i 6 thread in modo da completare la pagina solo quando tutti 6 hanno completato il loro lavoro.

Il risultato e' stato sorprendente:
query 1: 41965 ms
query 2: 33340 ms
query 3: 48538 ms
query 4: 15127 ms
query 5: 33451 ms
query 6: 1901 ms
Totale preparazione pagina:48589 ms

In pratica, le query hanno necessitato di un tempo di esecuziona di gran lunga maggiore!
Mi sarei aspettato che il tempo di esecuzione si riducesse (grosso modo) al tempo di esecuzione della query piu' lenta. Questo risultato e' completamente inatteso!
Ho fatto anche stampare la data/ora di partenza della query, pensando ad un mio errore di programmazione (pensando che erroneamente avessi potuto far partire i thread sequenzialmente) ma tutte e 6 le query dicono di partire esattamente allo stesso orario, quindi stanno lavorando tutte insieme.

C'e' qualcuno esperto di Microsoft SQL server che ha un'idea di cosa stia accadendo?

A proposito: per quanto riguarda le connessioni, uso la gestione del pool di connessioni messa a disposizione da Tomcat (i.e. org.apache.tomcat.jdbc.pool.DataSource). Ho un singleton DataSource dal quale ottengo una connessione mediante DataSource.getConnection(), quindi suppongo che ci sia una connessione diversa per ogni thread/query. Purtroppo la documentazione e' un po' vaga e non sono sicurissimo.

Qualcuno ha un'idea?

Ciao!

[Kaya]

Non riesco a capire come possa essere che lanciare le query in parallelo riduca il tempo.
Alla fine se ci impiega tempo X per fare il lavoro, quello ci impiega.
Certo, a meno che non ci sia un discorso di allocazione di thread lato server e ti aspetti che lanciando n query distinte le distribuisca sui thread della cpu del server distinti.
Su questo aspetto non ti saprei aiutare, tuttavia io valuterei prima di fare una analisi sulle prestazioni della query stessa e vedere se non c'è magari qualche indice mancante che possa migliorare le prestazioni.

[wingman87]

Può essere che quando lanci quelle query le risorse del server vengano usate al massimo? Spiegherebbe perché anche lanciandole tutte insieme non hai miglioramenti.
Verificherei anch'io se è possibile ottimizzare le query.
Uno strumento utile per analizzare le prestazioni delle query è l'execution plan. Da SQL Management Studio, dopo aver scritto la query, vai nel menu Query e attiva "Display Estimated Execution Plan" e "Include Actual Execution Plan". Ora esegui la query e una volta terminato, oltre al tab dei risultati avrai altri due tab con gli step che SQL server ha eseguito, i tempi e le risorse impiegate. In alcuni casi SQL server individua già la mancanza degli indici e ti consiglia cosa aggiungere (sopra all'execution plan).

[sottovento]

Grazie per le risposte. Si, l'idea e' quella di eseguire tutte e sei le query parallelamente, dando per scontato che un server Ms Sql le possa gestire senza problemi. Mi aspettavo infatti che il tempo di esecuzione fosse pari a quello della query piu' lenta. Evidentemente non e' cosi'.

Dovro' quindi procedere all'analisi delle query per cercare di ottimizzarle. Purtroppo cercavo di evitare una simile analisi perche' le query provengono da altri dipartimenti. Si tratta di coinvolgere altri gruppi di sviluppo e spesso non e' un'operazione agevole.

wingman87, grazie per le informazioni su SQL Management Studio, magari faccio un tentativo prima di contattare gli autori delle query.

Ad ogni modo non mi spiego ancora come sia possibile un decadimento verticale delle prestazioni a seguito di incremento del parallelismo. Sembra davvero che l'ipotesi ventilata da Kaya sia quella giusta: il server non riesce a gestire il carico.

Questo spaventerebbe ancora di piu': il gruppo che ha sviluppato questa applicazione l'ha chiamata "Big Data" affermando che questa installazione di Ms Sql Server sia in grado appunto di gestire i "big data" dell'azienda (produciamo TB di dati ogni giorno). Il loro progetto non e' ancora maturo e di dati in SQL server ce ne sono ancora pochi. Se comincia a sedersi proprio adesso, figuriamoci quando l'applicazione sara' disponibile a tutti in azienda!
Inutile dire che nutro delle forti perplessita' sulle scelte tecniche adottate, ma non ci posso mettere becco

[Kaya]

Originariamente inviato da sottovento

Ad ogni modo non mi spiego ancora come sia possibile un decadimento verticale delle prestazioni a seguito di incremento del parallelismo. Sembra davvero che l'ipotesi ventilata da Kaya sia quella giusta: il server non riesce a gestire il carico.

Per fare questo basta che verifichi quando esegui la procedura il livello del carico sul server. Se la CPU schizza al 100% allora non puoi fare molto se non lavorare lato query.

Originariamente inviato da sottovento

Questo spaventerebbe ancora di piu': il gruppo che ha sviluppato questa applicazione l'ha chiamata "Big Data" affermando che questa installazione di Ms Sql Server sia in grado appunto di gestire i "big data" dell'azienda (produciamo TB di dati ogni giorno). Il loro progetto non e' ancora maturo e di dati in SQL server ce ne sono ancora pochi. Se comincia a sedersi proprio adesso, figuriamoci quando l'applicazione sara' disponibile a tutti in azienda!
Inutile dire che nutro delle forti perplessita' sulle scelte tecniche adottate, ma non ci posso mettere becco

Personalmente non accoppierei mai la parola big data con SQL Server