¿Cuál es el almacenamiento de sesión más confiable en PHP: Memcache, base de datos o archivos? [cerrado]


10

¿Cuál es la mejor y más segura forma de manejar sesiones PHP? Es la mejor forma de almacenar sesiones en:

  1. Base de datos (más confiable, pero con un alto cuello de botella, baja velocidad, no es bueno para sitios web de alto uso de la base de datos).

  2. ¿Memcache (superrápido, pero distribuyó más problemas de seguridad, posibilidades de perder datos cuando el servidor se reinició y posibilidades de perder datos cuando el caché está lleno)?

  3. Archivos (opción predeterminada, supongo que es lenta ya que lee y escribe desde archivos de E / S, menos seguridad, etc.).

¿Qué método es el mejor? ¿Cuáles son los problemas y las cosas buenas de cada uno de esos enfoques?


2
Creo que debe especificar si está utilizando una sola máquina o si la aplicación está distribuida, ya que influirá mucho en las respuestas.
Arseni Mourzenko

1
@haylem este es el lugar más adecuado para hacer esta pregunta, la pregunta no la programación de su programación problema conceptual,
user1179459

3
Esta es realmente una pregunta pobre porque 'mejor' depende de su circunstancia específica. El "mejor" para Facebook probablemente no sea el mismo "mejor" para su página de inicio personal.
GrandmasterB

1
@GrandmasterB Sé que por eso pregunté claramente "¿Cuáles son los problemas y las cosas buenas de cada uno de esos enfoques?" para averiguar cuál es el mejor para mí.
user1179459

Respuestas:


6

Lo mejor es almacenar en Memcached, ya que podemos resolver fácilmente los otros problemas (tamaño de caché, seguridad, etc.)

facebook es el consumidor número 1 de memcached. Lea si está interesado: http://www.facebook.com/note.php?note_id=39391378919

¿Cómo resolver los otros problemas?


4

Para la gran mayoría de las aplicaciones del día a día, mantener sesiones en bases de datos está bien. El volumen y el nivel de concurrencia que puede manejar un servidor SQL será más que suficiente. La clave es mantener cada entrada de tamaño pequeño y purgar las filas innecesarias con regularidad. Y una indexación adecuada, por supuesto.

El sistema de archivos: nunca he visto la necesidad de hacer eso. Prefiero la simplicidad de administrar filas en tablas en lugar de miles de pequeños archivos. Además, no puede consultar entre archivos si desea profundizar en las estadísticas de la sesión.

Tenga en cuenta que con PHP es fácil intercambiar manejadores de sesión. Por lo tanto, puede comenzar con un formato de almacenamiento y migrar a otro sin demasiados problemas.


4

¿Qué pasa con el uso del motor de almacenamiento MEMORY en MySQL?

No es tan rápido como Memcache, pero tiene la ventaja de que puede usar SQL simple, y también puede usar el motor de almacenamiento normal cuando no sea necesario y cambiar a MEMORY cuando aumente el número de usuarios / solicitudes.

Lo estoy usando para almacenar grandes cantidades de datos estadísticos en una aplicación web que cambia con frecuencia, por lo que no se usa para manejar sesiones, pero creo que debería ser adecuada para este propósito.


3

Esta publicación de blog muestra los resultados de una comparación de rendimiento de diferentes motores de almacenamiento de sesiones con Magento y parecen haber concluido que hasta unos 75 usuarios concurrentes no hay realmente una diferencia de rendimiento entre ellos.

Creo que en estos niveles (tenían aproximadamente 5 transacciones por segundo, que serían aproximadamente 430k visitas durante un período de 12 horas), la sobrecarga en todo lo demás domina los números de rendimiento que ves, ya que el archivo / DB / Memcache / Redis manejará felizmente el tráfico sin sudar si se usa correctamente.

Eso deja otros factores como la escalabilidad, la confiabilidad y la seguridad.

Primero me gustaría decir que cualquier cosa que comprometa su almacenamiento de archivos probablemente también comprometerá cualquier otra cosa, ya que un atacante puede modificar el código de su aplicación o al menos descubrir claves y protocolos / credenciales de acceso al almacenamiento, incluso si tienen solo lectura acceso. El almacenamiento de archivos funcionará bien para un sitio de bajo volumen, es fácil de configurar y es fácil razonar. Por mucho que diga que golpeó el disco, una lectura de base de datos también afectará al disco y si la base de datos puede almacenarlo en caché, es probable que su sistema operativo también haya almacenado en caché el archivo de sesión. Además, solo se lee un archivo, y su sistema de archivos es brillante para obtenerlo si ya conoce su nombre. Si está utilizando PHP, ¿sabe cuántas lecturas de archivos tiene que hacer el sistema solo para servir su aplicación? La desventaja es que puedes '

Memcache es relativamente rápido y si está considerando las soluciones de clase Memcache de manera más amplia (Redis, etc.), hay algunas que incluso prometen persistencia con lecturas de memoria para mayor velocidad para que pueda aprovechar al máximo ambos mundos. También son relativamente fáciles de razonar y la naturaleza de valor clave de las sesiones es exactamente para lo que han sido diseñadas. ¿Sabes cuánto tendrías que poner en una sesión para completar uno de estos? De cualquier manera, todas sus opciones lo obligarán a comprometerse si alcanza su capacidad. Los discos se llenan con archivos (factor de número y tamaño aquí), los almacenes de caché se llenan en capacidad y las bases de datos tienen un número limitado de filas y los mismos límites de capacidad de disco que el enfoque de archivo. Además, estos sistemas solo se distribuyen si los ejecuta de manera distribuida. La mayoría funciona bien con una única configuración de servidor. Si los distribuye, entonces probablemente ya haya distribuido servidores web / servidores de bases de datos, etc., por lo que los problemas de su sistema distribuido ciertamente no aparecerán en su elección de almacenamiento de sesión. Sin embargo, cuando desea 10 veces el tráfico / capacidad, etc., llegar allí es mucho más natural con esto que con el esquema de almacenamiento de archivos. Algunos almacenes de clave / valor también le permitirán realizar análisis simples de los datos de la sesión con relativa facilidad, pero la mayoría no lo acercará a lo que SQL puede hacer.

