¿WP Super Cache y DB Cache Reloaded Fix juntos?

  • Autor Autor dogwasher
  • Fecha de inicio Fecha de inicio
Por cierto, yo tengo suPHP activo en apache y creo que no soporta los sistemas cache. Bueno, APC y XCache con limitaciones creo. ¿Habría algún problema con memcache? :ambivalence:

No uses suPHP, es el que tiene peor rendimiento de todos los handlers. Mejor utiliza mod_php o FastCGI.

Y no soporta ni APC ni nada de eso, en cuanto a memcache si lo soporta.
 
No uses suPHP, es el que tiene peor rendimiento de todos los handlers. Mejor utiliza mod_php o FastCGI.

Y no soporta ni APC ni nada de eso, en cuanto a memcache si lo soporta.

Es más lento pero consume menos RAM, aveces no queda otra 🙁
 
Es más lento pero consume menos RAM, aveces no queda otra 🙁

Algo muy curioso, es que he instalado WordPress en blanco, y he realizado pruebas con Apache bench, y ni mod_php, ni fastcgi consumen tanta memoria RAM, apenas y consumen unos 100MB en total, con el CPU al 100% durante las pruebas, y suPHP ademas de ser lento, consume mucho CPU, y el CPU es mas caro que la memoria RAM en mi caso.

Podria ser porque uso APC. El caso es que mi configuracion no usa memoria RAM casi ni en los tests.
 
Algo muy curioso, es que he instalado WordPress en blanco, y he realizado pruebas con Apache bench, y ni mod_php, ni fastcgi consumen tanta memoria RAM, apenas y consumen unos 100MB en total, con el CPU al 100% durante las pruebas, y suPHP ademas de ser lento, consume mucho CPU, y el CPU es mas caro que la memoria RAM en mi caso.

Podria ser porque uso APC. El caso es que mi configuracion no usa memoria RAM casi ni en los tests.

Claro si usas APC usaras menos CPU.

Yo uso PHP-FPM y me gusta, mod_php es rápido pero no lo pongo nunca, luego fallan otras cosas y el user - grupo y todo lo demás 🙁
 
Al final, tendremos que pasar este hilo a hosting.
La cuestión inicial era hacer correr wp-super cache + suPHP + memcached/memcache y ver el rendimiento. De hecho, lo tengo por el tema de seguridad pero creo que tampoco es para tanto y la cpu no me preocupa hasta ahora. En un vps anterior tenía fast-cgi, pero lo mismo estaba mal configurado porque no he notado diferencia (era administrado). Con suPHP y probando con pagespeed se superan los 90 puntos, machacando un poco las cosas, sobretodo la parte de wordpress.
El tema de los handlers tiene para rato. Supongo que fast-cgi será el más compatible si hiciese un cambio ya que mantiene los permisos de suPHP. Creo que lo hace correr como usuario,no? Más que nada, lo haría para implementar el APC u otra caché.
El php-fpm,¿se usa solo o con fast-cgi?.

- - - Actualizado - - -

Claro si usas APC usaras menos CPU.

Yo uso PHP-FPM y me gusta, mod_php es rápido pero no lo pongo nunca, luego fallan otras cosas y el user - grupo y todo lo demás 🙁

Al final, cambié suPHP por FastCGI (Preworker) e instale APC. En wordpress, además del wp-super cache, estoy probando con el APC Object Cache. Cargas de un index de 0,700 me ha bajado a 0,300 aprox. 😱 (lo que habéis dicho aquí....va que vuela).
El consumo de cpu aumentó al principio pero estoy al tanto. La ram, por supuesto, se disparó progresivamente. El problema que tengo son los avisos de consumo de recursos, pero brutales los e-mails que me llegan.
Los de memoria y procesos específicos los he resuelto tocando la configuración del firewall, pero los que ejecutan propiamente php, ni idea. En algunos foros sugieren un cron para ellos, yo supongo que tendrá algo que ver FcgidProcessLifeTime del mod_fcgid.c y el firewall, pero no consigo resolverlo del todo.
 
