Qual è l'archiviazione di sessione più affidabile in PHP: Memcache, database o file? [chiuso]


10

Qual è il modo migliore e più sicuro per gestire le sessioni PHP. È il modo migliore per archiviare sessioni in:

  1. Database (più affidabile, ma collo di bottiglia elevato, bassa velocità, non adatto a siti Web ad alto utilizzo di database)?

  2. Memcache (super veloce, ma ha distribuito più problemi di sicurezza, possibilità di perdere dati al riavvio del server e possibilità di perdere dati quando la cache è piena)?

  3. File (opzione predefinita, immagino lento poiché legge e scrive dall'I / O dei file, meno sicurezza, ecc.).

Qual è il metodo migliore? Quali sono i problemi e le cose buone di ciascuno di questi approcci?


2
Credo che dovresti specificare se stai usando una sola macchina o se l'applicazione è distribuita, poiché influenzerà pesantemente le risposte.
Arseni Mourzenko,

1
@haylem questo è il posto più adatto per porre questa domanda, non è una domanda di programmazione, è un problema concettuale di programmazione,
user1179459

3
Questa è davvero una domanda scadente perché "il migliore" dipende dalla tua specifica circostanza. Il "migliore" per Facebook non è probabilmente lo stesso "migliore" per la tua home page personale.
GrandmasterB,

1
@GrandmasterB So che è per questo che ho chiesto chiaramente "Quali sono i problemi e le cose buone di ciascuno di questi approcci?" per scoprire qual è il migliore per me.
user1179459,

Risposte:


6

La cosa migliore è archiviare su Memcached poiché possiamo facilmente risolvere gli altri problemi (dimensione della cache, sicurezza, ecc.)

facebook è il primo consumatore di memcached. Si prega di leggere se interessati: http://www.facebook.com/note.php?note_id=39391378919

Come risolvere gli altri problemi?


4

Per la stragrande maggioranza delle applicazioni quotidiane, tenere sessioni in database va bene. Il volume e il livello di concorrenza che un server sql può gestire sarà più che sufficiente. La chiave è mantenere ogni voce di piccole dimensioni ed eliminare le righe non necessarie con regolarità. E una corretta indicizzazione, ovviamente.

Il file system: non ho mai visto la necessità di farlo. Preferisco la semplicità di gestione delle righe nelle tabelle piuttosto che migliaia di piccoli file. Inoltre, non è possibile eseguire query tra i file se si desidera approfondire le statistiche della sessione.

Tieni presente, con PHP, è facile sostituire i gestori di sessione. Quindi puoi iniziare con un formato di archiviazione e migrare a un altro senza troppi problemi.


4

Che dire dell'utilizzo del motore di archiviazione MEMORY in MySQL?

Non è veloce come Memcache ma ha il vantaggio di poter usare il semplice SQL e puoi anche usare il normale motore di archiviazione quando non sarà necessario e passare a MEMORY quando il numero di utenti / richieste aumenta.

Lo sto usando per archiviare grandi quantità di dati statistici in un'app Web che cambia frequentemente, quindi non viene utilizzato per gestire le sessioni, ma penso che dovrebbe essere adatto a questo scopo.


3

Questo post sul blog mostra i risultati di un confronto delle prestazioni di diversi motori di archiviazione delle sessioni con Magento e sembrano aver concluso che fino a circa 75 utenti simultanei non c'è davvero una differenza di prestazioni tra di loro.

Penso che a questi livelli (avevano circa 5 transazioni al secondo, che sarebbero circa 430k hit in un periodo di 12 ore) il sovraccarico in tutto il resto domina i numeri delle prestazioni che vedi dal momento che file / DB / Memcache / Redis gestiranno tutti felicemente il traffico senza sudare se usato correttamente.

Ciò lascia altri fattori come la scalabilità, l'affidabilità e la sicurezza.

Innanzitutto vorrei dire che tutto ciò che compromette l'archiviazione dei file probabilmente comprometterà qualsiasi altra cosa poiché un utente malintenzionato può quindi semplicemente modificare il codice dell'applicazione o almeno scoprire chiavi e protocolli / credenziali di accesso all'archiviazione anche se hanno sola lettura accesso. L'archiviazione dei file funzionerà bene per un sito a basso volume, è facile da configurare ed è facile ragionare. Per quanto tu dica di aver colpito il disco, una lettura del DB colpirà anche il disco e se il DB può memorizzarlo nella cache, probabilmente anche il tuo sistema operativo avrà memorizzato nella cache il file di sessione. Inoltre, viene letto un solo file e il tuo file system è brillante nel raggiungerlo se ne conosci già il nome. Se stai usando PHP, sai quanti file legge il sistema deve fare solo per servire la tua applicazione? Il rovescio della medaglia è che puoi '

Memcache è relativamente veloce e se stai considerando le soluzioni di classe Memcache in modo più ampio (Redis, ecc.) Ce ne sono alcune che promettono persino persistenza con letture in memoria per la velocità in modo da ottenere il massimo da entrambi i mondi. Sono anche relativamente semplici da ragionare e la natura del valore-chiave delle sessioni è esattamente ciò per cui sono state progettate. Sai quanto dovresti mettere in una sessione per riempire uno di questi? Ad ogni modo, tutte le opzioni ti costringeranno a scendere a compromessi se raggiungi la loro capacità. I dischi si riempiono di file (il numero e il fattore dimensioni qui), gli archivi di cache si riempiono di capacità e i database hanno un numero limitato di righe e gli stessi limiti di capacità del disco dell'approccio dei file. Inoltre, questi sistemi sono distribuiti solo se li esegui in modo distribuito. La maggior parte funziona perfettamente con una configurazione a server singolo. Se li distribuisci, probabilmente hai già distribuito server Web / server database ecc., Quindi i tuoi problemi di sistema distribuito non appariranno sicuramente dalla tua scelta di archiviazione della sessione. Tuttavia, quando si desidera 10 volte il traffico / capacità ecc., Arrivarci è molto più naturale con questo che con lo schema di archiviazione dei file. Alcuni archivi chiave / valore ti permetteranno anche di condurre analisi semplici dei dati della sessione in modo relativamente semplice, ma la maggior parte non ti porterà da nessuna parte vicino a ciò che SQL può fare.

Non sono sicuro del motivo per cui proponi che il database sia più affidabile rispetto alle altre opzioni, ma ottengo il fascino del database poiché la tua applicazione PHP probabilmente ne fa già uso. Ciò significa che non aggiungi un'altra dipendenza server e probabilmente puoi riutilizzare la stessa connessione che usi per recuperare i dati della sessione per ottenere i dati dell'utente, quindi non devi stabilirne uno per i dati, uno per Memcache, ecc. Se indicizzi il tabella bene, funzionerà anche abbastanza velocemente e fornirà una semantica piuttosto semplice che hai già familiarità con la raccolta di vecchie sessioni o anche con l'analisi dei dati di sessione (non sono sicuro del motivo per cui vorresti farlo e se non lo sei, probabilmente non lo fa non importa così tanto). Il ridimensionamento su enormi scale non è così banale come con qualcosa come Redis,

Penso che questa scelta non sia così importante all'inizio. Ogni approccio ha sfide, vantaggi e cose a cui devi pensare. In generale, probabilmente puoi cavartela semplicemente usando le impostazioni predefinite di PHP / qualunque framework tu usi o anche solo la cosa più semplice con cui andare avanti. Se la scelta risulterà negativa in seguito, la tua analisi delle prestazioni ti dirà e sarai armato dei dati necessari per fare le scelte appropriate data la natura specifica del traffico che ricevi. All'inizio, tutto ciò che puoi ragionevolmente avere è una speculazione generale.


0

Dipende dai tuoi bisogni.

Ci sono alcune differenze tra i file e l'archiviazione del database. Vedere questa domanda .

Tuttavia, puoi fare ciò che è stato fatto in Rails 3 per impostazione predefinita e utilizzare solo cookie crittografati per la tua sessione. Quindi crittografate tutti i valori in un modo che solo voi potete decifrare in seguito (ad esempio chiavi private / pubbliche) e lasciate che il client faccia lo stato per voi.

Da un lato ti limita a 4Kb, che di solito è abbastanza (dal momento che di solito vuoi archiviare ID, non interi oggetti), ma il vantaggio davvero piacevole che ottieni è che non devi preoccuparti della pulizia della sessione. Lo lasci al cliente, dove dovrebbe essere.


2
A meno che tu non abbia separato le tue risorse statiche per essere al di fuori del tuo percorso cookie, i cookie sono un'imposta fissa che devi pagare su ogni richiesta.
Joeri Sebrechts,

jQuery e Bootstrap sono combinati intorno a 150kb, e questo è senza altre librerie. Il cookie massimo è di 4kb e di solito inferiore a 1Kb. A meno che il PO non stia chiedendo circostanze estreme - chi se ne frega di quel tipo di tassazione?
Yam Marcovic,

@YamMarcovic ci sono alcuni problemi 1) Anche i cookie stanno andando al server (gli utenti di solito hanno un download più veloce quindi caricano) 2) di solito le pagine hanno centinaia di richieste di file statici (immagini, js, css) in modo da poter arrivare a 100kb per ogni richiesta salendo
Miro Svrtan,

