Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

di il
47 risposte

47 Risposte - Pagina 2

  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    No no, assolutamente no!
    Allora devi migliorare la conoscenza di interfacce, functional interface, lambda expression e in generale su come passare dei "comportamenti" a del codice.
    Altrimenti non riusciresti a fare in autonomia cose come il ForkJoinListMutator che ho scritto io.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Sto provando a testare il codice per scrivere dati nel database e registro dei grandi margini di miglioramento però noto una cosa stranissima che non mi spiego. Non prestare molta attenzione al codice, è scritto male e velocemente.
    Ho timore di commettere qualche errore nella scrittura dei dati nel database.
    Il metodo seguente funziona e viaggia circa 4 volte più veloce del ciclo for.
    
        private void creaUtenti2(Long numeroUtenti, String nomi, String password){
            List<String> nomiUtente = new ArrayList<String>();
            for(int i=0; i<numeroUtenti; i++){
                nomiUtente.add(nomi+" "+(i+1));
            }
            int core = Runtime.getRuntime().availableProcessors();
            ForkJoinListMutator listMutator = ForkJoinListMutator.getDefault();
            listMutator.mutate(
                    nomiUtente,
                    nomiUtente.size()/core,
                    (i, n) -> registrazione(n, password).getNome()
            );
        }
    
    In sostanza creo una lista di String con N nomi utente differenti e li registro a database con registrazione(). Se nel metodo registrazione() metto 2 query, una per scrivere il dato e l'altro per recuperarlo ottengo questo errore:
    org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0
    Perché la query per cercare il dato manda in tilt il sistema?
    Detto in altro modo perché in registrazione non posso mettere 50 o 60 query ma solo una?
    
        private Long numeroUtenti = 100L;
    
        @Test
        public void testSingleThreading(){
            // Si caricano nel database una serie di dati specifici per eseguire il presente test:
            caricaDatabasePerIlTest();
            // --
            long t1 = System.nanoTime();
            String primoNome = "Utente";
            String primaPassword = "password123ABC%";
            creaUtenti(numeroUtenti, primoNome, primaPassword);
            long t2 = System.nanoTime();
            System.out.println("testSingleThreading() -> " + (long) (t2-t1)/1000000000 + " secondi");
            // --
            caricaDatabasePerIlTest();
        }
    
        @Test
        public void testMultiThreading(){
            // Si caricano nel database una serie di dati specifici per eseguire il presente test:
            caricaDatabasePerIlTest();
            // --
            long t1 = System.nanoTime();
            String primoNome = "Utente";
            String primaPassword = "password123ABC%";
            creaUtenti2(numeroUtenti, primoNome, primaPassword);
            long t2 = System.nanoTime();
            System.out.println("testMultiThreading() -> " + (long) (t2-t1)/1000000000 + " secondi");
            // --
            caricaDatabasePerIlTest();
        }
    
        private Utente registrazione(String nomeIscritto, String passwordIscritto){
            Registrazione registrazione = new Registrazione(
                    nomeIscritto,
                    passwordIscritto,
                    passwordIscritto
            );
            eseguiRegistrazione.registrazione(
                    registrazione,
                    caratteriConsentiti,
                    gestionePassword
            );
            Utente utente = utenteRepository.trovaUtente(nomeIscritto);
            return utente;
        }
    
        private List<Utente> creaUtenti(Long numeroUtenti, String nomi, String password){
            List<String> nomiUtente = new ArrayList<String>();
            for(int i=0; i<numeroUtenti; i++){
                nomiUtente.add(nomi+" "+(i+1));
            }
            List<Utente> utenti = new ArrayList<Utente>();
            for(int i=0; i<nomiUtente.size(); i++){
                utenti.add(registrazione(nomiUtente.get(i),password));
            }
            return utenti;
        }
    
        private void creaUtenti2(Long numeroUtenti, String nomi, String password){
            List<String> nomiUtente = new ArrayList<String>();
            for(int i=0; i<numeroUtenti; i++){
                nomiUtente.add(nomi+" "+(i+1));
            }
            int core = Runtime.getRuntime().availableProcessors();
            ForkJoinListMutator listMutator = ForkJoinListMutator.getDefault();
            listMutator.mutate(
                    nomiUtente,
                    nomiUtente.size()/core,
                    (i, n) -> registrazione(n, password).getNome()
            );
        }
    
    Curiosità: Nel caso la mia app fosse pubblicata e N utenti si registrassero in contemporanea la procedura di registrazione gestita da Tomcat avverrebbe in parallelo oppure no?
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Potrebbe essere un problema di deadlock. A tuo avviso è risolvibile oppure un utente può scrivere nel db solo con 1 thread?
    Anche questo semplice codice:
    List<String> nomiUtenteB = nomiUtente.parallelStream().map(n -> registrazione(n, password).getNome()).collect(Collectors.toList());
    fornisce questo:
    org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Appena finito questa esercitazione mi prendo un bel manuale di java perché mi mancano molte cose, ma anche di db come puoi vedere. In teoria bisognerebbe anche conoscere bene javascript. Insomma sono messo male.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    Ho timore di commettere qualche errore nella scrittura dei dati nel database.
    Il metodo seguente funziona e viaggia circa 4 volte più veloce del ciclo for.
    Allora:

    1) Io ti ho mostrato il "mio" ForkJoinListMutator come strumento per modificare "in loco" una lista in maniera parallelizzabile. Ma in generale il Fork-Join pool NON è stato pensato e fatto per fare operazioni di I/O o su DB. Insomma, dovrebbe essere usato solo per computazioni "pure", non per cose potenzialmente lunghe/bloccanti.

    Se vuoi davvero fare query su DB in maniera parallelizzabile, allora dovresti usare un thread pool "normale", quello a cui si sottomettono dei "task" (Runnable/Callable). Non il Fork-Join.

    Nel tuo caso comunque il concetto di modifica della lista ha pure poco senso, perché si presuppone che il getNome() dia lo stesso nome (magari solo come oggetto diverso, distinto) uguale al nome passato a registrazione(n, .....). Quindi cosa cambia nella lista?? Concettualmente nulla ....


    2) Ti stai fissando sul fatto di pensare che se hai solo 4 core puoi avere solo 4 scritture in parallelo su db, cioè un parallelismo uguale al numero dei core. Sbagliato!! Quando hai un "lavoro" da rendere parallelizzabile, devi avere ben chiaro se si tratta di un lavoro che usa molto la cpu o usa molto il I/O (si intende I/O su file ma anche networking o accesso a DB).

    Fare es. un reverse su una stringa (non grossa) può richiedere microsecondi (anche meno ...), fare una query su DB può richiedere millisecondi. Stiamo parlando di un rapporto 1:1000.
    Se il tuo lavoro fa quasi esclusivamente query su db, il problema non è il processore ... ma le Connection al DB.
    Ora, io non so se/come hai configurato il connection-pool. In Spring Boot il HikariCP se non sbaglio (e se non hanno cambiato di recente) usa per default un max di 10 Connection al DB.

    Se hai max 10 Connection, è inutile avere un mega processore con 32 core. Anche creando 32 thread (idealmente, uno per core), la maggior parte dei thread starebbe lì fermo in sospensione, in attesa di ottenere una Connection libera. Questo non è "scalare" in prestazioni.
    Lo dico in altro modo: se i tuoi lavori da parallelizzare fanno quasi esclusivamente query su DB, il "collo di bottiglia" NON è il numero dei core ... ma delle Connection!!

    iBaffiPro ha scritto:


    In sostanza creo una lista di String con N nomi utente differenti e li registro a database con registrazione(). Se nel metodo registrazione() metto 2 query, una per scrivere il dato e l'altro per recuperarlo ottengo questo errore:
    org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0
    Perché la query per cercare il dato manda in tilt il sistema?
    Senza vedere bene cosa c'è "sotto" quel

    private Utente registrazione(String nomeIscritto, String passwordIscritto){

    (in particolare COSA fanno eseguiRegistrazione.registrazione() e utenteRepository.trovaUtente() )

    è parecchio difficile da dire.

    iBaffiPro ha scritto:



    Nel caso la mia app fosse pubblicata e N utenti si registrassero in contemporanea la procedura di registrazione gestita da Tomcat avverrebbe in parallelo oppure no?
    Ciascuna richiesta HTTP viene "servita" da un thread a sé stante, quindi dipendentemente da come è configurato il web server, sì, le richieste possono essere molto in parallelo (anche centinaia).

    iBaffiPro ha scritto:


    Appena finito questa esercitazione mi prendo un bel manuale di java
    Anche due .... o tre ..... su ambiti più specialistici .....

    iBaffiPro ha scritto:


    perché mi mancano molte cose
    Sì moooooolte, purtroppo. Se non migliori un po' le conoscenze, temo che continuerai a scrivere codice per niente buono e per niente ottimale come prestazioni.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Scusa per la lungaggine nel risponderti ma sono stato occupato con altro in questo periodo.
    Quale sistema mi consigli per scrivere più velocemente record in un database?
    Per esempio con jdbcTemplate se devo scrivere 200000 record è giusto fare in questo modo:
    INSERT INTO tabella (c1, c2) VALUES (?, ?);
    oppure c'è qualche codice MySQL che posso aggiungere per velocizzare l'inserimento?
    Non so cosa siano connection-pool e HikariCP...
    Sul web trovo questo:
    https://www.baeldung.com/spring-boot-hikar
    come dovrei settare questi 3 parametri?
    spring.datasource.hikari.connectionTimeout=30000 
    spring.datasource.hikari.idleTimeout=600000 
    spring.datasource.hikari.maxLifetime=1800000 
    ...
    Però sembrano caratteristiche generali, a me interessa che le cose cambino solo in alcuni casi non sempre. Quando ad esempio scrivo:
    INSERT INTO utenti (nome, password) VALUES (?, ?);
    non ho nessuna esigenza e preferirei lasciare le cose come sono.
    Non sono esperto di SQL ma trovo strano che non esista una sintassi SQL specifica che permetta di distinguere una query di questo tipo:
    INSERT INTO utenti (nome, password) VALUES (?, ?);
    da 200000 di questo tipo:
    INSERT INTO tabella (c1, c2) VALUES (?, ?);
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    Quale sistema mi consigli per scrivere più velocemente record in un database?
    Per esempio con jdbcTemplate se devo scrivere 200000 record è giusto fare in questo modo:
    INSERT INTO tabella (c1, c2) VALUES (?, ?);
    oppure c'è qualche codice MySQL che posso aggiungere per velocizzare l'inserimento?
    Sì, l'INSERT è quello. Ma per fare TANTE operazioni così, la questione è un'altra. JDBC (la API nuda e cruda di Java) contempla il concetto di "batch". E a livello di JdbcTemplate (Spring) la funzionalità dei batch è stata altrettanto esposta come API. Basta che guardi nel javadoc di JdbcTemplate i metodi chiamati batchUpdate (non intende solo statement di UPDATE .. anche altri di aggiornamento!)

    iBaffiPro ha scritto:


    Non so cosa siano connection-pool e HikariCP...
    Male ... molto male ...

    iBaffiPro ha scritto:


    come dovrei settare questi 3 parametri?
    spring.datasource.hikari.connectionTimeout=30000 
    spring.datasource.hikari.idleTimeout=600000 
    spring.datasource.hikari.maxLifetime=1800000 
    ...
    Questi sono solo dei timeout, che hanno ovviamente un loro senso/significato e utilità. Ma usare un connection-pool significa anche saperlo dimensionare correttamente come quantità di connection minime/massime, ecc...
    E per questo ci sono varie altre property.

    Ma se non comprendi bene COSA è un connection-pool e a cosa SERVE ... diventa per te difficile andare più avanti.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Però ho un'esigenza in più, non voglio modificare il metodo di jdbcTemplate che uso per lanciare:
    INSERT INTO tabella (c1, c2) VALUES (?, ?);
    Questo perché sarebbe un lavoro troppo grande, non per la query in questione ovviamente ma per le modifiche che dovrei fare a tantissime altre query similari.
    Non vorrei sbagliare ma mi sembra di ricordare che esistessero dei codici SQL scritti prima della prima query e lanciati subito dopo la 200000-esima query che oltre a bloccare il DB ne aumentassero le performance. Probabilmente ricordo male e mi confondo con altro.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    Però ho un'esigenza in più, non voglio modificare il metodo di jdbcTemplate che uso per lanciare:
    INSERT INTO tabella (c1, c2) VALUES (?, ?);
    Lo devi cambiare, se volessi sfruttare il concetto dei "batch".

    iBaffiPro ha scritto:


    Questo perché sarebbe un lavoro troppo grande, non per la query in questione ovviamente ma per le modifiche che dovrei fare a tantissime altre query similari.
    "tantissime"?? Ma di quante query stiamo parlando? 10? 100? Di più?
    Scusa ma in generale che cosa stai cercando di fare?

    iBaffiPro ha scritto:


    Non vorrei sbagliare ma mi sembra di ricordare che esistessero dei codici SQL scritti prima della prima query e lanciati subito dopo la 200000-esima query che oltre a bloccare il DB ne aumentassero le performance. Probabilmente ricordo male e mi confondo con altro.
    La bacchetta magica in SQL non esiste .... se ti riferisci a certe istruzioni per il locking delle tabelle, qui dipende dal database. Su Oracle ad esempio ci sono. Su altri DB come PostgreSQL al momento non ho idea/non ricordo. Ma non è comunque il locking che "velocizza". Semmai serve più per questioni di atomicità e "integrità" delle modifiche.

    EDIT: comunque sarebbe anche il caso che vedi un po' meglio a cosa serve un connection-pool e come funziona la sua logica in generale.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Va be dai mi accontento di quello che ho. Se posso ti chiedo però un'ultima chiarificazione sui pool di connessioni, niente codice.
    Dal web apprendo che il pool di connessioni è una cache di connessioni al database gestite in modo che le connessioni possano essere riutilizzate quando sono necessarie richieste future al database. I pool di connessione vengono utilizzati per migliorare le prestazioni di esecuzione dei comandi su un database.
    Se devo importare un file .csv in un database uso il pool di connessioni mentre in una login no, giusto?
    Quando c'è il pool attivo (sto aggiungendo record sulla base di un file .csv) altre query possono essere eseguite (un utente si connette al database), giusto?
    I pool di connessioni vanno limitati perché la cache è limitata, in pratica è memoria ancora più veloce della classica RAM usata per le GPU, giusto?
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    Dal web apprendo che il pool di connessioni è una cache di connessioni al database gestite in modo che le connessioni possano essere riutilizzate quando sono necessarie richieste future al database. I pool di connessione vengono utilizzati per migliorare le prestazioni di esecuzione dei comandi su un database.
    Le connection al db sono molto "preziose", impegnano varie risorse, di memoria e soprattutto di networking (sia sul client sia sul server dove c'è il DB; che può essere la stessa macchina o due diverse). E inoltre creare una nuova connection può richiedere del tempo, anche svariati millisecondi.
    Per questi motivi, di Connection non ne puoi avere "a migliaia". E non puoi nemmeno crearne una ogni volta che ti pare o per ciascuna singola query. Questo in sostanza è il motivo per cui esistono i connection-pool. Mantengono in vita un numero ristretto di Connection che vengono RI-usate continuamente e molte volte.

    In JDBC il metodo basilare per ottenere una Connection è tramite il DriverManager con i metodi getConnection(String url, .....). Ma questi sono metodi statici, non è quindi una cosa facilmente "astraibile". Pertanto si usa un'altra cosa, ovvero il DataSource, cioè l'interfaccia che fa già parte di JavaSE chiamata javax.sql.DataSource. Che possiede 2 metodi importanti chiamati getConnection, ovvero concettualmente "dammi una Connection". Essendo una interfaccia, ci possono essere varie implementazioni. Difatti HikariCP ha una sua classe dove dichiara implements DataSource.

    Quando si usa una Connection (indipendentemente da dove arriva, se direttamente dal DriverManager o da un DataSource), si deve sempre fare la trafila di operazioni appropriate per chiudere tutte le risorse, arrivando anche a fare sempre il close() sulla Connection. E nota che JdbcTemplate di Spring fa tutta la trafila in modo corretto.

    Se la Connection è una non pooled (es. dal DriverManager), il close() chiude davvero quella connection al db. Ecco che arriva il punto importante: se la Connection è una di quelle fornite dal pool, il close() NON chiude la connection ma semplicemente "restituisce" la Connection al pool così che sia disponibile per altre richieste.

    iBaffiPro ha scritto:


    Se devo importare un file .csv in un database uso il pool di connessioni mentre in una login no, giusto?
    No. Una applicazione generalmente o usa un connection-pool per tutto o non lo usa affatto. Non ha molto senso (e sarebbe anche più difficile tecnicamente da gestire) fare solo alcune cose con il connection-pool e alcune altre senza.

    iBaffiPro ha scritto:


    Quando c'è il pool attivo (sto aggiungendo record sulla base di un file .csv) altre query possono essere eseguite (un utente si connette al database), giusto?
    Sì finché ci sono Connection disponibili dal connection-pool.

    iBaffiPro ha scritto:


    I pool di connessioni vanno limitati perché la cache è limitata, in pratica è memoria ancora più veloce della classica RAM usata per le GPU, giusto?
    No, non c'entra niente. Non è quel tipo di cache fisica. Invece, cache dal punto di vista "concettuale". Si tratta sempre di oggetti Java, sul heap space, esattamente come altri oggetti.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Perché esistono queste due metodologie per interagire con il DB?
    Se le connection-pool sono più veloci perché non usare solo quelle?
    Non ci sono contro ad usare le connection-pool?
    Se aggiornassi tutti metodi di jdbcTemplate avrei un incremento considerevole delle performance oppure solo dell’1%?
    Basterebbe aggiornare le classi Repository oppure dovrei riscrivere tutta l'applicazione?
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    Perché esistono queste due metodologie per interagire con il DB?
    Perché JDBC (tra l'altro introdotto solo nel JDK 1.1, quindi nemmeno dall'inizio di Java) è iniziato solo con quello, cioè con il package java.sql dove c'era il DriverManager e il resto.
    La parte del package javax.sql cioè DataSource e il resto è poi venuta dopo. Se non sbaglio, javax.sql proviene dal mondo JavaEE (c'è già nella API di JavaEE 1.2 https://docs.oracle.com/javaee/1.2.1/api ) e poi solo dopo è stato portato in JavaSE nel JDK 1.4.
    Insomma ... questa è stata la "evoluzione" di Java per JDBC.

    iBaffiPro ha scritto:


    Se le connection-pool sono più veloci perché non usare solo quelle?
    Perché ad esempio in applicazioni standalone JavaSE una singola connection potrebbe anche bastare. Da lì, cioè da applicazioni JavaSE basilari, è partito l'uso di JDBC.

    iBaffiPro ha scritto:


    Non ci sono contro ad usare le connection-pool?
    Che esiste sicuramente un limite max al numero di connection e questo è da valutare e impostare oculatamente.

    iBaffiPro ha scritto:


    Se aggiornassi tutti metodi di jdbcTemplate avrei un incremento considerevole delle performance oppure solo dell’1%?
    Sicuramente più del 1% ma non saprei quantificare ora.

    iBaffiPro ha scritto:


    Basterebbe aggiornare le classi Repository oppure dovrei riscrivere tutta l'applicazione?
    Dipende da come hai fatto i repository. Se nel repository hai già fatto un metodo tipo es.

    public void insertXyzs(List<Xyz> xyzs)

    dove all'interno fai un (banale) ciclo che racchiude una singola chiamata jdbcTemplate.update("INSERT ......", .....)

    allora basta cambiare solo qui, e non parti più "sopra".

    Però, attenzione. Considera che un "batch" di statement non può essere lunghissimo. Se hai 1000 record da inserire NON puoi fare un batch di 1000 insert! Diciamo che un 50~100 statement per batch è generalmente ok. Ma molti di più sarebbe problematico e controproducente.

    Quindi bisogna spezzettare la lista in piccoli blocchi e fare un "batch" per ciascun blocco. A seconda di quale variante di batchUpdate di JdbcTemplate usi, lo splitting lo devi fare tu o lo può fare JdbcTemplate. Basta vedere il javadoc.

    Io sarei perfettamente in grado di farlo. Non so se ci arriveresti tu (come non c'eri arrivato alle modifiche del ForkJoinListMutator con il Supplier, se ben ricordi).

    P.S. se mi dici che non riesci ad arrivarci, ti scrivo un esempio appena posso. Ma cerca prima di ragionarci un po' ... se non riesci in questi piccoli design, non farai poi cose più complesse.
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    Se cerco HikariCP trovo questa pagina:
    https://www.baeldung.com/spring-boot-hikar
    dove c'è scritto che HikariCP è già incluso in questa dipendenza:
    
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-jdbc</artifactId>
    		</dependency>
    
    che io uso nel mio progetto.
    Quindi io uso già un connection-pool, bisogna solo verificare che le impostazioni di default siano quelle corrette.
    A questa pagina:
    https://github.com/brettwooldridge/HikariCP#configuration-knobs-baby
    trovo questa lista:
    spring.datasource.hikari.allow-pool-suspension
    spring.datasource.hikari.auto-commit
    spring.datasource.hikari.catalog
    spring.datasource.hikari.connection-init-sql
    spring.datasource.hikari.connection-test-query
    spring.datasource.hikari.connection-timeout
    spring.datasource.hikari.data-source-class-name
    spring.datasource.hikari.data-source-j-n-d-i
    spring.datasource.hikari.data-source-properties
    spring.datasource.hikari.driver-class-name
    spring.datasource.hikari.exception-override-class-name
    spring.datasource.hikari.health-check-properties
    spring.datasource.hikari.health-check-registry
    spring.datasource.hikari.idle-timeout
    spring.datasource.hikari.initialization-fail-timeout
    spring.datasource.hikari.isolate-internal-queries
    spring.datasource.hikari.jdbc-url
    spring.datasource.hikari.keepalive-time
    spring.datasource.hikari.leak-detection-threshold
    spring.datasource.hikari.login-timeout
    spring.datasource.hikari.max-lifetime
    spring.datasource.hikari.maximum-pool-size
    spring.datasource.hikari.metric-registry
    spring.datasource.hikari.metrics-tracker-factory
    spring.datasource.hikari.minimum-idle
    spring.datasource.hikari.password
    spring.datasource.hikari.pool-name
    spring.datasource.hikari.read-only
    spring.datasource.hikari.register-mbeans
    spring.datasource.hikari.scheduled-executor
    spring.datasource.hikari.schema
    spring.datasource.hikari.transaction-isolation
    spring.datasource.hikari.username
    spring.datasource.hikari.validation-timeout
    In questa una strategia di configurazione:
    https://www.javadevjournal.com/spring-boot/spring-boot-hikari/
    Ho provato a scrivere una decina di cicli for che scrivono in svariate tabelle del mio database e non ho notato nessun miglioramento. Con la configurazione di Hikari impiego 36 secondi a fare tutto, senza configurazione sempre 36 secondi per cui non vedo l'utilità di andare a modificare la configurazione standard del connection-pool.
    Ho semplicemente editato il .properties con queste stringhe, non ho fatto altro:
    # maximum number of milliseconds that a client will wait for a connection
    spring.datasource.hikari.connection-timeout = 20000
    # minimum number of idle connections maintained by HikariCP in a connection pool
    spring.datasource.hikari.minimum-idle = 1000
    # maximum pool size
    spring.datasource.hikari.maximum-pool-size = 1000
    # maximum idle time for connection
    spring.datasource.hikari.idle-timeout = 60000
    # maximum lifetime in milliseconds of a connection in the pool after it is closed.
    spring.datasource.hikari.max-lifetime = 1000
    # default auto-commit behavior.
    spring.datasource.hikari.auto-commit = true
  • Re: Creare un codice indipendente ed immutabile per far lavorare in multithreading un ciclo for parallelizzabile

    iBaffiPro ha scritto:


    dove c'è scritto che HikariCP è già incluso in questa dipendenza:
    
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-jdbc</artifactId>
    		</dependency>
    
    Sì, lo dice bene qui, dove spiega anche la logica di scelta del connection-pool: 1.1.4. Supported Connection Pools

    iBaffiPro ha scritto:


    spring.datasource.hikari.minimum-idle = 1000
    spring.datasource.hikari.maximum-pool-size = 1000
    
    Scusa ma ti rendi conto di cosa vuol dire tenere 1000 connection??? Leggi About Pool Sizing che è meglio ....
Devi accedere o registrarti per scrivere nel forum
47 risposte