Visualizzazione dei risultati da 1 a 6 su 6
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2012
    Messaggi
    776

    Da Php usando la PDO, meglio una select che seleziona 50 record o 50 select che selezionano 1 record alla volta?

    Ciao a tutti,
    la logica mi dice che sia meglio la prima soluzione pero, quanto guadagnerei in termini di velocit�/prestazioni?

    Vi spiego:

    Carico una pagina html da PHP, cerco delle corrispondenze all'interno della pagina stessa che non sono altro che un valore assoluto all'interno di una tabella traduzioni, es:

    la parola all'interno del file html #SALUTO#, viene sostituita con la corrispondenza della lingua scelta ovvero, all'interno della tabella traduzioni esiste il valore univoco 'saluto', che , se la pagina � in italiano, mi restituisce 'ciao', mentre se la pagina � in spagnolo mi restituisce 'hola'.
    Ovviamente il testo puo essere pi� lungo a seconda della pagina e puo essere composto da molte parole da tradurre, diciamo almento 40/50 per pagina, alcune sono parole singole, altre possono essere un testo html e la tabella ha circa 1000 record.
    Per ogni parola, attualmente, faccio una select alla tabella traduzioni cercando il suo valore relativo.
    Lo stesso sistema lo uso su un altro sito che � online da quasi 3 anni e il caricamento delle pagine � rapido.
    Guadagnerei molto, in termini di velocit�, ad effettuare una sola select per tutte le parole da tradurre al posto che fare una select per ogni parola?

    Grazie,
    Roberto

  2. #2
    Utente di HTML.it
    Registrato dal
    Oct 2014
    Messaggi
    519
    all'interno della tabella traduzioni esiste il valore univoco 'saluto'
    la lettura del db con un'unica select migliora i tempi, ma di quanto ?

    qui vedi i risultati di un tool Microsoft che ha misurato un eseguibile
    l'eseguibile leggeva un record alla volta,
    dopo la "ristrutturazione", la lettura è stata resa unica con delle join (credo sia una situazione diversa da quella proposta)

    Microsoft PLIST Version 1.00
    Profile: Function timing, sorted by time.
    Program Statistics
    Total time: 57542.664 milliseconds
    Total functions: 29 <- numero delle funzioni presenti nell'eseguibile

    tempo di preparazione : 48 sec <- lettura del db
    tempo di ottimizzazione : 0 sec <- puro calcolo
    tempo di memor.risultato : 5 sec <- scrittura del risultato nel db
    tempo totale di elab.ne : 53 sec

    Microsoft PLIST Version 1.00
    Profile: Function timing, sorted by time.
    Program Statistics
    Total time: 19592.594 milliseconds
    Total functions: 33

    tempo di preparazione : 14 sec
    tempo di ottimizzazione : 0 sec
    tempo di memor.risultato : 3 sec
    tempo totale di elab.ne : 17 sec

    la differenza è notevole, l'analisi è stata fatta con una macchina vecchia a basse prestazioni che ha messo in luce la forte diversità

    bisogna comunque tenere conto di altri fattori,

    la colonna del valore univoco 'saluto' deve essere indicizzata e l'indice deve poter essere sfruttato nella ricerca
    la ricerca deve essere fatta sul valore compiuto e non con "like"
    la macchina che gestisce il db, (in particolare i dischi) dovrebbe essere molto "veloce" e non avere carichi che possono ridurre le prestazioni

    si dovrebbero utilizzare tool di analisi delle query per ottenere suggerimenti sulla miglior indicizzazione del db
    in casa Microsoft "Database Engine Tuning Advisor"

    in ogni caso, si, la lettura unica migliora le prestazioni,
    le macchine moderne potrebbero nascondere questi miglioramenti, vedi dischi a stato solido

    nel caso facessi delle prove, ricordati di riavviare il "motore" del database per evitare la cache

  3. #3
    Utente di HTML.it
    Registrato dal
    Sep 2016
    Messaggi
    783
    Puoi fare delle misurazione utilizzando la funzione microtime() prima e dopo l'esecuzione del fetch e vedere di quanto ti cambia.
    Volendo puoi anche attivare il profiling, anche se è un po' più complicato da implementare.

    In generale fare una sola query risulta decisamente più veloce, io andrei in quella direzione.

  4. #4
    Utente di HTML.it
    Registrato dal
    May 2012
    Messaggi
    776
    Quote Originariamente inviata da M4V1 Visualizza il messaggio
    Puoi fare delle misurazione utilizzando la funzione microtime() prima e dopo l'esecuzione del fetch e vedere di quanto ti cambia.
    Volendo puoi anche attivare il profiling, anche se è un po' più complicato da implementare.

    In generale fare una sola query risulta decisamente più veloce, io andrei in quella direzione.
    Grazie ad antrambi per i suggerimenti.
    Attualmente, tramite una callback sostituisco tutte le occorenze trovate nella pagina html una per una.

    Dovrei, estrarre tutte le occorenze (valori assoluti) in un array analizzando tutta la pagina html, creare una select unica e poi rianalizzare la pagina html e sostituire le occorrenze con i valori relativi.
    Ma il mio dubbio è:
    il fatto di effettuare una singola select per 60 ricorrenze trovate come:

    Codice PHP:
    select it from traduzioni where valoreassoluto='saluto' LIMIT 1 
    oppure fare una select con tutte le occorrenze da trovare:

    Codice PHP:
    select it from traduzioni where valoreassoluto='saluto' OR valoreassoluto='parola'....{altre 58 volte
    Comunque per ogni record della tabella dovrà verificare se una delle 60 condizioni viene compiuta.

    Mettiamo il caso che i record della tabella siano 1000:
    Nel primo caso, una select per ogni parola, appena verificata la condizione, smetterà la ricerca, questo vuol dire che la condizione si potrebbe verificare al record 1, record 100, oppure record 1000.
    Quindi 1 verifica per il numero della posizione del record che compie la condizione, per ogni parola cercata.

    Mentre nel secondo caso dovra controllare in sequenza le 60 condizioni per tutti i record della tabella fino a quando la condizione, riga per riga, non si compie.

    Il numero sarà simile.

    Comunque, prima di effettuare cambi nel codice, provero a calcolare i tempi di esecuzione di 50 select o una select unica, tenendo conto che nel primo caso, sostituisco subito il valore, mentre nel secondo caso, devo analizzare la pagina html due volte.

    Per pochi millesimi di secondi, non toccherei il codice!

    Roberto
    Ultima modifica di robynosse; 16-03-2018 a 17:21

  5. #5
    uhm forse io non ho ben capito la questione, ma reputo inutile fare una query 1000 volte invece che farne una che tira fuori i risultati voluti..
    senza contare che una singola query tira fuori un record set sul quale fare operazioni, e che puoi salvare per usarla in più punti di una pagina.

    cosa che non ottieni nell'altro modo.

  6. #6
    Utente di HTML.it
    Registrato dal
    May 2012
    Messaggi
    776
    Ho risolto in questo modo:
    Dal momento che sto lavorando in MVC, tramite 2 metodi che mi restituiscono il nome del controller e il metodo chiamato, quando faccio una interrogazione alla tabella traduzioni, salvo in un'altra tabella un record unico con 3 parametri(controller, metodo e id della parola tradotta).
    In questo modo, quando chiamo il controller e il metodo, posso sapere in anticipo quali sono le parole che utilizzo in un determinato controller, metodo, e le carico in un array con una singola select.
    Quando richiedo la traduzione di una determinata parola, vado quindi prima di tutto a cercare la parola nell'array e, se non esiste, vado a cercarla nella tabella traduzioni (basta aver utilizzato la pagina almeno una volta e la parola sarà nell'array al caricamento successivo della pagina).
    Ho inoltre impostato una variabile globale "impara" che se è impostata su TRUE effettua l'operazione di scrittura del record unico con i 3 parametri(controller, metodo, id della parola tradotta) mentre se è false non esegue tale operazione.

    Roberto

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.