@MiroSvrtan Se stai inviando i tuoi utenti a inviare centinaia di richieste per pagina (dove è mai successo?), L'ottimizzazione non è chiaramente un problema per te.
Yam Marcovic,

Avevo un cliente il cui sito stava facendo ~ 170 richieste HTTP per caricare la prima pagina prima di consultarmi per le ottimizzazioni della velocità, quindi succede, fidati di me. A proposito, le chiavi private / pubbliche sono un concetto della crittografia asimmetrica, che generalmente non verrebbe applicato in questo scenario in cui equivale a una cifra simmetrica, solo più complessa da implementare. Inoltre, la maggior parte delle implementazioni di archiviazione delle sessioni si basano su alcuni cookie gestiti dal client, quindi il vantaggio descritto nell'ultimo paragrafo della risposta si applica a tutti.
jeteon,

0

Per la mia situazione particolare, posso dirti che le sessioni in un database sono la causa numero uno dei nostri blocchi del server con un buon margine. la nostra tabella delle sessioni viene corrotta abbastanza frequentemente che abbiamo deciso di troncarla preventivamente.

memcache sembra attraente, ma abbiamo troppi processi che eliminano l'intera memcache, quindi le sessioni utente verrebbero interrotte troppo frequentemente. e le sessioni più vecchie sarebbero state cancellate quando la memoria si fosse riempita ... quindi non più accessi permanenti.

Proveremo presto le sessioni basate su file predefinite.

Se sei preoccupato per la sicurezza dei dati della sessione, non dovresti metterli nella sessione - e non fidarti della sessione - convalidare l'utente su ogni richiesta.


0

Puoi provare a salvare la sessione su Redis . Redis è veloce come Memcached ma ha anche diverse opzioni di persistenza dei dati. Inoltre, sono supportati vari client PHP.

Inoltre, puoi provare servizi di terze parti come Memcached Cloud con funzionalità di replica e motore di archiviazione integrate

Informativa, sono Co-Founder e CTO di Garantia Data.


2
Grazie per la divulgazione! Assicurati di partecipare a questo sito oltre ai post in cui puoi menzionare i tuoi prodotti, vogliamo che tu come persona contribuisca, non la tua azienda.
Martijn Pieters,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.