Al final, tendremos que pasar este hilo a hosting.
La cuestión inicial era hacer correr wp-super cache + suPHP + memcached/memcache y ver el rendimiento. De hecho, lo tengo por el tema de seguridad pero creo que tampoco es para tanto y la cpu no me preocupa hasta ahora. En un vps anterior tenía fast-cgi, pero lo mismo estaba mal configurado porque no he notado diferencia (era administrado). Con suPHP y probando con pagespeed se superan los 90 puntos, machacando un poco las cosas, sobretodo la parte de wordpress.
El tema de los handlers tiene para rato. Supongo que fast-cgi será el más compatible si hiciese un cambio ya que mantiene los permisos de suPHP. Creo que lo hace correr como usuario,no? Más que nada, lo haría para implementar el APC u otra caché.
El php-fpm,¿se usa solo o con fast-cgi?.

- - - Actualizado - - -



Al final, cambié suPHP por FastCGI (Preworker) e instale APC. En wordpress, además del wp-super cache, estoy probando con el APC Object Cache. Cargas de un index de 0,700 me ha bajado a 0,300 aprox. 😱 (lo que habéis dicho aquí....va que vuela).
El consumo de cpu aumentó al principio pero estoy al tanto. La ram, por supuesto, se disparó progresivamente. El problema que tengo son los avisos de consumo de recursos, pero brutales los e-mails que me llegan.
Los de memoria y procesos específicos los he resuelto tocando la configuración del firewall, pero los que ejecutan propiamente php, ni idea. En algunos foros sugieren un cron para ellos, yo supongo que tendrá algo que ver FcgidProcessLifeTime del mod_fcgid.c y el firewall, pero no consigo resolverlo del todo.

En firewall tienes que añadir PHP en el white list para que no lo monitoree y no te lleguen esos emails

O bien en el mismo firewall subir el tiempo, que por defecto es avisar si un proceso se ejecuta más de 60 segundos, lo subes y listo.

Esto pasa con fastcgi por que el proceso no muere, si no se queda atendiendo otras peticiones.
 
Al final, cambié suPHP por FastCGI (Preworker) e instale APC. En wordpress, además del wp-super cache, estoy probando con el APC Object Cache. Cargas de un index de 0,700 me ha bajado a 0,300 aprox. 😱 (lo que habéis dicho aquí....va que vuela).
El consumo de cpu aumentó al principio pero estoy al tanto. La ram, por supuesto, se disparó progresivamente. El problema que tengo son los avisos de consumo de recursos, pero brutales los e-mails que me llegan.
Los de memoria y procesos específicos los he resuelto tocando la configuración del firewall, pero los que ejecutan propiamente php, ni idea. En algunos foros sugieren un cron para ellos, yo supongo que tendrá algo que ver FcgidProcessLifeTime del mod_fcgid.c y el firewall, pero no consigo resolverlo del todo.

Usar PHP APC no es cualquier cosa, si lo configuras mal, podria causarte problemas.

Tienes que elegir cierta cantidad de memoria para opcode tomando en cuenta el tamaño del CMS, en este caso WP, y deberia ser de al menos 30MB ~50MB por sitio.

Y necesitas revisar el uptime de la cache para ver que funcione correctamente, al igual que el radio hit/miss.
El archivo apc.php te sera util para configurar adecuadamente, y es una seccion de memoria para cada sitio, asi que tendras que revisar los sitios independientemente (por cuenta o usuario mas bien).

- - - Actualizado - - -

En firewall tienes que añadir PHP en el white list para que no lo monitoree y no te lleguen esos emails

O bien en el mismo firewall subir el tiempo, que por defecto es avisar si un proceso se ejecuta más de 60 segundos, lo subes y listo.

