Perfeccionando script PHP, mejor rendimiento y seguridad

[ernewston]

Buenas,
Estoy desarrollando un sistema bastante grande con usuarios, transacciones, admins, etc... con una base de datos mysql y php.

En el camino me he topado con muchas dudas, lo cual google me ha ayudado bastante, pero en otros no.

Una de las duda es la siguiente: Tengo por ejemplo un usuario logueado en su cuenta y guardo todos sus datos extraidos de la base de datos en una variable $_SESSION['usuario'] (id, nombre, apellido, tel, etc...), y cada 2 minutos vuelvo a extraer los datos de la bd para acutalizar el session (por si le han cambiado algo). Con los mensajes del usuario lo mismo: $_SESSION['usuario']['mensaje1,2,....,N']['texto, asunto, fecha....']... Esto es tan solo un ejemplo.

Esta forma la de sacado de otro programador que lo hace para proteger la base de datos, porque me dijo que si se hacen muchas consultas la bd puede caer o sobrecargar al servidor. Eso es verdad? Utilizando sessions en vez de hacer cada vez una consulta al bd rinde mas? Hay que proteger la bd de que se le hagan muchas consultas?

La otra duda es algo parecido pero sobre las session. Si definimos muchas variables en la session, baja mucho el rendimiento del script? Seria mejor consultar nuevamente a la base de datos antes de guardarlo en la session?

Tengo que aclarar que la página debe ser lo más seguro posible, pero también debe tener un buen rendimiento, tiene que poder soportar a miles de usuarios.

Mi última duda: Sería mejor hacer una clase 'usuario' o 'mensaje' y pasarla por session en vez de un array ['usuario']? De que tanto me sirve tener una clase usuario o mensaje si igual casi nunca voy a trabajar sobre las varibales de la clase sino que sobre la base de datos?(tengo clases definidas pero solo uso métodos, ya que cambios solo lo hago directamente sobre la bd).

Espero que me puedan ayudar/aconsejar.
Desde ya muchas gracias.

[maycolalvarez]

1- los datos de la sesión (modulo session PHP) se almacenan en archivos locales de tu server, así que a cada petición, leerá el archivo, da lo mismo si solo tienes el ID del usuario en sesión y consultes a la DB, además: puedes establecer que los datos de session se almacenen directamente en una table de la DB

2- el servidor de DB funciona mejor si las consultas SQL están optimizadas y en general es el último en caerse, porque el servidor web tiene que procesar mas cosas, incluyendo PHP, el servidor de DB solo leerá/actualizará registros, es casi todo lo que hace, a menos que las consultas sean complejas

3- sí, los datos de session se almacenan en archivos, cierto, pero si son muchos en cada petición vuelven a cargarse y saturar la RAM del servidor, es por ello que en session deben de tenerse sólo los datos necesarios, un servidor rinde más con más memoria disponible para leer y escribir en disco que si tuviese la RAM saturada de datos, que a final solo existirán mientras PHP procese, ya que estos serán liberados a la respuesta.

4- hay muchos optimizadores para PHP: zend optimizer, ioncube, xcache, phpacelerator, hiphop for php, debido a que php es interpretado su rendimiento decae según incremente exponencialmente el numero de usuarios.

[Logotytype]

Mi opinion es que trates de equilibrar el uso de las 3 cosas, servidor web, php y msql, trata de tenerlos en equilibrio, no abuses de ninguno, pero si es necesario abusar de alguno, trata de delegar un poco de esa carga a otro servicio, por ejemplo en este momento estoy tratando de evitar conectarme a una base de datos que coniene de paises /ciudades cada ves que se inicia una sesion nueva, los paises y ciudades no se actualizan casi nunca, ademas solo usare unos 10 paises, para eso me creo un xml dinamicamente que php lea y cargue los paies de ahi, de esta forma estoy evitando hacer una consulta a sql, dejandolo libre y usando php, y cosas asi. otro ejemplo es como cargas un menu? lo lees de la base de datos? son cosas que yo estoy perfeccionando para hacer la webs mas optimas,

no actualizes las variables de sesion cada 2 minutos, esto genera consultas casi que innecesarias (en caso de que no se haya actualizado nada) creo que seria mejor que una ves valides el dato, lo actualizes en la base de datos y enseguida lo actualizes en la variable de sesion directamente.

de verdad es necesario tener apellido, tel, en variables de sesion? (el nombre te lo acepto, es mas podrias juntar nombre y apellido en una sola variable de sesion) digo, usas mucho estos datos? aveces nos dejamos llevar por lo poderosos que nos sentimos y queremos demostrar el poder que tenemos visualizando en pantalla datos que el usuario final no quiere ver. haz las cosas simples, pero efectivas, que el usuario le agrade el entorno visual que le proporcionas, y no que se aturda con la gran cantidad de informacion innecesaria que le imprimes en pantalla.

saludos.

[ernewston]

Gracias! Las dos respuestas me sirvieron montones.

En un punto mencionaron:
"DB funciona mejor si las consultas SQL están optimizadas y en general es el último en caerse"

A que se refieren bien con consultas optimizadas?
Esto quiere decir que le doy preferencia a mejorar el rendimiento de php antes que el de mysql cuando solo se trata de leer/actualizar?

Y con lo de hacer un equilibrio entre cada cosa, por ejemplo tengo una situacion similar a esta:
En la $_session['usuario'] tengo el id, nombre y apellido, pero en la pagina mensajes.php necesito además cargar un monton de cosas, como cargar los 2 ultimos mensajes con su respectivo texto, titulo, descripcion, etc... En ese caso tendria que crear una consulta a la base de datos para obtener los mensajes de ese usuario.

