¿Se recolecta la basura de los transitorios?

Ahora están

A partir de WordPress 3.7, los transitorios caducados se eliminan en las actualizaciones de la base de datos, consulte # 20316

Respuesta anterior

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 su caducidad.

Algún código improvisado para realizar la recolección de basura si la base de datos se utiliza para el 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, redefiniendo y reformateando ...

Básicamente, todo se reduce a que, a menos que tenga un caso extremadamente extremo, no es necesario que se "recoja basura". Si nunca los traes, 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 están cargadas automáticamente.

Al inicio, WordPress carga las opciones en la memoria, pero solo carga las opciones que tienen su marca de carga automática activada. Los transitorios no reciben esto y, por lo tanto, no se cargan en la memoria. Solo los transitorios que se utilicen 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 opción Id 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 simples selecciones en un único valor de clave único. Por lo tanto, la búsqueda es O (log (n)) y es super rápida. Con un Big-O de log (n), tendrías que ganar millones y millones de filas antes de que se hiciera notorio. Francamente, la sobrecarga en la configuración y el 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 por comparación. Por lo tanto, simplemente tener filas no utilizadas adicionales no afecta nada, pero usa espacio en disco extra.

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

Ahora, la limpieza de la manera más obvia (llamar 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". De nuevo, así es como funcionan las bases de datos. Para realmente eliminar el espacio en el disco, debe continuar y realizar 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 ahorrarle 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é es la inserción de estos transitorios? ¿Están utilizando una clave de cambio o mutación? Si es así, entonces el complemento o el código que causa esto debe ser arreglado para, básicamente, no hacer eso. Eso será más útil, porque es probable que el código que no los está creando correctamente no los esté recuperando y, por lo tanto, haga más trabajo del que tiene que hacer.

Por otro lado, puede haber un caso en el que se estén creando transitorios para algo como cada publicación. 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 tienes 10k publicaciones, tendrás 20k filas en la tabla de opciones (eventualmente). Esto no es malo ni lento, porque nuevamente, hay muy poca diferencia entre 100 y 20,000 filas en lo que a las bases de datos realmente les importa. Todo está indexado. Es tan rápido como demonios. Sub-sub-milisegundos.

Cuando comiences a meterte en millones de filas, entonces estaré preocupado. Cuando el tamaño de la tabla de opciones aumenta por encima de cientos de megabytes, entonces me preocuparía lo suficiente como para mirar más de cerca. Pero en general, esto no es un problema, excepto en casos extremos. Ciertamente no es un problema para algo 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 de forma automática en la base de datos. / p>     

Otto - No podría estar más en desacuerdo contigo. El problema es que, finalmente, con todos esos transitorios, el tamaño de la tabla se vuelve ridículo. No se necesitan millones de filas para atascarse. Actualmente estoy tratando 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. A pesar de que es lógicamente parte de la misma tabla, las uniones deben ocurrir para jalar las filas que desea. Las uniones que ahora llevan una eternidad porque los datos que necesita se distribuyen por todo el disco. El perfilado (usando el perfilador de chorro para mysql) ha demostrado esto.

Agregar la carga automática a la clave agrupada podría ayudar a resolver este problema. La agrupación en Autload 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 de DB.

Personalmente creo que el diseño de este sistema es raro. La tabla de opciones parece haberse convertido en un catch-all general para muchas cosas. Eso está bien si el campo de valor es lo suficientemente pequeño como para ser incluido en la misma página que el resto de los datos de la fila, y se puede indexar de manera efectiva. Lamentablemente ese no es el caso. Quienquiera que haya diseñado esto necesita volver a la clase DB101.