No estoy seguro de por qué propone que la base de datos puede ser más confiable que las otras opciones, pero entiendo el atractivo de la base de datos, ya que su aplicación PHP probablemente ya la utiliza. Esto significa que no agrega otra dependencia del servidor y probablemente pueda reutilizar la misma conexión que usa para obtener datos de sesión para obtener datos de usuario, de modo que no tenga que establecer uno para datos, uno para Memcache, etc. Si indexa el bien, también funcionará razonablemente rápido y proporciona una semántica bastante simple con la que ya está familiarizado para cosechar sesiones antiguas o incluso analizar datos de la sesión (no estoy seguro de por qué querría hacerlo y si no lo hace, probablemente esto no No importa mucho). Escalar a escalas masivas no es tan trivial como con algo como Redis,

Creo que esta elección no es tan importante al principio. Cada enfoque tiene desafíos, ventajas y cosas en las que debe pensar. En términos generales, probablemente pueda salirse con la suya simplemente usando los valores predeterminados de PHP / cualquier marco que use o incluso lo más fácil para comenzar. Si la elección resulta ser mala más adelante, sus análisis de rendimiento le informarán y usted contará con los datos que necesita para tomar las decisiones apropiadas dada la naturaleza específica del tráfico que obtiene. Por adelantado, todo lo que razonablemente puede tener es especulación general.


0

Depende de tus necesidades.

Existen algunas diferencias entre los archivos y el almacenamiento de la base de datos. Ver esta pregunta .

Sin embargo, puede hacer lo que se hace en Rails 3 de manera predeterminada y usar solo cookies cifradas para su sesión. Entonces, encripta todos los valores de una manera que solo usted puede desencriptarlos más tarde (por ejemplo, claves privadas / públicas), y deja que el cliente se encargue del estado por usted.

Por un lado, lo limita a 4Kb, que generalmente es suficiente (ya que generalmente desea almacenar ID, no objetos completos), pero el beneficio realmente bueno que obtiene es que no necesita preocuparse por la limpieza de la sesión. Dejas eso en manos del cliente, donde debería estar.


2
A menos que haya separado sus recursos estáticos para estar fuera de su ruta de cookies, las cookies son un impuesto fijo que debe pagar en cada solicitud.
Joeri Sebrechts

jQuery y Bootstrap combinan alrededor de 150 kb, y eso sin otras bibliotecas. Cookie max es de 4kb, y generalmente por debajo de 1Kb. A menos que el OP pregunte sobre circunstancias extremas, ¿a quién le importa ese tipo de impuestos?
Yam Marcovic

@YamMarcovic hay algunos problemas 1) las cookies también van al servidor (los usuarios suelen descargar y cargar más rápido) 2) generalmente las páginas tienen cientos de solicitudes de archivos estáticos (imágenes, js, css) para que pueda llegar a 100kb en cada solicitud subiendo
Miro Svrtan

@MiroSvrtan Si está haciendo que sus usuarios envíen cientos de solicitudes por página (¿dónde sucedió eso?), La optimización claramente no es un problema para usted.
Yam Marcovic

Tenía un cliente cuyo sitio estaba haciendo ~ 170 solicitudes HTTP para cargar la página principal antes de consultarme para optimizaciones de velocidad, por lo que sucede, confía en mí. Por cierto, las claves privadas / públicas son un concepto de la criptografía asimétrica, que generalmente no se aplicaría en este escenario donde es equivalente a un cifrado simétrico, solo que es más complejo de implementar. Además, la mayoría de las implementaciones de almacenamiento de sesión dependen de algunas cookies administradas por el cliente, por lo que el beneficio descrito en el último párrafo de la respuesta se aplica a todas ellas.
jeteon

0

Para mi situación particular, puedo decirle que las sesiones en una base de datos son la causa número uno de nuestros problemas de servidor por un buen margen. nuestra tabla de sesiones se corrompe con la frecuencia suficiente que hemos tomado para truncarla de manera preventiva.

memcache suena atractivo, pero tenemos demasiados procesos que borran todo el memcache, por lo que las sesiones de los usuarios se cortan con demasiada frecuencia. y las sesiones más antiguas se borrarían a medida que la memoria se llenara ... así que no más inicios de sesión permanentes.

Intentaremos las sesiones predeterminadas basadas en archivos pronto.

Si le preocupa la seguridad de los datos de su sesión, entonces no debe poner esos datos en la sesión, y no confíe en la sesión, valide al usuario en cada solicitud.


0

Puede intentar guardar su sesión en Redis . Redis es rápido como Memcached pero también tiene varias opciones de persistencia de datos. Además, se admiten varios clientes PHP.

Además, puede probar servicios de terceros como Memcached Cloud que tiene capacidades de motor de almacenamiento y replicación incorporadas

Divulgación, soy cofundador y director de tecnología de Garantia Data.


2
Gracias por la divulgación! Sin embargo, asegúrese de participar en este sitio más allá de las publicaciones donde puede mencionar sus propios productos, queremos que usted, como persona, contribuya, no su empresa.
Martijn Pieters
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.