Ahora la pregunta es, tendria que hacer una consulta a la bd cada vez que se cargue esa pagina o la cargo una vez en una session y la actualizo cada tanto? (recordemos que podria llegar un mensaje de otro usuario en cualquier momento)

Es realmente delicado usar muchas consultas a la bd o seria casi lo mismo que definir variables en la session? Al final de cuentas los dos se almacenan en el disco.

No podría uno o más usuarios cargar esa pagina muchísimas veces en un hora (una especie de ataque) y poder hacer caer la bd o el servidor?
Esto ya sería tal vez una pregunta más sobre el área de seguridad.

Disculpen la molestia y muchas gracias por la ayuda!

[suntus]

en mi opinion trabajas erroneamente.

mysql es potente, mucho mas de lo que tu crees (por la forma de hablar de el), no solo es potente sino que seguro que mas rapido a la hora de trabajar que con las sesiones que comentas, sesiones enormes y a montones.

para tirar un servidor mysql, dedicado con un hardware medio que.. vas a necesitar cientos de consultas simultaneas, osea en el mismo SEGUNDO y aun lo dudaria, ya que buscar mensajes o usuarios en una DB bien estructurada con buenos indices, caches y tal, uff!! cien me quedo corto.

dale caña a mysql hombreeeeeeeee

[ernewston]

Excelente! =]

No se porque tengo la idea de usar la base de datos lo menos posible.

Eso me aclara mucho las cosas y tendré que cambiar un poco algunas cosas en mis trabajos, usaré menos sesiones y un poco más la bd. Igualmnte haré ese equilibrio intentando de ahorrar consultas o variables innecesarias.

Gracias!

[maycolalvarez]

@ernewston: cuando me refiero a consultas optimizadas se tratar de evitar en lo posible que el motor de SQL busque información para poder ejecutar determinada consulta, indicando de forma explicita cada elemento que se quiere consultar, ejemplo:

SELECT * FROM clientes; //lento porque el motor tiene que buscar cuales son los campos de la tabla clientes

SELECT nombre, apellido, id FROM clientes; //rápido porque el motor no tiene que buscar nada, solo interpretar y extraer

SELECT nombre, apellido, id_pedido FROM clientes INNER JOIN pedidos ON (id_cliente=id); //lento porque el motor tiene que buscar a que tabla le corresponde cada campo, y con el problema que puede generarse si las tablas tienen campos iguales

SELECT clientes.nombre, clientes.apellido, pedidos.id_cliente FROM clientes INNER JOIN pedidos ON (pedidos.id_cliente=clientes.id); //rápido: el motor ya sabe de quien es cada campo

y entre otras cosas como optimización se subquerys por JOINS

[ernewston]

Gracias maycolalvarez!

Este es uno de los ejemplos que mas uso en mi script:

SELECT `name`, `surname` FROM `persons` WHERE `id`='{$id}' LIMIT 1;

O otro ejemplo:

SELECT `name`, `surname` FROM `persons` WHERE `id`='{$id}' AND `time`> '{$mytime}' LIMIT 1;

Se podría escribir la consulta de otra manera más optimizada para obtener esos datos? Es rapida esta funcion??

Gracias.

[ocp001a]

¿Lees cada dos minutos la información del usuario?

En mi opinión, a menos que tener TODOS los datos del usuario actualizados al segundo sea de extrema necesidad, los datos no deberían ser leídos más que al iniciar sesión.

Incluso si es por que al usuario se le pueda asignar algún permiso, ¿qué tan frecuente puede ser? yo creo que es más recomendable que en esos casos reinicie sesión para tener los nuevos privilegios.

[suntus]

Iniciado por ernewston

Gracias maycolalvarez!

Este es uno de los ejemplos que mas uso en mi script:

SELECT `name`, `surname` FROM `persons` WHERE `id`='{$id}' LIMIT 1;

O otro ejemplo:

SELECT `name`, `surname` FROM `persons` WHERE `id`='{$id}' AND `time`> '{$mytime}' LIMIT 1;

Se podría escribir la consulta de otra manera más optimizada para obtener esos datos? Es rapida esta funcion??

Gracias.

logicamente esas consultas no se pueden optimizar mas, son consultas simples y directas, lo que si puedes Y DEBES y crear los indices para mejorar aun si cabe la busqueda que reflejas.

1º como minimo el campo ID deberia ser un indice PRIMARY
2º y luego se podria debatir la creacion de un nuevo indice para ID y TIME que en este caso seria de tipo INDEX y los 2 juntitos, (primero el id y luego time, debes seguir el mismo orden SIEMPRE tanto en la consulta como en la creacion del indice) pero eso ya yo solo lo veo si realmente la consulta 2º que muestras fuera una consulta MUY MUY usada

[Logotytype]

que tanto trafico va a tener la aplicacion?, si solo se limitara a unas cuantas personas digamos dentro de la oficina de una empresa, entonces usa mysql a tu antojo, mysql es muy pontente, si quieres saber cuanto se demora tu consulta en ejecutarse podrias guardar los timestamp de antes y despues de finalizada la consulta, y veras lo rapido q es mysql, no te preocupes por tener que hacer las mismas consultas una y otra ves.. en realidad los que mantienen los resultados de las consultas en sql en memoria despues que el script finalizo, son las paginas de alto trafico, amazon, facebook, usan algo llamado "memcahed".

http://www.maestrosdelweb.com/editor...ases-de-datos/

asi que las varaible de sesion solo dejalas para pequeños datos importantes, y que debes tener a la mano.