Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Redmi Pad 2 9.7: ampio display, economico e peso contenuto, ma qualche limite nelle prestazioni
Redmi Pad 2 9.7: ampio display, economico e peso contenuto, ma qualche limite nelle prestazioni
Redmi Pad 2 9.7 punta su un display ampio e fluido, una batteria capace di accompagnare l'uso quotidiano senza ansie da ricarica e un prezzo accessibile, a partire da 179,90 euro per la versione con 64 GB di storage. Lo Snapdragon 6s 4G Gen 2 e i 4 GB di RAM della configurazione più diffusa frenano però chi cerca reattività e multitasking spinto: ecco il bilancio dopo due settimane di prova diretta
Peugeot Polygon Concept: ecco il futuro delle utilitarie
Peugeot Polygon Concept: ecco il futuro delle utilitarie
Polygon è la concept car di Peugeot che mostra il futuro delle soluzioni del segmento B: tra design compatti e innovativi affiancati da dimensioni compatte uno scherzo dalla manovrabilità incredibile per le manovre a bassa velocità
Reno16 Pro: il compatto di OPPO punta su fotocamera da 200MP e il nuovo Bubble! La recensione
Reno16 Pro: il compatto di OPPO punta su fotocamera da 200MP e il nuovo Bubble! La recensione
OPPO ha portato in Italia, dal 1° luglio 2026, Reno16 Pro: display AMOLED da 6,32 pollici a 144Hz, tripla fotocamera con sensore principale da 200 megapixel, chip Dimensity 8550 Super e batteria da 6000mAh, al prezzo di lancio di 899 euro. Lo abbiamo provato per due settimane insieme al nuovo accessorio Bubble, per capire se la formula compatta della serie regge ancora di fronte a un listino da 1099 euro
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 24-02-2011, 16:02   #1
anonimizzato
 
Messaggi: n/a
[JAVA] benefici dei thread

Ciao a tutti,

vorrei farvi una domanda sui Threads.

In questi giorni stiamo sviluppando un'applicazione Java che avrà il compito di caricare da DB una serie
di profili (record) come set di dati che poi verranno inviati ad un WebService uno ad uno per essere elaborati ed ottenere
in risposta un risultato calcolato.

es:
A1-B1-c1 -> WS -> R1
A2-B2-c3 -> WS -> R2
A3-B3-c3 -> WS -> R3

Siccome i profili (record) sono molti (5000) ed il WS ci metterà circa un 30 secondi per ogni risposta, il mio capo progetto ha
suggerito il fatto che useremo, molto probabilmente, i Thread.

Ora, io ho poco dimestichezza coi thread (anche se sò cosa sono e come si utilizzano), perciò volevo chiedere quali possono
essere, in questo caso, i benefici dell'utilizzare i thread.

Grazie in anticipo.
  Rispondi citando il messaggio o parte di esso
Old 24-02-2011, 16:12   #2
codcata
Member
 
Iscritto dal: Jun 2008
Città: Torino
Messaggi: 118
suddivisione del lavoro. suddivisione dei compiti del sw tra i thread in modo da svolgere più operazioni allo stesso tempo.
__________________
codcata è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2011, 16:21   #3
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da Sgurbat Guarda i messaggi
...
Siccome i profili (record) sono molti (5000) ed il WS ci metterà circa un 30 secondi per ogni risposta, il mio capo progetto ha
suggerito il fatto che useremo, molto probabilmente, i Thread.
...
Bisogna capire "dove" intederebbe usare il multithreading, il tuo capo.
Dalla tua spiegazione dello scenario, dubito si intendesse lato applicazione che si interfaccia con il database locale, dato che il collo di bottiglia sembra essere il web service che impiega 30 sec. a elaborare una singola risposta, o sbaglio?
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 24-02-2011, 19:32   #4
anonimizzato
 
Messaggi: n/a
Quote:
Originariamente inviato da banryu79 Guarda i messaggi
Bisogna capire "dove" intederebbe usare il multithreading, il tuo capo.
Dalla tua spiegazione dello scenario, dubito si intendesse lato applicazione che si interfaccia con il database locale, dato che il collo di bottiglia sembra essere il web service che impiega 30 sec. a elaborare una singola risposta, o sbaglio?
Uhm, dovrei chiederglielo ma credo intendesse aprire un thread (quanti non saprei) per singola chiamata al WS.
  Rispondi citando il messaggio o parte di esso
