2011-07-01 18 views
7

Tengo un servicio web php que se puede llamar (desde teléfonos móviles) para realizar ciertas tareas. Para que estas tareas se realicen, el que llama debe estar "conectado". ¿Cuál es la mejor manera de manejar la autenticación?¿Cuál es la mejor manera de implementar inicio de sesión para un servicio web?

Actualmente, solo estoy usando SESSIONS. El cliente llama a una API de inicio de sesión y a cualquier otra API necesaria. Pero me preocupa el impacto de tener 200,000 personas que llaman a este servicio y tienen todas esas sesiones. No estoy seguro de cómo responderá el servidor. ¿Algun consejo? ¿Cómo se maneja esto típicamente? Como facebook, flickr, etc ....

+0

PHP y sus sesiones son mucho más poderosas de lo que piensas. Si aún hay demasiada carga en su servidor (optimícela más tarde, ¡no prematuramente!), Considere cambiar la directiva 'session.save_handler' en PHP para usar una base de datos para almacenar las sesiones (en lugar del sistema de archivos). Aparte de eso, siempre use una biblioteca de autenticación segura en lugar de desplegar la suya propia. Ejemplo: https: // github.com/delight-im/PHP-Auth, que es tanto agnóstico como de base de datos y agnóstico de la base de datos. – caw

Respuesta

3

Si esto es invocado por un programa cliente personalizado (es decir, sus teléfonos móviles), y no por el navegador, ¿por qué "iniciar sesión" en absoluto? En su lugar, simplemente use HTTP Authentication (ya sea DIGEST o BASIC si va a SSL, o su propio esquema) y "log in" cada vez.

Entonces no tiene que preocuparse por las sesiones, sobre el equilibrio de carga, y la conmutación por error, etc. Manténgalo sin estado.

Adenda:

Ciertamente, un menor número de accesos a la base de datos son mejores, eso es sólo una regla general. Pero al mismo tiempo, muchas visitas al DB se manejan mediante páginas almacenadas en caché en el servidor de bases de datos, o posiblemente en cachés de aplicaciones para que nunca lleguen al servidor de bases de datos. Por lo tanto, en algunos casos, particularmente las consultas de fila única en una columna indexada, los hits de DB pueden ser muy baratos.

Ahora, uno podría considerar si ambos son almacenados y de fácil acceso, lo que realmente es la diferencia entre un bit de caché de la base de datos y una sesión de usuario única.

Bueno, principalmente, la diferencia está en el contrato con los datos. Un elemento almacenado en caché tiene una vida útil directamente proporcional a la cantidad de memoria que tiene y la cantidad de actividad sin almacenar en caché. Déle una pequeña cantidad de memoria, y el elemento en caché probablemente tenga una vida útil muy corta. Dale mucha memoria y el objeto en caché tiene muchas más posibilidades de pasar el rato. Si la cantidad de memoria para los datos almacenados en caché es lo suficientemente grande como para que la actividad repetida de esos datos continúe usando el caché, el caché sea una gran ganancia. Si su caché se recicla tan rápido que nada está "en" la memoria caché, su caché casi no tiene valor. Pero el punto es que el sistema funcionará con o sin el caché, el caché es simplemente una mejora del rendimiento.

Una sesión, sin embargo, tiene un contrato diferente. Muchas sesiones tienen una vida útil específica y mínima, generalmente medida en minutos: 10, 20, incluso 30 minutos.

Eso significa que si un usuario accede a su sitio solo una vez, debe dedicar recursos a ese usuario, incluso si nunca vuelve. Tienes que hacerlo, de lo contrario la sesión no ofrece ningún valor.

Si recibe mucho tráfico, obtiene muchas sesiones nuevas para administrar. En teoría, bajo malas circunstancias, las sesiones pueden aumentar sin límites. Si de repente obtienes 10.000 visitas en tu sitio, puedes administrar los restos de esos hits durante la vida mínima de tu sesión. Tienes que dedicarles recursos (memoria o disco), tienes que hacer un seguimiento de ellos, y luego, inevitablemente, debes limpiarlos.

