¿Se recolectan los desechos transitorios?

Esta pregunta me hizo pensar que las fuentes RSS transitorias en wp_options no se eliminan automáticamente.

Se supone que los transitorios caducan y se eliminan. Sin embargo, la única forma en que veo que esto se maneja es cuando el transitorio caduca y se solicita, luego se elimina durante la solicitud.

¿Qué pasa si el transitorio expiró pero nunca se solicitó después de eso? De la descripción en Codex, pensé que algún tipo de recolección de basura está implícito. Ahora no estoy tan seguro y no puedo encontrar ningún código que realice tal.

Entonces, ¿se quedará atascado en la base de datos para siempre?

Ahora son

Comenzando con WordPress 3.7, los transitorios caducados se eliminan en las actualizaciones de la base de datos, ver # 20316

Vieja respuesta

Si alguien no puede mostrarme lo contrario, parece que los transitorios no son basura recolectada después de todo. Lo que lo empeora es que, a diferencia de las opciones, no se garantiza que se almacenen en la base de datos. Por lo tanto, no hay una forma confiable de obtener una lista de todos los transitorios para verificar que caduquen.

Algunos códigos improvisados ​​para la recolección de basura si la base de datos se usa para almacenamiento:

add_action( 'wp_scheduled_delete', 'delete_expired_db_transients' );

function delete_expired_db_transients() {

    global $wpdb, $_wp_using_ext_object_cache;

    if( $_wp_using_ext_object_cache )
        return;

    $time = isset ( $_SERVER['REQUEST_TIME'] ) ? (int)$_SERVER['REQUEST_TIME'] : time() ;
    $expired = $wpdb->get_col( "SELECT option_name FROM {$wpdb->options} WHERE option_name LIKE '_transient_timeout%' AND option_value < {$time};" );

    foreach( $expired as $transient ) {

        $key = str_replace('_transient_timeout_', '', $transient);
        delete_transient($key);
    }
}

Trasladar algunos de los comentarios de la discusión a una respuesta, con una nueva redacción y un nuevo formato.

Básicamente, todo se reduce a que, a menos que tenga un caso súper extremo, en realidad no necesitan ser "recolectados de basura". Si nunca los busca, entonces no importa si están allí o no.

Ver, los transitorios se almacenan en la tabla de opciones de forma predeterminada. En una instalación básica, la tabla de opciones tendrá quizás 100 entradas. Cada transitorio agrega dos entradas más, pero incluso si tiene miles, no afectan la velocidad del sitio, ya que no se cargan automáticamente.

Al inicio, WordPress carga las opciones en la memoria, pero solo carga las opciones que tienen activada su bandera de carga automática. Los transitorios no reciben esto, por lo que no se cargan en la memoria. Solo los transitorios que se usan realmente más tarde incurrirán en un costo.

Desde la perspectiva de la base de datos, la tabla de opciones tiene índices tanto en la ID de la opción como en el nombre de la opción. Los transitorios siempre se cargan en función del nombre (clave), por lo que las búsquedas para ellos siempre son selecciones simples en un único valor de clave único. Por lo tanto, la búsqueda es O (log (n)) y es súper rápida. Con un Big-O de log (n), tendrías que entrar en los millones y millones de filas antes de que sea notable. Francamente, la sobrecarga en la configuración y desmontaje de la consulta, junto con la transferencia de datos real, es mucho más larga. La consulta en sí se ejecuta esencialmente en tiempo cero en comparación. Entonces, simplemente tener filas adicionales sin usar no afecta nada más que usar espacio extra en disco.

La indexación en bases de datos es una de esas ideas de lectura profunda que no tiene sentido para las personas que realmente no han entendido lo que está sucediendo detrás de escena. Las bases de datos están diseñadas para una recuperación rápida de datos, desde cero, y pueden manejar este tipo de cosas sin problemas. Esta es una lectura bastante buena: http://en.wikipedia.org/wiki/Index_(database )

Ahora, la limpieza de la manera más obvia (llamando a SQL DELETE en ellos) en realidad no los elimina de la base de datos. Simplemente los elimina del índice y marca la fila como "eliminada". Nuevamente, así es como funcionan las bases de datos. Para liberar realmente el espacio en disco, debe continuar y hacer una TABLA DE OPTIMIZACIÓN después, y esta no es una operación rápida. Toma tiempo. Probablemente más tiempo del que vale. Probablemente no sea suficiente para darle un ahorro en tiempo de CPU, en total.

Si tiene algún caso que está causando una inserción continua de nuevos transitorios que no se están utilizando, entonces necesita encontrar el problema subyacente. ¿Qué está insertando estos transitorios? ¿Están utilizando una clave cambiante o mutante? Si es así, entonces el complemento o el código que causa esto debería estar arreglado, básicamente, para no hacerlo. Eso será más útil, porque es probable que el código que no los crea correctamente tampoco los recupere y, por lo tanto, haga más trabajo del que tiene que hacer.

Por otro lado, puede haber un caso en el que se crean transitorios para algo como cada publicación. De hecho, esto puede ser perfectamente aceptable. Lo hago yo mismo en SFC, para almacenar los comentarios entrantes de Facebook. Cada publicación tiene un potencial transitorio asociado, lo que significa dos filas adicionales por publicación. Si tiene 10k publicaciones, tendrá 20k filas en la tabla de opciones (eventualmente). Esto no es malo ni lento, porque de nuevo, hay muy poca diferencia entre 100 filas y 20,000 filas en lo que a las bases de datos realmente les importa. Todo está indexado. Es rápido como el diablo. Sub-sub-milisegundos.

Cuando empiezas a meterte en millones de filas, entonces me preocuparía. Cuando el tamaño de la tabla de opciones aumenta por encima de cientos de megabytes, entonces me preocuparía lo suficiente como para echar un vistazo más de cerca. Pero en general, esto no es un problema, excepto en casos extremos. Ciertamente, no es un problema para nada más pequeño que algo como un gran sitio de noticias, con cientos de miles de publicaciones. Y para cualquier sitio lo suficientemente grande como para que sea un problema, debe usar un caché de objetos externo de algún tipo, y en ese caso, los transitorios se almacenan automáticamente allí en lugar de en la base de datos.

Otto: no podría estar más en desacuerdo contigo. El problema es que eventualmente con todos esos transitorios, el tamaño de la tabla se vuelve ridículo. No se necesitan millones de filas para atascarse. Actualmente estoy lidiando con una tabla de opciones que tiene más de 130k filas y se cuelga regularmente. Debido a que el campo de valor es un tipo de texto grande, incluso buscar solo las filas de "carga automática" se convierte en una pesadilla de rendimiento. Esos campos de valor se almacenan por separado del resto de los datos de la fila. Aunque es lógicamente parte de la misma tabla, las uniones deben ocurrir para extraer las filas que desee. Uniones que ahora tardan una eternidad porque los datos que necesita se extienden por todo el lugar en el disco. El perfilado (usando jet profiler para mysql) ha demostrado esto.

Agregar carga automática a la clave agrupada podría ayudar a resolver este problema. La agrupación en Autoload Desc, ID ASC por ejemplo, permitiría que todas las filas de carga automática se agrupen primero en el disco. Aún así, creo que estás viendo una gran tensión desde una perspectiva DB.

Personalmente creo que el diseño de este sistema es wack. La tabla de opciones parece haberse convertido en un genérico para muchas cosas. Eso está bien si el campo de valor es lo suficientemente pequeño como para incluirse en la misma página que el resto de los datos de la fila, y puede indexarse ​​de manera efectiva. Lamentablemente ese no es el caso. Quien haya diseñado esto debe volver a la clase DB101.