Connessione database

[kairos2020]

Buongiorno,
quando ho una pagina dalla quale accedo al database di norma uso questo codice :

require_once __DIR__ . '/include/Base.php';
require_once __DIR__ . '/include/ClSysSecure.php';
/* Gestione sessioni, ne apre una */
require_once __DIR__ . '/include/ClConnect.php';
require_once __DIR__ . '/include/ClCapsule.php';
$secur = new ClSysSecure();
$conn = new ClConnect();
$PDO = $conn->dbConnection();
$capsule = new ClCapsule($PDO);
session_regenerate_id();
.. 

Mi sentivo soddisfatto, però ... la pagina può essere ricaricata più volte dall'utente, anzi di norma
lo è dato che visualizza gruppi di capsule che possono raggiungere il numero di oltre 100 e pertanto
è attivo una funzione di pagining, inoltre è presente una maschera per la creazione di un filtro, infine
l'utente può cambiare l'ordine di visualizzazione dei record.

Il dubbio, ad ogni caricamento di pagina apro una connessione al database, non credo che questa richieda molte risorse ma sicuramente moltiplicare questo 'peso' per n volte potrebbe incidere sulle prestazioni, non ho idea di quanto incida ma anche pochisso per molte volte può diventare significativo.

Mi chiedo, è possibile, e consigliabile, utilizzare una connessione persistente, ovvero che non cessi alla chiusura del form che l'ha creata,o nel caso di un massimo di 350 utenti registrati di cui mediamente il 25% collegato in contemporanea il 'peso' della connessioni non sia determinante.

Le richieste effettuate al db riguardano il caricamento di fotografie in formato webp 400x400 non credo esista formato più performante e pertanto non credo di poter migliore le prestazioni attinenti il caricamento delle foto.
Grazie

[dreadnaut]

Il carico di una connessione effimera non è una cosa di cui preoccuparsi. Per un server con molti utenti, è peggio avere tante (una per utente) connessioni persistenti, che tengono risorse occupate senza essere in uso.

Per le foto, l'unica cosa che mi viene in mente è tenerle fuori dal database. L'accesso è di solito più veloce, ma c'è un costo di manutenzione più alto visto che hai dati in due posti.

Altra cosa che mi viene in mente: rigenerare l'id della sessione ad ogni caricamento pagina mi pare eccessivo. Per evitare problemi di session fixation, l'importante è rigenerare l'id al momento del login. Successivamente, farlo "ogni tanto" (minuti, ore, giorni) è una sicurezza in più, ma grazie ad HTTPS una cosa meno importante.

[kairos2020]

Buongiorno,
grazie per la risposta, allora sono 'a posto' per quanto attiene il database.
Le foto, mi sono spiegato davvero male e mi scuso, vengono caricate da una directory sono sono conservate per codice, accedo al database per creare l'array con i codici che scorro e trasformo in echo a video, intendevo dire che per quanto attiene il peso delle immagini ritengo di aver fatto 'il meglio' nel senso che il formato webp dovrebbe essere il miglior compromesso tra peso/qualità e la dimensione è la minore possibil per una visione ottimale, inoltre sto scrivendo una routine che nella 'griglia' carica immagini 150x150 e nella scheda le 400x400.
Avrei dovuto farlo da subito, ma visto che non c'erano evidenti rallentamenti... Grazie

P.s. Dimenticavo una routine legge il browser e controlla la compatibilità dello stesso con webp, se non è compatibile utilizzo il formato jpg, mi pare che solo otto utenti abbiano questo 'problema'.

[dreadnaut]

P.s. Dimenticavo una routine legge il browser e controlla la compatibilità dello stesso con webp, se non è compatibile utilizzo il formato jpg, mi pare che solo otto utenti abbiano questo 'problema'.

Invece di fare questo lavoro lato server, puoi lasciarlo al browser usando <picture>, vedi: https://web.dev/serve-images-webp/#serve-webp-images. Se preferisci comunque farlo sul server, puoi usare l'header Accept.

