Sitio lento después de vaciar la caché

[tavenger5]

He pasado por e implementado todos los trucos de optimización posible que pueda encontrar. Esto incluye nginx como proxy para apache, vbOptimize con memcached, y todos los procedimientos regulares de optimización de vbulletin.

Estoy trabajando con dos servidores de cuádruple procesador de doble núcleo con 12 y *** de RAM y 15K SAS en raid. Por lo tanto, en otras palabras, los servidores tienen el poder suficiente para procesar todo.

El sitio principal empieza a disminuir inmediatamente después de la caché de VBET se borra cada 15 días. (La base de datos llega a poco más de *** después de este plazo de 15 días)> 500k páginas al día se están rastreando los motores de búsqueda.

¿Hay algo que pueda hacer para modificar Apache para que se encarga de estas peticiones mejor? Estos son mis valores actuales de apache:
de httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000
Desde httpd-default.conf:

Tiempo de espera 150
El KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Déjame adivinar - que ha Matías y gran cantidad de enlaces en la página principal - que tengo razón? ;)

El truco es - si usted realmente no tiene que hacerlo, no utilice la estrategia de compensación pasado. Yo sé que hay si - se ha marcado otras estrategias de compensación? Otros no se vacía la caché entera, y tenga más recursos para eliminar desde el otro lado.

Siguiente VBET liberación 3.x puede ayudarle - vamos a añadir nuevos parámetros de rendimiento avanzado de páginas muy grande. También descubrimos cuello de botella con la traducción de vínculos. En este momento hemos puesto en marcha una solución para las direcciones URL vB solteros en vBET4.x (no publicado aún) y vamos a tratar de adoptar también para Matías. Si lo conseguimos tendremos que mover también a VBET 3.x La cuestión es que Matías le pregunta para los enlaces de uno en uno, y esto produce docenas de solicitudes de Google. Como he escrito que ya implementó la solución para VB URLs Frinedly - hicimos la traducción retraso. Problema con Matías es que trabaja fuera de BB, después de la traducción que pasa y que además no se necesita decir url para comprobar la corrección de un real
o para ponerlo en producción.
Gran cantidad de detalles -, poco se sabe un cuello de botella que se produce sólo cuando la caché no está lleno y ya estamos trabajando en este tema.

Así que en este momento sólo puedo aconsejarle a jugar con las estrategias de compensación y otros parámetros de compensación. Para otras estrategias:
- Si la limpieza de una tabla de la caché no está matando a su servidor, a continuación, establecer más grande "Limpiando timelap '- el servidor se respira entre los claros
- Analise el tráfico de su foro y ver cuando es menor - Ejecución claro cambio en este momento
- Establecer menor caché TTL - tamaño de las tablas se borrará tan claro en sí tendrá menos recursos. Otro lado - el servidor tendrá que pedir a Google con más frecuencia para las traducciones.
- EXPERIMENTAL: 'Quick eliminación local con mesas optimizar "conjunto abierto / includes / vbenterprisetranslator_functions.php y comentarios hay tres líneas de código con' OPTIMIZE TABLE locales. Esto hará que la eliminación muy rápido, sin actualizar los índices. NOTA: Los índices de crecer, por lo que tendrá que ejecutar la consulta manualmente - es decir, comprobar una vez por semana. Si va a trabajar para que vamos a implementar la nueva estrategia, donde los índices no se va a reorganizar todos los días.

[tavenger5]

Sí a Matías.

Estoy usando la eliminación normal en el momento y no parece tener demasiado tiempo para hacer las cosas despejado. Con la eliminación rápida locales son los índices de la izquierda en el tacto, y los índices de eliminación normal, se borran? ¿El tener índices de edad tienen ningún beneficio si no se han optimizado?

Las cosas se parecen más lento cuando hay mucho tráfico en el sitio y la memoria caché está siendo reconstruida. Estoy seguro de que esto se debe a los procesos de apache no se cierran tan rápido como lo haría normalmente (ya que los datos que se solicitan de google).

Es bueno saber que la próxima versión se mejora la velocidad de nuevo. Yo era simplemente asegurarse de que no había nada más que pudiera hacer con apache ajustes.

[vBET]

Si está utilizando limpieza normal, entonces se olvidó de mis sugerencias. Pensé que usted está utilizando la última estrategia y eliminar la caché entera. Lo sentimos - malentendido:) Sólo tienes que dejarlo como está.

De tal manera que pueda asesorar al conjunto mayor caché TTL. Menos de datos serán eliminados cada vez, así que menos datos se recuperar.
Como he escrito ya hemos encontrado un cuello de botella con Matías + vaciar la memoria caché, y estamos trabajando en ello:)

Lo que también se puede hacer es asegurarse de que su servidor no está llevando a cabo solicitudes de salida. Hemos descubierto que algunos servidores se comportan como si este número de solicitudes de salida van a un mismo servidor. Debido a que 100 solicitudes puede tomar tiempo x 1000 más de una solicitud (en teoría deberían tomarse el tiempo 100 veces más). Puede ser un servidor de seguridad, tema de la seguridad del servidor. Por supuesto, puede ser que Google pone un poco pequeña "castigo" en ese caso. Así que si usted puede encontrar algo en este campo - que pueden ayudar. Si no es así por favor espere para mejorar:)