Esto pasa con fastcgi por que el proceso no muere, si no se queda atendiendo otras peticiones.

Yo tengo un problema al usar FastCGI, y por ejemplo, el proceso de PHP muere despues de cierto tiempo, y la cache de opcode en APC se reinicia, con mod_php no me pasaba esto, no se exactamente que directivas tenga que cambiar.
 
En firewall tienes que añadir PHP en el white list para que no lo monitoree y no te lleguen esos emails

O bien en el mismo firewall subir el tiempo, que por defecto es avisar si un proceso se ejecuta más de 60 segundos, lo subes y listo.

Esto pasa con fastcgi por que el proceso no muere, si no se queda atendiendo otras peticiones.

El tiempo ya lo subí para memoria editando el csf,pero claro,la ejecución por mucho que suba siempre hay procesos que superarán lo establecido. Por ejemplo,en lfd he ido subiendo hasta 7000 segundos y parecía todo ok hasta que llegan los avisos (muchos menos).
¿y si pongo /usr/bin/php en el csf.pignore,no será como ir a ciegas luego? Te refieres a esto lo de añadir php al whitelist,no?


Usar PHP APC no es cualquier cosa, si lo configuras mal, podria causarte problemas.

Tienes que elegir cierta cantidad de memoria para opcode tomando en cuenta el tamaño del CMS, en este caso WP, y deberia ser de al menos 30MB ~50MB por sitio.

Y necesitas revisar el uptime de la cache para ver que funcione correctamente, al igual que el radio hit/miss.
El archivo apc.php te sera util para configurar adecuadamente, y es una seccion de memoria para cada sitio, asi que tendras que revisar los sitios independientemente (por cuenta o usuario mas bien).

Pues instalé APC, hice un phpinfo para ver que estaba enabled y p.ej w3tc lo reconoció en uno de mis sitios. La cuestión es que no encuentro el apc.php en ninguna ruta,¿está comprimido o renombrado? Yo sé que lo tengo que mover a una ruta pública y ejecutarlo,pero no he visto nada en el server:sorrow:
 
El tiempo ya lo subí para memoria editando el csf,pero claro,la ejecución por mucho que suba siempre hay procesos que superarán lo establecido. Por ejemplo,en lfd he ido subiendo hasta 7000 segundos y parecía todo ok hasta que llegan los avisos (muchos menos).
¿y si pongo /usr/bin/php en el csf.pignore,no será como ir a ciegas luego? Te refieres a esto lo de añadir php al whitelist,no?




Pues instalé APC, hice un phpinfo para ver que estaba enabled y p.ej w3tc lo reconoció en uno de mis sitios. La cuestión es que no encuentro el apc.php en ninguna ruta,¿está comprimido o renombrado? Yo sé que lo tengo que mover a una ruta pública y ejecutarlo,pero no he visto nada en el server:sorrow:


Si mas o menos es eso, añadir PHP, es la única forma de que no te lleguen emails o bien deshabilitar los emails o crear un filtro para que vallan a otra carpeta, pero es mejor deshabilitar php.

Por lo demás el apc.php esta en /usr/local o share.

En ssh

cd /usr
find -name apache.php

Ahí saldrá la ruta.

Por lo que dice Enlace eliminado puse ajustar los valores de apc y de fastcgi para que tengan el mismo tiempo, el tiempo de expire y el que dura el proceso de php.
 
Pues instalé APC, hice un phpinfo para ver que estaba enabled y p.ej w3tc lo reconoció en uno de mis sitios. La cuestión es que no encuentro el apc.php en ninguna ruta,¿está comprimido o renombrado? Yo sé que lo tengo que mover a una ruta pública y ejecutarlo,pero no he visto nada en el server:sorrow:


En Debian/Ubuntu, esta en /usr/share/php/apc.php

Lo editas y le colocas una contraseña y usuario, y lo colocas en algun lugar publico.
 
Atrás
Arriba