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

9

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

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

  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, credo che sia lenta dal momento in cui legge e scrive da file I / O, meno sicurezza, ecc.)

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

    
posta user1179459 05.11.2012 - 06:27
fonte

7 risposte

5

Il meglio è archiviare su Memcached in quanto possiamo facilmente risolvere gli altri problemi (dimensione della cache, sicurezza, ecc.)

facebook is the #1 consumer of memcached. Please read if interested: http://www.facebook.com/note.php?note_id=39391378919

Come risolvere gli altri problemi?

risposta data 05.11.2012 - 09:51
fonte
3

Per la maggior parte delle applicazioni quotidiane, mantenere le sessioni nei database va bene. Il volume e amp; il livello di concorrenza che un server SQL può gestire sarà più che sufficiente. La chiave è di mantenere ogni voce di dimensioni ridotte ed eliminare le righe non necessarie con regolarità. E indicizzazione corretta, ovviamente.

Il file system: non ho mai visto la necessità di farlo. Preferisco la semplicità di gestire le righe nelle tabelle piuttosto che migliaia di piccoli file. Inoltre, non puoi eseguire query su tutti i file se desideri analizzare le statistiche di sessione.

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

    
risposta data 14.11.2012 - 05:40
fonte
3

Che ne pensi di utilizzare il motore di memorizzazione MEMORY in MySQL?

Non è veloce come Memcache ma ha il vantaggio di poter usare SQL semplice, 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 utilizzando per archiviare grandi quantità di dati statistici in un'applicazione web che cambia frequentemente, quindi non è usata per la gestione delle sessioni, ma penso che dovrebbe essere adatta a questo scopo.

    
risposta data 14.11.2012 - 01:02
fonte
2

Questo post sul blog mostra i risultati di un confronto delle prestazioni di diversi motori di storage di sessione 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 (avessero circa 5 transazioni al secondo, che sarebbero circa 430.000 accessi in un periodo di 12 ore) il sovraccarico in tutto il resto domina i numeri delle prestazioni che si vedono dal momento che file / DB / Memcache / Redis saranno tutti gestiscono felicemente il traffico senza sudare se usati correttamente.

Questo lascia altri fattori come scalabilità, affidabilità e sicurezza.

In primo luogo vorrei dire che tutto ciò che compromette lo spazio di archiviazione del tuo file probabilmente comprometterà qualsiasi altra cosa poiché un utente malintenzionato può semplicemente modificare il codice dell'applicazione o per lo meno scoprire chiavi e protocolli / credenziali di accesso allo storage anche se hanno accesso di sola lettura. Lo storage di file funziona bene per un sito a basso volume, è facile da configurare ed è facile da ragionare. Per quanto tu dica di aver colpito il disco, una lettura di DB colpirà anche il disco e se il DB può memorizzarlo nella cache, anche il tuo sistema operativo avrà memorizzato nella cache il file di sessione. Inoltre, il suo unico file è stato letto e il tuo file system è brillante nel raggiungerlo se già conosci il suo nome. Se stai usando PHP, sai quanti file legge che il sistema deve fare solo per servire la tua applicazione? Il rovescio della medaglia è che non si può andare troppo lontano perché si raggiungerà rapidamente il limite del numero di file che è possibile conservare su un singolo disco.

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ò che questi sono stati progettati per fare. Sai quanto dovresti mettere in una sessione per riempire uno di questi? In entrambi i casi, tutte le opzioni ti costringono a scendere a compromessi se raggiungi la loro capacità. I dischi si riempiono di file (il numero e il fattore di dimensione qui), i depositi di cache si riempiono di capacità ei database hanno un numero limitato di righe e gli stessi limiti di capacità del disco dell'approccio dei file. Inoltre, questi sistemi vengono distribuiti solo se li si esegue in modo distribuito. La maggior parte funziona bene con una singola configurazione del server. Se li distribuisci, probabilmente hai già distribuito server web / server di database, ecc. Quindi i tuoi problemi di sistema distribuiti non appariranno certamente dalla tua scelta di archiviazione di sessione. Tuttavia, quando si desidera 10 volte il traffico / la capacità ecc., Arrivarci è molto più naturale di quanto non lo sia con lo schema di archiviazione dei file. Alcuni archivi chiave / valore ti permetteranno anche di condurre semplici analisi dei dati della sessione in modo relativamente semplice, ma la maggior parte non ti porterà vicino a ciò che SQL può fare.