In generale il web ha raggiunto un punto per cui puoi applicare questa regola: se una feature ti richiede di controllare che browser l'utente sta usando, probabilmente c'è un modo più semplice per fare la stessa cosa lato browser.

[kairos2020]

Buongiorno, ho letto del tag <picture> che se non sbaglio permette anche di cambiare l'immagine caricata in base alla definizione del dispositivo in uso.

Leggerò con attenzione i link suggeriti.

Una domanda (aggiuntiva) è corretto asserire che le procedure/operazioni lato server sono più sicure/veloci di quelle
lato browser ? Chiedo questo per darmi, se possibile, una linea guida, quando è possibile sceglire tra le due opzioni.

Spero non sia un quesito tipo " Mi chiamo Mauro ... quanto peso?"
Grazie per la pazienza

[dreadnaut]

Una domanda (aggiuntiva) è corretto asserire che le procedure/operazioni lato server sono più sicure/veloci di quelle
lato browser ? Chiedo questo per darmi, se possibile, una linea guida, quando è possibile sceglire tra le due opzioni.

Ci sono intere scuole di filosofia attorno a questo argomento

Nella mia esperienza, fai il più possibile lato server: il codice PHP è sotto il tuo controllo, gira in un singolo ambiente che puoi testare, è più difficile da manomettere. JavaScript da pochissime garanzie: potrebbe non caricare, potrebbe comportarsi diversamente da quello che ti aspetti, il browser sono in continuo movimento e non hai controllo sull'ambiente in cui il codice è eseguito. Se un utente ha un problema, potresti non accorgertene mai.

PHP ed HTML possono costruire siti complessi. Puoi poi usare (in ordine di priorità, a mio parare) moderno HTML, CSS, e se hai esaurito le possibilità JavaScript per aggiungere dettagli interattivi non fondamentali per quello che stai costruendo.

Le possibilità erano più limitate 5-10 anni fa, ma l'HTML e CSS degli anni '20 fanno tutto e di più.

[kairos2020]

Buongiorno, mi conforta ricevere (per una volta) un parere che conferma 'le mie linee guida'.
In effetti la mia esperienza è limitata al sito della mia collezione, che in cinque anni anni ho completamente riscritto almeno tre volte, nell' versione utilizzo quel poco di JavaScript che sto faticosamente imparando.
Mi sono però accorto che tutto quello che davvero mi serviva possono ottenerlo anche in PHP... quasi tutto.
Nel form di upload di una immagine, pur cercando lumgamente sul web, una routine con la preview dell'immagine selezionata senza il submit non sono riuscito a trovarla, sempre in un form una fuzione che caricasse una tabella
in un <select> in base alla selezione sul <select> precedente ho realizzato non essere possibile senza AJAX.
A parte queste due funzionalità il sito funziona, sembra funzionare bene anche senza codice JavaScript creato AD HOC.
Grazie

[dreadnaut]

Nel form di upload di una immagine, pur cercando lumgamente sul web, una routine con la preview dell'immagine selezionata senza il submit non sono riuscito a trovarla, sempre in un form una fuzione che caricasse una tabella
in un <select> in base alla selezione sul <select> precedente ho realizzato non essere possibile senza AJAX.

Si, JavaScript è la mossa giusta per questo tipo di "guarnizione" che migliora l'interfaccia: se funziona c'è una bella anteprima; se ha qualche problema, il form funziona comunque.

Il doppio select magari si può aggirare con due form separati (soluzione così così), oppure cose tipo <optgroup> o <datalist>. Ma spesso JS è la via.

[kairos2020]

Buongiorno, probabilmente in un paio di situazioni potrei utilizzare <optgroup> con profitto.
Proprio oggi mi si è presentata la necessità di valorizzare una label con i valori di una select multipla
in modo che l'utente possa chiaramente vedere i nomi selezionati.
In realtà è ridondante ma gli utenti, collezionisti di capsule di spumante, hanno un'età media di circa 70 anni,
e molti usano pc tablet etc esclusivamente per gestire le proprie capsule, nulla è mai sufficiente per semplificare
loro l'uso del 'nuovo' strumento.
Grazie, per la cortese attenzione