Objetos persistentes en WordPress/PHP

4 minutos de lectura

Objetos persistentes en WordpressPHP
conocido

Me gustaría crear un conjunto de objetos persistentes que carguen su estado desde la base de datos y luego se mantengan en la memoria para que las cargas de páginas de WordPress/PHP se usen como objetos de memoria en caché. Me imagino una interfaz para que estos objetos incluyan:

  • initialise(): carga el estado de la base de datos y realiza cualquier otra función de inicialización necesaria antes de atender las solicitudes
  • getter_foo() – una serie de métodos getter para que el código PHP solicite respuestas almacenadas en la memoria caché
  • getter_bar() – una serie de métodos getter para que el código PHP solicite respuestas almacenadas en la memoria caché
  • update () – llamado por procesos controlados por tiempo o eventos que le piden al objeto que regrese a la base de datos y actualice su estado

Los dos trucos que sospecho son:

  1. Haga que el proceso principal de PHP asigne y mantenga la referencia de memoria para estos objetos para que permanezcan anclados a la memoria a través de transacciones/solicitudes web sin necesidad de reinicializar cada vez en la base de datos.
  2. Tener un mecanismo para permitir que los procesos transaccionales obtengan un puntero a estos objetos.

¿Hay ejemplos de soluciones que hagan esto? He estado programando durante años, pero soy muy nuevo tanto en WordPress como en PHP, así que tal vez esto sea bastante sencillo. No estoy seguro. En cualquier caso, reconozco que soluciones técnicas como redis y memcached podría lograr objetivos similares pero de una manera menos elegante y no contextual. Dicho esto, si no hay una manera fácil de hacerlo, estoy feliz de usar la regla 80/20. :^)

No es posible almacenar datos en la memoria durante 1 solicitud y luego volver a leerlos de la memoria durante otra solicitud usando nada más que PHP simple. Claro que el proceso PHP usa memoria, pero tan pronto como finaliza su solicitud, esa parte de la memoria se recolecta como basura. Lo que significa que una segunda solicitud no puede volver a acceder a esa parte anterior de la memoria.

Lo que estás insinuando, se llama almacenamiento en caché. En pocas palabras, el almacenamiento en caché significa que usted guarda el resultado de una transacción costosa para su posterior reutilización, para ahorrar en el costo de esa transacción. Lo que luego use como backend para almacenar esa salida depende de usted o de lo que tenga disponible. Si desea guardarlo en la RAM, necesitará algo como Memcached. También puede almacenarlo en un archivo normal, pero eso es más lento debido a que se accede al disco duro.

  • Gracias Miljar. Soy consciente de memcached y redis. Probablemente los usaré, pero esperaba un mecanismo como el que describí, ya que puede tener algunos beneficios agradables en comparación con soluciones más infraestructurales como memcached/redis.

    – saber

    15 mayo 2012 en 23:11

  • Supongo que si tiene razón en que no hay forma de hacer esto, eso también significa que no hay forma de crear una capa de administración de base de datos que mantenga un conjunto de conexiones abiertas a la base de datos. ¿A menos que WordPress sea lo suficientemente inteligente como para hacer esto por sí mismo? En los sitios de transacciones altas, esto es un gran beneficio, ya que puede mantener las conexiones y obtener más reutilización de las variables de vinculación también.

    – saber

    15 mayo 2012 en 23:12


  • Es posible mantener una conexión abierta compartida en una solicitud. Pero nunca he oído hablar de compartirlo a través de múltiples solicitudes. Si tiene tantas lecturas de su base de datos, intentaría almacenar en caché los resultados de su consulta en Memcache y consideraría una configuración Maestro-Esclavo para su base de datos con un grupo de esclavos para leer.

    – Miljar

    16 mayo 2012 en 07:41

  • Creo que probablemente tengas razón Miljar. En algunas de las aplicaciones realmente grandes en las que he estado involucrado a lo largo de los años, compartir las conexiones del grupo fue de gran valor, pero todo esto fue en una era anterior a Memcached.

    – saber

    23 mayo 2012 en 07:09


  • Los beneficios fueron dos: (1) el costo de abrir y cerrar conexiones entre la lógica de negocios y los niveles de almacenamiento de datos fue costoso y (2) la base de datos tuvo que ejecutar una explicación en consultas estructuradas de manera similar en lugar de usar variables de vinculación para evitar esta sobrecarga . Sospecho que con Memcached está logrando una regla 80/20 con muy poco esfuerzo, por lo que hay menos casos en los que gastar el esfuerzo en el último 20 % del continuo tiene sentido. Voy a cerrar esta pregunta por ahora. Gracias por tu contribución.

    – saber

    23 mayo 2012 en 07:11

.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad