[PHP] Cache ?

[Federicomb]

Holaaa, como va?

Bueno, andaba por acá para preguntarles si es posible guardar datos en cache en PHP y cual sería la forma correcta de hacerlo. Más que nada preguntaba porque tengo scripts php los cuales cada vez que son consultados hacen consultas al servidor MySQL y lo que quiero evitar es eso. Mi idea sería que se renueven los datos cada cierto tiempo, ya que solo son datos que muestro. Al haber mucha cantidad de usuarios consultando al mismo tiempo, eso genera que el servidor tarde más tiempo en responder (un ejemplo exagerado).

Es posible poder guardar datos en cache y luego consultarlos de ahí?

Gracias de antemano.

[KISKE]

Es posible poder guardar datos en cache y luego consultarlos de ahí?

No estoy seguro de a qué te referís con esa parte.

start_cache.php

Código PHP:

<?php
    $url = $_SERVER["SCRIPT_NAME"];
    $break = Explode('/', $url);
    $file = $break[count($break) - 1];
    $cachefile = 'cached-'.substr_replace($file ,"", -4).'.html';
    $cachetime = 300;
    
    if(file_exists($cachefile) && time() - $cachetime < filemtime($cachefile)) {
        include($cachefile);
        exit;
    }
    
    ob_start();
?>

end_cache.php

Código PHP:

<?php
    $cached = fopen($cachefile, 'w');
    
    fwrite($cached, ob_get_contents());
    fclose($cached);
    
    ob_end_flush();
?>

Include arriba de todo y abajo de todo con los archivos correspondientes y básicamente te crea un .html de la página tal cual está y luego muestra ese archivo si el tiempo establecido no transcurrió.

Tené en cuenta que esto funciona para páginas globales, si tu página tiene consultas dinámicas no funcionaría, es decir, si tu página tiene consulta/s según el usuario que la visita esto no funcionaría, necesitás buscar algo así como 'PHP Cache Dynamic Pages', fijate en Google, hay muchísimos ejemplos.

[LuKks]

http://php.net/manual/es/book.apcu.php

[Federicomb]

Es posible poder guardar datos en cache y luego consultarlos de ahí?

No estoy seguro de a qué te referís con esa parte.

start_cache.php

Código PHP:

<?php
    $url = $_SERVER["SCRIPT_NAME"];
    $break = Explode('/', $url);
    $file = $break[count($break) - 1];
    $cachefile = 'cached-'.substr_replace($file ,"", -4).'.html';
    $cachetime = 300;
    
    if(file_exists($cachefile) && time() - $cachetime < filemtime($cachefile)) {
        include($cachefile);
        exit;
    }
    
    ob_start();
?>

end_cache.php

Código PHP:

<?php
    $cached = fopen($cachefile, 'w');
    
    fwrite($cached, ob_get_contents());
    fclose($cached);
    
    ob_end_flush();
?>

Include arriba de todo y abajo de todo con los archivos correspondientes y básicamente te crea un .html de la página tal cual está y luego muestra ese archivo si el tiempo establecido no transcurrió.

Era justo eso lo que tenía en mente, capaz me expresé mal.

Tené en cuenta que esto funciona para páginas globales, si tu página tiene consultas dinámicas no funcionaría, es decir, si tu página tiene consulta/s según el usuario que la visita esto no funcionaría, necesitás buscar algo así como 'PHP Cache Dynamic Pages', fijate en Google, hay muchísimos ejemplos.

Ese es el otro tema. Implemente el code que pasate y funciona de maravillas, pero al momento de obtener el id con $_GET['id'] al no ser un caché dinámico no funciona como bien dijiste. Muchas gracias por la ayuda

[LuKks]

Puedes crear un caché para cada id (un html por id) pero las soluciones óptimas varían dependiendo como sea el sistema ya que yo no cachearía miles de .html para distintos ids.
Tienes que optimizar las consultas, estructurar bien las tablas, cachear las consultas y nada más, MySQL hace lo suyo.

Haz pruebas, crea una tabla con muchas filas y luego haz un script en php para que cada medio segundo consulte distintas filas distintas y verás que sigue siendo muy rápido.
Cuando alguien visita la web con el id "18", la próxima visita con el mismo id será mas rápido porque estará cacheada (por la propia base de datos). Cuando crees la tabla ejemplo con muchas filas, haz dos consultas con el mismo id y verás que la segunda, tercer, cuarta, etc consulta con el mismo id serán casi instantáneas en comparación con la primera.
Aquí tiene mucho que ver el tema de definir muy bien los índices.

Generalmente, uno quizás intente cachear lo que es html, css, js, imgs por tema de recursos de conexión, no tanto de cpu pero para eso están las CDN (Content Delivery Network) en caso de tener muchas visitas y querer ahorrar cpu, red, etc en el servidor.

[Neeeeeeeeeel.-]

Si no estás hablando de querys que consulten más de 1 millón de datos, es casi al pedo... con un antiflood para evitar DDoS en capa 7 alcanza.

Código PHP:

session_start();
if (!empty($_SESSION['flood']) && $_SESSION['flood'] >= 3){
    exit(); //flood detected
}
$_SESSION['flood']++;
if (!isset($_SESSION['flood']) || $_SESSION['floodtime']+3 < time()){
    $_SESSION['flood'] = 0;
    $_SESSION['floodtime'] = time();
} 


Lo escribí rápido, así que puede tener errores.

[LuKks]

Lo escribí rápido, así que puede tener errores.

También lo pensaste rápido porque desahabilito las cookies y me salteo la sessión, esto se hace con ip y sin sesiones, o mejor dicho se hace desde Apache/Nginx/etc pero no hay nada de malo implementar otra verificación desde php.