Old 24-02-2011, 19:37   #5
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da Sgurbat Guarda i messaggi
Uhm, dovrei chiederglielo ma credo intendesse aprire un thread (quanti non saprei) per singola chiamata al WS.
Quindi lato Web Service: ogni richiesta in arrivo viene processata da un singolo thread.
La questione allora dovrebbe riguardare una modifica del Web Service?
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 24-02-2011 alle 19:40.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 07:11   #6
anonimizzato
 
Messaggi: n/a
Quote:
Originariamente inviato da banryu79 Guarda i messaggi
Quindi lato Web Service: ogni richiesta in arrivo viene processata da un singolo thread.
La questione allora dovrebbe riguardare una modifica del Web Service?
No, non credo intendesse lato WS ma lato client ovvero all'interno dell'applicazione che pesca i profili (record) e poi utilizza lo Stub per chiamare il WS.

Es:
-Applicazione client
- select N profili from table (es: 5)
- ciclo sui 5 profili presi
- apro 1 thread per ciascuno di essi
- all'interno del thread utilizzo lo Stub per chiamare il WS.

Ma la mia, al momento è solo un'ipotesi, oggi dovrei chiarire meglio.

Il WS è comunque nostro quindi eventuali modifiche si posso sempre fare ma, ripeto, credo che intendesse come quanto riportato sopra.
  Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 11:52   #7
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da Sgurbat Guarda i messaggi
No, non credo intendesse lato WS ma lato client ovvero all'interno dell'applicazione che pesca i profili (record) e poi utilizza lo Stub per chiamare il WS.

Es:
-Applicazione client
- select N profili from table (es: 5)
- ciclo sui 5 profili presi
- apro 1 thread per ciascuno di essi
- all'interno del thread utilizzo lo Stub per chiamare il WS.

Ma la mia, al momento è solo un'ipotesi, oggi dovrei chiarire meglio.

Il WS è comunque nostro quindi eventuali modifiche si posso sempre fare ma, ripeto, credo che intendesse come quanto riportato sopra.
Ok, non avevo capito.

Allora il WS già acetta e processa richieste multiple; è il client che ne spedisce una e attende la risposta in modo sincrono, quando invece potrebbe spedirne varie contemporaneamente. Che è quello che dovrete fare.

Quindi invece di essere:
Quote:
select su db
result set di 5 record
invio record 1 al WS
attesa...
processo la risposta
invio record N al WS
attesa...
processo la risposta
invio record 5 al WS
attesa...
processo la risposta
termino
Sarà:
Quote:
select su db
result set di 5 record
thread1: invio record 1 al WS
thread2: invio record 2 al WS
thread3: invio record 3 al WS
thread4: invio record 4 al WS
thread5: invio record 5 al WS
attesa... [in teoria solo 30 sec. circa, se il WS processa più richieste in parallelo]
thread1: processo risposta 1
thread2: processo risposta 2
thread3: processo risposta 3
thread4: processo risposta 4
thread5: processo risposta 5
termino
Ma quindi i tuoi dubbi circa i benefici dell'usare più thread in questo scenario quali sono? No perchè, chiarendo i miei dubbi ti sei praticamente risposto da solo
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 25-02-2011 alle 11:59.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 12:05   #8
anonimizzato
 
Messaggi: n/a
Quote:
Originariamente inviato da banryu79 Guarda i messaggi
Ok, non avevo capito.

Allora il WS già acetta e processa richieste multiple; è il client che ne spedisce una e attende la risposta in modo sincrono, quando invece potrebbe spedirne varie contemporaneamente. Che è quello che dovrete fare.

Ma quindi i tuoi dubbi circa i benefici dell'usare più thread in questo scenario quali sono? No perchè, chiarendo i miei dubbi ti sei praticamente risposto da solo
Ho parlato con il mio capo progetto e posso confermare quanto ho riportato prima.

Il dubbio era legato all'uso delle risorse lato WS, mi spiego:

// PROCEDURA SEQUENZIALE
Se devo fare un ciclo su 2 record ed invocare per entrambi il WS che ci impiega 30 secondi l'uno, vuole dire che avrò completato la mia procedura in 60 secondi giusto?