Un caché es un recurso fijo. Solo crece según el tamaño que configures. No tiene obligación de guardar nada en el caché, y como se discutió anteriormente, el sistema funcionará con o sin el caché. Los caches naturalmente reciclan. Si obtienes ese aumento de 10.000 visitas, posiblemente rodarán tu caché, pero después de eso no dejan ninguna marca en tu sistema. Pueden golpear y desaparecer en 1 o 2 minutos, nunca más volver a verse.

Finalmente, con las sesiones, debe compartirlas entre su infraestructura para que viajen con el usuario si saltan de máquina a máquina (por el motivo que sea). Los caches no. Idealmente, debe mantener a un usuario local en un conjunto de recursos para que las memorias caché puedan hacer su trabajo, pero el sistema funciona tanto si se muda como si se queda (simplemente funciona mejor si se queda, debido a la reutilización de la memoria caché). Si no replicas tus sesiones, no funcionan en absoluto.

Los accesos a DB se suman, pueden ser baratos, pero nunca son gratuitos. Pero una sesión tiene sus propios costos también, por lo que es importante considerarlos a ambos y cómo se aplican dentro de su arquitectura.

+0

Históricamente no soy un programador de backend, así que calculé la velocidad de la consulta. Iniciar sesión una vez es 1 consulta vs inicio de sesión cada vez. Tal vez es neglectible? – user123321

+0

muy buena explicación de seguimiento! Gracias. – user123321

3

Actualmente, solo estoy usando SESSIONS. El cliente llama a una API de inicio de sesión y necesita cualquier otra API . Pero me preocupa sobre el impacto de tener 200,000 personas llamando a este servicio y tienen todas esas sesiones.

Estándar esas sesiones tocan el disco porque el valor predeterminado session_save_handler está establecido en file. Es mejor que su sistema no toque el disco (la memoria es mucho más rápida). Puede intentar anular session_set_save_handler para usar algo diferente de file. Por ejemplo, podría tener las sesiones almacenadas en:

  • redis (me gusta el cliente predis). Incluso más rápido sería install C extension, pero probablemente necesite acceso de root para recompilar PHP. Si tiene tantos usuarios, probablemente debería poseer/alquilar VPS. La buena gente al http://redistogo.com le proporciona planes gratis (5 MB) si no puede instalar nada en la computadora. Mencioné anteriormente que debería tener la capacidad de instalar cosas si realmente quiere tener rendimiento.
  • memcached

estos datos en memoria también apoyar mejor a escala. También debería utilizar estas bases de datos para almacenar en caché el resto de sus consultas de base de datos (¿MySQL?). Debe recordar que tocar el disco es muy lento en comparación con solo usar la memoria.

También debe instalar APC para obtener el mejor rendimiento.

¿Cómo se maneja esto normalmente? Al igual que facebook, flickr, etc ....

Hoy en día no se puede utilizar cualquier API sin utilizar OAuth (aunque creo que la autenticación a través de las sesiones son más fáciles de implementar). Es el nuevo estándar de facto para realizar la autenticación sin tener que compartir contraseñas. El creador de PHP (Rasmus) ha hecho un tutorial que explica cómo Writing an OAuth Provider Service. Buscando oauth php en google usted debe obtener información más que suficiente.

También en la actualidad, la mayor parte del sitio de Facebook está usando HipHop en lugar del simple viejo PHP para acelerar su sitio web. PHP tiene open-sourced muchos de los trabajos que debería/debería usar:

+0

wow. Que linda explicación. Leeré todo lo que pueda. Desafortunadamente, no estoy lo suficientemente informado como para hacer preguntas de seguimiento en este momento. ¡Gracias! – user123321

+0

No hay problema para preguntar;). Espero poder ayudar ... – Alfred

Cuestiones relacionadas