Místo pomalé po vyrovnávací zúčtování

[tavenger5]

Prošel jsem, a provedla všechny možné triky, optimalizace najdu. To zahrnuje nginx jako proxy server Apache, vbOptimize s memcached a všechny běžné postupy vBulletin optimalizace.

Pracuji s dvěma dual quad core procesor servery s 12 a *** RAM a 15K SAS disky v RAID. Takže jinými slovy, že servery mají dostatek energie ke zpracování všechno.

Hlavní stránka začíná pomalu hned po vyrovnávací vBET je vymazána každých 15 dní. (Databáze se dostane do více než *** Po uplynutí této lhůty 15 dnů)> 500k stránek denně jsou procházeny vyhledávači.

Je něco, co mohu udělat, vylepšit Apache zpracovává tyto požadavky lépe? To jsou moje současné nastavení apache:
z httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

Z httpd-default.conf:

Časový limit 150
Na KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName off

[vBET]

Trik je v tom - pokud nemáte opravdu nutné, pak nepoužívejte posledního zúčtování strategii. Vím, že je jestliže - Jste zkontrolovat ostatní zúčtování strategie? Ostatní není jasné celou cache a bude trvat více zdrojů jasné, z druhé strany.

Další vBET 3.x verze vám mohou pomoci - budeme přidávat nové pokročilé výkonnostní parametry pro opravdu velké stránky. Také jsme objevili problémům s překladem odkazů. V tuto chvíli máme implementované řešení pro VB Friendly URL v vBET4.x (ne povolený zatím) a budeme se snažit přijmout to i vBSEO. Pokud se nám podaří se bude pohybovat také na vBET 3.x Problém je, že požádá o vBSEO odkazy jeden po druhém, a to vytváří desítky žádostí Google. Jak jsem psal už implementovaného řešení pro VB URL Frinedly - jsme zpoždění překladu. Problém s vBSEO je, že to funguje mimo VB, po přenosu se děje, a také neříkají, se musí adresa URL pro kontrolu správnosti skutečně jedno
nebo dát do výstupu.
Mnoho detailů - brzy jsme poznali překážkou, která se stane pouze tehdy, když vyrovnávací paměť není naplněna a my se již pracuje na toto téma.

Takže v tuto chvíli mohu jen poradit, abyste si s zúčtování strategií a dalších parametrů zúčtování. Pro jiné strategie:
- Pokud vymazání vyrovnávací paměti jednoho stolu nebude zabíjet na serveru, pak nastavit větší "Cache zúčtování timelap '- server bude mít dech mezi průseky
- Analise fórum provoz a kontrolu, pokud je to méně - změna provedení zúčtování této doby
- Stanovit nižší vyrovnávací TTL - menší tabulky budou prázdná, takže zúčtování se bude méně prostředků. Druhé straně - server bude muset požádat Google častěji na překlady.
- EXPERIMENTÁLNÍ: Nastavení "rychlé odstranění lokální optimalizaci tabulek s" otevřeným / Includes / vbenterprisetranslator_functions.php a komentář se 3 řádky kódu "OPTIMIZE místní tabulky". To bude velmi rychlé smazání bez indexů upgrade. Poznámka: indexy poroste, takže budete muset provést dotaz ručně - tj. kontrola jednou za týden. Pokud to bude pracovat pro vás budeme implementovat novou strategii, kde se indexy reorganizovány ne každý den.

[tavenger5]

Ano, na vbSEO.

Já používám normální odstranění v tuto chvíli a nezdá se, že trvá příliš dlouho, aby se věci vymazány. S rychlým místním odstranění jsou indexy vlevo v platnosti a normální odstranění indexy jsou smazány? Bude mít starý indexy mají nějaké výhody, pokud nejsou optimální?

Věci se zdá, že zpomalí, když je tu velký provoz na těchto stránkách a cache je přestavěn. Jsem si jist, že to je proto, že apache procesy nejsou uzavřeny tak rychle, jak se běžně dostanou (protože data jsou požadována od Google).

Je dobré slyšet, že příští verze bude zlepšit rychlost znovu. Jen jsem se ujistit, že nebylo něco, co bych mohl udělat s laděním Apache.

[vBET]

Pokud používáte normální zúčtování pak zapomněl na mé rady. Myslel jsem, že používáte poslední strategie a odstranit celou cache. Omlouváme se - nedorozumění Nech to jak to je.

Takovým způsobem, mohu poradit nastavit větší Cache TTL. Méně dat budou odstraněny pokaždé, tak méně dat bude zotavovat.


Co si také můžete udělat, je ujistit, že váš server není drží odchozí požadavky. Zjistili jsme, že některé servery se chovají takhle, pokud mnoha odchozí požadavky budou na stejném serveru. Vzhledem k tomu, 100 žádostí může mít 1000 x déle než 1 žádost (teoreticky by měl 100 x více času). Může to být nějaký firewall, server bezpečnostní problém. Samozřejmě to může být, že Google staví nějaké malé "trest" v tomto případě. Takže pokud si najdete něco, co v této oblasti - to může pomoci. Pokud ne, prosím počkejte na zlepšení