// PROCEDURA A THREAD
Utilizzando invece 2 thread separati sull'applicazione client (due invocazioni contemporanee quindi) chi mi dice che il WS ci mette sempre 30 secondi ad ogni elaborazione?
Nel caso così fosse io avrò completato la stessa procedura nella metà del tempo visto che avrò le 2 risposte entrambe dopo 30 sec.

Il dubbio nasce dal fatto che, se io "bombardo il WS" di richieste simultanee (thread sul client) il WS non dovrebbe ridurre notevolmente la sua capacità elaborativa e quindi impiegare più tempo per ogni risposta?

Grazie ancora.
  Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 13:09   #9
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da Sgurbat Guarda i messaggi
Il dubbio nasce dal fatto che, se io "bombardo il WS" di richieste simultanee (thread sul client) il WS non dovrebbe ridurre notevolmente la sua capacità elaborativa e quindi impiegare più tempo per ogni risposta?
Boh. Dipende da come è fatto il WS naturalmente.
Io la vedo così.
Il client spedisce più richieste "in parallelo" al WS, con diversi thread.
Lato WS ci sarà il classico thread pool che riceve le richeste e le processa con i vari thread a disposizione. Un thread pool è configurabile in base alle esigenze (vedi package java.concurrent).
Naturalmente bisogna che il WS si strutturato in modo che il processo "calcolone da 30 sec" possa essere svolto da più thread contemporaneamente.
Se il calcolone usasse anche una sola risorsa che non può essere condivisa ma deve essere usata in modo esclusivo per tutto il tempo, ciao ciao.
Spero di non aver postato boiate
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 15:34   #10
anonimizzato
 
Messaggi: n/a
Quote:
Originariamente inviato da banryu79 Guarda i messaggi
Boh. Dipende da come è fatto il WS naturalmente.
Io la vedo così.
Il client spedisce più richieste "in parallelo" al WS, con diversi thread.
Lato WS ci sarà il classico thread pool che riceve le richeste e le processa con i vari thread a disposizione. Un thread pool è configurabile in base alle esigenze (vedi package java.concurrent).
Naturalmente bisogna che il WS si strutturato in modo che il processo "calcolone da 30 sec" possa essere svolto da più thread contemporaneamente.
Se il calcolone usasse anche una sola risorsa che non può essere condivisa ma deve essere usata in modo esclusivo per tutto il tempo, ciao ciao.
Spero di non aver postato boiate
Grazie ancora.

Vi farò sapere.
  Rispondi citando il messaggio o parte di esso
 Rispondi


Redmi Pad 2 9.7: ampio display, economico e peso contenuto, ma qualche limite nelle prestazioni Redmi Pad 2 9.7: ampio display, economico e peso...
Peugeot Polygon Concept: ecco il futuro delle utilitarie Peugeot Polygon Concept: ecco il futuro delle ut...
Reno16 Pro: il compatto di OPPO punta su fotocamera da 200MP e il nuovo Bubble! La recensione Reno16 Pro: il compatto di OPPO punta su fotocam...
 Hisense 55U7SE: tuttofare e accessibile, il MiniLED per film, sport e gioco Hisense 55U7SE: tuttofare e accessibile, il Min...
Kindle Scribe Colorsoft: riduce le cornici e diventa a colori, ma il prezzo è alto Kindle Scribe Colorsoft: riduce le cornici e div...
Visa Intelligent Commerce: gli agenti di...
Broadcom prolunga la collaborazione con ...
Assassin's Creed Black Flag Resynced mos...
HillMiles MileCity1 in offerta su Amazon...
3 portatili in offerta da non perdere: A...
Fusione nucleare, Proxima Fusion raccogl...
xAI cambia ufficialmente nome in SpaceXA...
Le 10 offerte TOP Amazon: ci sono divers...
Un data center di Meta ha portato un bat...
Il chip cinese 478 volte più velo...
Reddit usa l'AI per fermare l'AI: blocca...
Il presunto guasto hardware della Steam ...
LG QNED80, OLED C5 e OLED evo C6: 3 Smar...
Google cambia le regole del backup Andro...
Utili da capogiro per Samsung, ma il mer...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 11:22.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v