Non sono sicuro del motivo per cui proponi che il database possa essere più affidabile delle altre opzioni, ma ottengo il fascino del database dal momento che probabilmente la tua applicazione PHP lo usa già. Ciò significa che non si aggiunge un'altra dipendenza del server e si può probabilmente riutilizzare la stessa connessione che si usa per recuperare i dati della sessione per ottenere i dati dell'utente in modo da non doverne stabilire uno per i dati, uno per Memcache, ecc. tavolo bene, si esibirà anche abbastanza velocemente e fornisce semantica abbastanza semplice con cui hai già familiarità con il recupero di vecchie sessioni o anche l'analisi dei dati di sessione (non sono sicuro del motivo per cui vorrai e, se non lo sei, probabilmente non lo fa t importa così tanto). Scalare a massicce scale non è così banale come con qualcosa come Redis, ma passare da un server PHP a due sia l'accesso allo stesso DB è piuttosto semplice.

Penso che questa scelta non sia così importante all'inizio. Ogni approccio ha sfide, vantaggi e cose a cui devi pensare. Parlando in generale, è probabile che si possa farla franca solo usando le impostazioni predefinite di PHP / qualunque sia la struttura che si utilizza o anche solo la cosa più semplice da seguire. Se in seguito la scelta si rivelerà errata, l'analisi delle prestazioni ti comunicherà e sarai armato con i dati necessari per effettuare le scelte appropriate in base alla natura specifica del traffico. Di fronte, tutto ciò che si può ragionevolmente fare è una speculazione generale.

    
risposta data 01.09.2015 - 10:12
fonte
0

Dipende dalle tue esigenze.

Ci sono alcune differenze tra i file e la memoria del database. Vedi questa domanda .

Tuttavia, puoi fare ciò che viene fatto in Rails 3 per impostazione predefinita e utilizzare solo cookie crittografati per la tua sessione. Pertanto, crittografa tutti i valori in un modo che solo tu puoi decrittografare in un secondo momento (ad esempio, chiavi private / pubbliche) e lasciare che sia il client a tenere lo stato per te.

Da un lato ti limita a 4Kb, che in realtà è in genere sufficiente (dato che di solito vuoi archiviare gli ID, non interi oggetti), ma il vantaggio davvero notevole che ottieni è che non devi preoccuparti della sessione pulire. Lo lasci al cliente, dove effettivamente dovrebbe essere.

    
risposta data 05.11.2012 - 06:43
fonte
0

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

memcache sembra interessante, ma abbiamo troppi processi che cancellano l'intero memcache, quindi le sessioni utente verrebbero tagliate troppo frequentemente. e le sessioni precedenti verrebbero cancellate man mano che la memoria si riempiva ... quindi non ci sono più accessi permanenti.

Proveremo presto le sessioni basate su file predefinite.

Se sei preoccupato per la sicurezza dei tuoi dati di sessione, non dovresti mettere quei dati nella sessione - e non fidarti della sessione - convalidare l'utente ad ogni richiesta.

    
risposta data 13.11.2012 - 22:37
fonte
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 i servizi di terze parti come Memcached Cloud con funzionalità di replica e di memorizzazione incorporate

Divulgazione, sono co-fondatore e CTO di Garantia Data.

    
risposta data 18.11.2012 - 13:52
fonte

Leggi altre domande sui tag