• Resuelto cr0hn

    (@cr0hn)


    Hola,

    Lamento abrir un nuevo post para este mismo tema, pero no he logrado desbloquear el original para seguir escribiendo (http://es.forums.wordpress.org/topic/wordpress-muy-lento-en-la-zona-de-administracion).

    Tras el último comentario de erchache2000, me dispuse a leer y optimizar mi mysql, además de hacer otro tipo de pruebas.

    He logeado todas las consultas que hace wordpress a mysql y , tras ejecutarlas a mano desde el servidor web, las he puesto en un .php independiente, que realiza la conexión a la base de datos de forma manual, y muestra un mensaje cuando el script ha finalizado. Como resultado: se ejecuta en milisegundos.

    Este es el script que ejecuto desde mi navegador (igual que llamo a wordpress).

    <?php
    mysql_connect(‘XXXXX’,’XXXX’,’XXXXXXXX’);
    @mysql_select_db(‘XXXXX’) or die( «Unable to select database»);

    $query=»SET NAMES utf8;
    SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’;
    SELECT option_value FROM wp_options WHERE option_name = ‘twentyeleven_theme_options’ LIMIT 1;
    SELECT * FROM wp_users WHERE user_login = ‘Admin’;
    SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1);
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_pages’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_calendar’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_links’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_tag_cloud’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_nav_menu’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_widget_twentyeleven_ephemera’ LIMIT 1;
    SELECT option_value FROM wp_options WHERE option_name = ‘widget_twentyeleven_ephemera’ LIMIT 1;
    UPDATE wp_options SET option_value = ‘1351454169.4415850639343261718750’ WHERE option_name = ‘_transient_doing_cron’;»
    mysql_query($query);
    mysql_close();

    echo «terminado»;
    ?>

    Esto me hace pensar que, tal vez, el problema no esté en la base de datos, sino en el propio wordpress. Espero estar equivocado y que tenga una explicación mas «lógica».

    PDT: He aumentado la memoria de wordpress a 64MB y la de php a 256MB, para evitar problemas por falta de memoria.

    Un saludo.

Viendo 6 respuestas - de la 1 a la 6 (de un total de 6)
  • Moderador erchache2000

    (@erchache2000)

    Tu problema no es un problema de WordPress, es un problema de tu sistema de virtualización.

    Seguramente no habrás montado correctamente el sistema operativo anfitrión y tampoco el hipervisor del gestor de máquinas virtuales.

    No tendrás parcheado freebsd para que éste reconozca que está ejecutandose en un sistema virtualizado y por ello el rendimiento del sistema se ve mermado considerablemente.

    Luego está que has separado lo que es el servidor web que ejecuta el código php de la base de datos, que está incorrectamente configurado.

    Todo ello hace que tengas tu instancia WordPress sobre un sistema inestable y de ahí tus problemas de rendimiento.

    Iniciador del debate cr0hn

    (@cr0hn)

    Buenas,

    Creo que estás enfocando el problema desde un punto de vista que no es.

    Das por hecho que el sistema de virtualización es un cuello de botella, que no va bien y que el sistema anfitrión no está bien configurados.

    Los invitados están parcheados para que Xen los reconozca. Tiene un rendimiento muy bueno (está medido).

    El sistema anfitrión está ajustado para rendimiento: los sysctl, la interfaces de red y el hypervisor.

    Para una arquitectura escalable y segura lo correcto es separar el backend del frontend. Lo raro es ponerlos en la misma máquina.

    En la misma máquina que aloja el servidor web tengo otros sitios (con las mismas configuraciones del nginx, recursos y jaulas), hechos en java, y funcionan perfectamente. De ahí pensar que el problema puede ser por WordPress o php.

    Como comento en el primero post, las mismas consultas hechas por WordPress se hacen de forma manual desde un .php independiente, se ejecutan en milisegundos. Lo normal es pensar que algo pasa con la aplicación web, en este caso WordPress.

    He buscado por internet y he visto que no es un problema que me ocurra solo a mi (de hecho google lo «autocompleta»). Veo que a partir de la versión 3.4.1 le está ocurriendo a mucha gente que la zona de administración no le funcione bien (http://wordpress.org/support/topic/wp-admin-even-33-incredibly-slow?replies=65).

    Por lo que comento en el anterior párrafo, me hace pensar que tal vez sea algo de Wordpres (o php), ya que parece ser que no es un caso aislado.

    Un saludo.

    Moderador erchache2000

    (@erchache2000)

    Según me comenta @bi0xid de @mecus, tienes que actualizar TODO el software. Tanto WordPress como el sistema operativo (ngninx, php y tal…) a las últimas versiones estables.

    Por lo visto al subir la versión de php te irá fino fino filipino.

    Prueba…

    Iniciador del debate cr0hn

    (@cr0hn)

    Buenas,

    Muchas gracias por contestar y por tu tiempo.

    Tras entrar en modo desesperación. Probé lo siguiente, sin ningún resultado positivo:
    – Actualizar php. Testeado con las versiones: 5.4.5; 5.4.6 y 5.4.7.
    – Actualizar php-extensions.
    – «Desactualizar» php. Probando la versión: 5.2.
    – Probar la versión de wordpress beta de wordpress: 3.5.-beta2
    – Poner la base de datos en el mismo sistema que está el servidor web, para descartar las latencias de red y conectar a localhost.
    – Aumentar todas las variables de timeout de php, mysql y nginx.
    – Aumentar los tamaños de los paquetes recibidos en mysql (a 164M).
    – Evitar la resolución de nombres en mysql.
    – Aumentar el buffer de red de mysql (net_buffer_length=1048576).

    Síntomas «raros» que he detectado:
    – Cuando cargo la parte pública de wordpress, tarda mucho en cargar pero al final lo hace. Una vez hecha la primera carga, las siguientes van bien.
    – Cuando intento cargar: «wp-admin/themes.php», «wp-admin/plugins.php» o «wp-admin/update-core.php» siempre me da un timeout y, además, cuando después intento cargar cualquier otra página tarda muchiiiiisimo o también me da timeout.

    Cualquier sugerencia es muy bien recibida.

    Sigo investigando. Si encontrara la solución, os lo comento.

    Un saludo.

    Iniciador del debate cr0hn

    (@cr0hn)

    Hola de nuevo,

    Creo que acabo de concluir que es un fallo de WordPress.

    El porqué?

    Acabo de instalar opencart (borrado los ficheros de WordPress y reemplazados por los de opencart) y funciona sin ningún problema.

    Tenéis constancia de un fallo similar? Creéis que debería de abrir un ticket?

    Un saludo

    Moderador erchache2000

    (@erchache2000)

    Abre un ticket pero antes lee esto, http://codex.wordpress.org/Reporting_Bugs

    ¿Tienes ip pública para testear?

Viendo 6 respuestas - de la 1 a la 6 (de un total de 6)
  • El debate ‘WordPress muy lento en la zona de administración (2)’ está cerrado a nuevas respuestas.