Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Renault Twingo E-Tech Electric: che prezzo!
Renault Twingo E-Tech Electric: che prezzo!
Renault annuncia la nuova vettura compatta del segmento A, che strizza l'occhio alla tradizione del modello abbinandovi una motorizzazione completamente elettrica e caratteristiche ideali per i tragitti urbani. Renault Twingo E-Tech Electric punta su abitabilità, per una lunghezza di meno di 3,8 metri, abbinata a un prezzo di lancio senza incentivi di 20.000€
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media
Nel Formula 1 Technology and Media Centre di Biggin Hill, la velocità delle monoposto si trasforma in dati, immagini e decisioni in tempo reale grazie all’infrastruttura Lenovo che gestisce centinaia di terabyte ogni weekend di gara e collega 820 milioni di spettatori nel mondo
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica
Il nuovo gimbal mobile DJI evolve il concetto di tracciamento automatico con tre modalità diverse, un modulo multifunzionale con illuminazione integrata e controlli gestuali avanzati. Nel gimbal è anche presente un'asta telescopica da 215 mm con treppiede integrato, per un prodotto completo per content creator di ogni livello
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 24-02-2011, 17: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, 17: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, 17: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, 20: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, 20: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 20:40.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 08: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, 12: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 12:59.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-02-2011, 13: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, 14: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, 16: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


Renault Twingo E-Tech Electric: che prezzo! Renault Twingo E-Tech Electric: che prezzo!
Il cuore digitale di F1 a Biggin Hill: l'infrastruttura Lenovo dietro la produzione media Il cuore digitale di F1 a Biggin Hill: l'infrast...
DJI Osmo Mobile 8: lo stabilizzatore per smartphone con tracking multiplo e asta telescopica DJI Osmo Mobile 8: lo stabilizzatore per smartph...
Recensione Pura 80 Pro: HUAWEI torna a stupire con foto spettacolari e ricarica superveloce Recensione Pura 80 Pro: HUAWEI torna a stupire c...
Opera Neon: il browser AI agentico di nuova generazione Opera Neon: il browser AI agentico di nuova gene...
Snap e Perplexity unite: dal prossimo an...
La Cina dice addio a NVIDIA? Il governo ...
Microlino, simbolo italiano della mobili...
Apple disattiverà la sincronizzaz...
Google lancia l'allarme: attenzione ai m...
Primo test drive con Leapmotor B10: le c...
'Non può essere un robot': l'uman...
Monopattino elettrico Segway Ninebot Max...
Syberia Remastered è disponibile:...
Sony scopre che tutti i modelli AI hanno...
Amazon nasconde un -15% su 'Seconda Mano...
Due occasioni Apple su Amazon: iPhone 16...
Verso la fine della TV tradizionale? I g...
Cassa JBL a 39€, portatili, smartphone, ...
Cometa interstellare 3I/ATLAS: la sonda ...
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: 20:17.


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