Site lent après effacement du cache

[tavenger5]

J'ai vécu et mis en œuvre toutes les astuces d'optimisation possibles que je peux trouver. Cela inclut nginx comme un proxy pour apache, vbOptimize avec memcached, et toutes les procédures d'optimisation régulière vbulletin.

Je travaille avec deux serveurs Quad core avec 12 et *** du bélier, et des disques SAS 15k en raid. Donc, en d'autres termes, les serveurs ont assez de puissance pour traiter tout.

Le site principal commence à ralentir à droite après le cache vBET est effacé tous les 15 jours. (La base de données devient un peu plus de *** après cette période de 15 jours)> 500k pages par jour sont en cours d'exploration par les moteurs de recherche.

Est-ce que je peux faire pour modifier apache pour les poignées de ces demandes mieux? Ce sont mes paramètres actuels de apache:
à partir httpd-mpm.conf
# MPM prefork

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

De httpd-default.conf:

Timeout 150
KeepAlive On
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

L'astuce est - si vous n'avez pas vraiment d', alors ne pas utiliser la stratégie de compensation dernier. Je sais qu'il ya si - Avez-vous vérifié les stratégies de compensation des autres? Autre ne sera pas effacer le cache de l'ensemble et prendra davantage de ressources à partir de l'autre côté clair.

Suivant vBET 3.x libération peut vous aider - nous allons ajouter de nouveaux paramètres de performance de pointe pour les pages de vraiment grand. Nous avons aussi découvert goulot d'étranglement à la traduction des liens. En ce moment nous avons mis en place une solution pour VB Friendly URLs dans vBET4.x (pas encore sorti) et nous allons essayer de l'adopter aussi pour vBSEO. Si nous réussissons, nous le déplacer aussi à vBET 3.x Le problème est que vBSEO demande pour les liens un par un et cela produit des dizaines de requêtes Google. Comme je l'écrivais déjà mis en œuvre, nous solution pour vB frinedly URL - nous avons fait la traduction en retard. Problème avec vBSEO est que cela fonctionne en dehors vB, après traduction arrive et aussi ne disent pas ne besoins url pour vérifier l'exactitude d'une réelle
ou de les mettre dans la production.
Lot de détails - peu de temps, nous savons un goulet d'étranglement qui se produit seulement lorsque le cache n'est pas rempli et nous travaillons déjà sur cette question.

Donc en ce moment je peux juste vous conseiller de jouer avec les stratégies de compensation et les paramètres de compensation d'autres. Pour d'autres stratégies:
- Si la compensation d'une table de cache n'est pas tuer votre serveur, puis définir plus "Cache compensation timelap '- votre serveur aura un souffle entre les clairières
- Analise votre trafic du forum et vérifier si elle est inférieure - l'exécution de compensation changement à ce moment
- Mettre en bas du cache TTL - petites tables seront effacées si la compensation se prendra moins de ressources. Autre côté - serveur devra demander à Google plus souvent pour des traductions.
- EXPERIMENTAL: Set "suppression rapide avec des tables locales d'optimiser« ouvert / Includes / vbenterprisetranslator_functions.php et commenter il ya trois lignes de code avec 'OPTIMIZE TABLE LOCALE». Cela rendra la suppression très rapide, sans mise à niveau des index. Note: Les indices vont croître, de sorte que vous devrez exécuter la requête manuellement - à savoir le vérifier une fois par semaine. Si elle va travailler pour vous, nous mettrons en œuvre cette nouvelle stratégie, où les indices seront réorganisées pas tous les jours.

[tavenger5]

Oui sur vBSEO.

J'utilise suppression normale en ce moment et il ne semble pas prendre trop de temps pour obtenir des choses effacées. Avec la suppression locale rapides sont les indices laissés dans le tact, et les indices de suppression normale sont effacés? Est-ce que avoir des indices anciennes ont tout avantage si elles ne sont pas optimisés?

Les choses ne semblent ralentir quand il ya beaucoup de trafic sur le site et le cache est reconstruit. Je suis sûr que ce n'est parce que les processus Apache ne sont pas fermés aussi vite qu'ils le feriez normalement (puisque les données sont demandées à partir de Google).

Il est bon d'entendre que la prochaine version permettra d'améliorer la vitesse à nouveau. J'étais juste s'assurer qu'il n'y avait pas autre chose que je pouvais faire avec apache peaufinage.

[vBET]

Si vous utilisez la compensation normale, puis oublié mes indications. Je pensais que vous utilisez la dernière stratégie et enlever le cache tout entier. Désolé - incompréhension Il suffit de le laisser tel qu'il est.

De telle manière que je peux conseiller de mettre plus de cache TTL. Moins de données sera supprimée à chaque fois, donc moins de données seront à récupérer.


Qu'est-ce que vous aussi puissiez faire est de s'assurer que votre serveur ne tient pas les requêtes sortantes. Nous avons découvert que certains serveurs se comportent comme cela si de nombreuses requêtes sortantes vont même serveur. Parce que 100 demandes peut prendre du temps 1000 x plus de 1 demande (théoriquement devraient prendre le temps de 100 x plus). Il peut y avoir des pare-feu, question de sécurité du serveur. Bien sûr, il peut être que Google met quelques petits «punition» dans un tel cas. Donc, si vous pouvez trouver quelque chose dans ce domaine - il peut aider. Si ce n'est pas s'il vous plaît attendez améliorations