[Neeeeeeeeeel.-]

Lo escribí rápido, así que puede tener errores.

También lo pensaste rápido porque desahabilito las cookies y me salteo la sessión, esto se hace con ip y sin sesiones, o mejor dicho se hace desde Apache/Nginx/etc pero no hay nada de malo implementar otra verificación desde php.

Sí me olvidé de eso... podés hacer lo mismo por IP y a un archivo común, es un poco más largo el código pero es lo mismo.

[LuKks]

Si ya tiene una base de datos funcionando, que agregue una tabla más para implementar el antiflood con ella, mas o menos de la misma forma que te mostró Nel en su ejemplo pero utilizando MySQL y por ip (recuerda borrar registros antiguos!).

[Federicomb]

Pero no sería lo mismo? Si yo lo que intentaba minimizar es las consultas a la base de datos

Yo en el script me conecto al inicio y desconecto al final, no mantengo una conexión permanente (no se si eso deba ser así ). Capaz que debería ver cómo mejorar eso y no las consultas en si. Porque mi duda sería en un 'flood', al conectar y desconectar constantemente no puede cerrar la base de datos?

[Neeeeeeeeeel.-]

Pero no sería lo mismo? Si yo lo que intentaba minimizar es las consultas a la base de datos

Como dije, seguramente por el volumen de datos que manejás sería completamente al pedo que hagas cualquier cosa que no sea obtener los datos directamente.

Yo en el script me conecto al inicio y desconecto al final, no mantengo una conexión permanente (no se si eso deba ser así ).

Eso está bien, siempre es así.

Capaz que debería ver cómo mejorar eso y no las consultas en si. Porque mi duda sería en un 'flood', al conectar y desconectar constantemente no puede cerrar la base de datos?

No entendí nada.

Para que te des una idea, cada vez que se llama al index.php del foro se ejecutan alrededor de 50 consultas a la base de datos...

Para cuando hay grandes volúmenes de datos, lo que se hace es almacenar los resultados calculados en otra tabla, para usarla de cache, y refrescarla cada tanto. Así hace MyBB, por ejemplo. Pero estoy seguro de que no lo necesitás.

[Federicomb]

Ahhh perfecto entonces, muchas gracias por la data Nel.

No creo que lo necesite, a menos que tenga millones de registros

Tengo una sola tabla con alrededor de 40.000 registros y ponele que por día se agreguen aprox 120 nuevos datos, esa sería la más grosa que tengo. Luego tengo otras 5 que manejan datos desde los 2.000 hasta los 6.000 cada tabla, obviamente que con los días se van sumando registros, pero todas las tablas están indexadas y cuando ejecuto el/los script busca datos en base al número de id.

Ahora me quedo un poco más tranquilo al saber que no hacía mal en conectarme de la forma en que lo hago, podría decir que están correctos los scripts.

Gracias

---

Capaz que debería ver cómo mejorar eso y no las consultas en si. Porque mi duda sería en un 'flood', al conectar y desconectar constantemente no puede cerrar la base de datos?

En esto me refería ya que en el script se conecta y desconecta, al 'intentar' hacer un 'flood' no podría ocasionar que la base de datos se cierre por multiples conexiones o algo de eso? Aunque está en localhost, no es remoto y no creo que pase eso

[Neeeeeeeeeel.-]

Ahora me quedo un poco más tranquilo al saber que no hacía mal en conectarme de la forma en que lo hago, podría decir que están correctos los scripts.

De ahí a que los scripts estén bien hechos hay un largo tramo en el medio...

En esto me refería ya que en el script se conecta y desconecta, al 'intentar' hacer un 'flood' no podría ocasionar que la base de datos se cierre por multiples conexiones o algo de eso? Aunque está en localhost, no es remoto y no creo que pase eso

Los ataques de capa 7 son complicados, hay que verlos caso a caso...

PD: Algunas tablas de la base de un cliente...

[KISKE]

Los ataques de capa 7 son complicados

Cada vez que decís capa 7 me acuerdo de 'FER Tiene Su Pie Ancho', así me lo enseñaron y así me quedo para siempre, es muy sencillo de acordarse realmente.

[LuKks]

Con esa cantidad de datos, no pasa nada, podes abusarte de MySQL todo lo que quieras.
Sobre conectar y desconectar con la base de datos en caso de que sea un atacante, no pasa nada, porque el mismo atacante solo podrá realizar el ataque a poca escala (dos o tres peticiones por segundo, máximo).
Y si lo avanzás mas, podes registrar de forma detallada la cantidad de peticiones de cada ip para saber si se están realizando peticiones constantes de una determinada ip pero que no llega a pasar el límite de 3 por segundo, entonces, si sucede esto también bloqueas esa ip.
Diría que debes aplicar si o si este "extra" y no solo limitar las peticiones por segundo, ya que seguirías siendo vulnerable, imagínate que tengo a disposición algunos miles de usuarios o miles de webs con distintas ips.. lo que hago es toda esta masa de usuarios haciéndote 3 peticiones por segundo (sin pasar el límite, también te ataco la web), en cambio, con el "extra" aplicado esto solo sucederá dos minutos, es decir, el ataque no será eficiente y ni lo vas a sentir.

[Neeeeeeeeeel.-]

Los ataques de capa 7 son complicados

Cada vez que decís capa 7 me acuerdo de 'FER Tiene Su Pie Ancho', así me lo enseñaron y así me quedo para siempre, es muy sencillo de acordarse realmente.

Jajajajaj es buena...