View Full Version: Opgelost Meer belasting problemen
Ok dus ik hebben gedaan veel testen.
Over een periode van 24 uur mijn belasting stijgt gestaag in de 30.00 's
Een herstart server fixes voor een ander 24 uur.
Als ik schakel de mod krijg ik niet dit probleem.
Zeg niet dat met de mod met een handicap is er minder verkeer als dat niet waar is, google stuurt nog steeds dezelfde verkeer met mod met een handicap volgens mijn stats.
Gelieve uit te leggen, belasting maakt me gek.
Klinkt als bots zijn het raken van de vertaalde pagina's als de mod is ingeschakeld. Je moet kijken naar het optimaliseren van apache of het krijgen van een server met meer cpu power. Bent u het lopen vboptimise of enige vorm van caching mechanisme, zoals memcached?
Het feit is mijn forum krijgt 30.000 uniques een dag, als ik schakel de mod belasting daalt direct, en bots en gebruikers vertonen nog steeds pagina's zijn dus nog steeds veeleisend server macht, het is gewoon dat het tonen van vertaalde pagina's 10x gebruik maken van de middelen dan standaard vb's van de normale database. Het is slecht geschreven code, en moet worden vastgesteld! De andere mods nooit gedaan, maar vbet, wou dat ik nooit veranderd, maar terug te gaan is nu te laat. : Mad:
Het klinkt echt alsof je draait op een underpowered server. Ik ben op een 8-core Nehalem-machine (dus we zijn op zoek naar acht virtuele cores meer als gevolg van de HT, voor een totaal van 16). Ik heb ook uitgebreid geoptimaliseerd deze machine met behulp van mijn eigen technieken en aanwijzingen van de mensen van vbulletin.com.
vBET verhoogt mijn lading van ongeveer 2,5 tot 3.0-3.5, afhankelijk van het aantal gebruikers, en dit uiteraard groeit op basis van de cache grootte. Maar ik denk niet dat het te slecht, omdat mijn gelijktijdige gebruikers lopen uiteen van een vrij hoge 800 tot een nog hogere 1200.
Hi:) Natuurlijk vertaling moeten sommige middelen - er is geen magie. Vertalen pagina betekent nemen uitgang resultaat en veranderen. Door die vertaling zal altijd langer duren dan normaal pagina.
Ik begrijp dat u niet al te blij met meer belasting van de server, maar let er op dat vBET is het nemen van slechts middelen voor de vertaling. Voor de normale pagina's het voegt alleen maar vlaggen. Dus al deze extra belasting komt van extra verkeer naar vertaalde pagina's. Zoals u schreef uw verkeer niet meteen naar beneden na het uitschakelen van vBET (als je het een tijdje, dan zal afnemen na het uitschakelen - trust me) en de belasting van de server is lager - het is duidelijk - robots zijn nog steeds kruipen URL's naar vertaalde pagina's, gebruikers zijn nog steeds te vinden in Google links naar uw vertaalde pagina's. U heeft dus nog hetzelfde het verkeer, maar nu onder vertaald links is gewoon gedupliceerd inhoud - normale pagina die niet is vertaald. Als u wilt verblijven met een handicap vBET raden we aan regel toe te voegen in je. Htaccess bestand waarin alle vertaalde pagina's zullen doorverwijzen naar een normaal, anders kun je verliezen als gevolg van uw SEO gedupliceerd inhoud.
Houdt u er rekening mee dat we al hebben gepland ter ondersteuning van andere cache-systemen en onze vertaling algoritmen zijn direct geoptimaliseerd. Wil zeggen dat we net ontdekt hoe drastisch afneemt PHP prestaties bij het werken op grote strijkers en we ons algoritme aangepast. Het is al uitgebracht in vBET 4.2.0 met extra configuratie-opties. En we zullen ook u alle verbeteringen aan vBET 3.x die nog steeds wordt ondersteund:)
Ik begrijp dat naar uw mening onze code zwak is. Ik weet niet op wat u baseert uw verwachtingen. We hebben snelst vertaling mod voor VB - er is niets wat werkt beter. Vertaling zal wat middelen en onze mod duurt het minder dan een ander. U kunt zien hoe snel vBET kan werken op vele forums. Als u problemen op uw server, dan kunt u overwegen wijzigingen in de configuratie of het toevoegen van resources van de server. Je zal niet zetten 20 liter water in 10 liter emmer.
Onze bedenken is: "We hebben heel wat te veranderen". En dat is waarom we experimenteren, veranderende algoritmen, profilering en besteden veel tijd aan het zoeken naar oplossingen die vereist minder middelen. Nog steeds weten we geen mod dat kan geen concurrentie te vBET worden en er zijn enkele andere vertaling mods. We hebben heel veel algoritme veranderingen die we moesten trow weg omdat ze niet helpen, tijdens dit proces hebben we ook ontdekt veel verbeteringen. U kunt uw indruk baseren op je server problemen, maar overweeg dan heb je een betere oplossing? Wat zou je een hint geven dat misschien vBET niet verkeerd oplossing aangezien werkt op duizenden fora, misschien heb je gewoon proberen om 20 liter water in 10 liter emmer. Nog steeds - we hebben veel te veranderen en grote TODO lijst in optimalisatie deel (ongeveer 70% om te experimenteren zal het helpen of niet):) En je bent 100% goed - we kunnen beter doen, zullen wij en we doen het allemaal de tijd:) Wacht maar tot we verhuizen alle verbeteringen die we gemaakt tijdens vBET4.x uitvoering:)
Als ik kan u enkele tips - controleer hoe je kunt vBET te optimaliseren: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html
Vooral beste uitschakelen enkele talen en het blokkeren van irrelevante pagina's door robots.txt
Wat is tijd van de respons van de vertaalde pagina's? Wat is je CPU-gebruik? Wat is je geheugengebruik? Of het aanvaardbaar is dan moet je geen zorgen te maken. Mensen zijn vaak bang door het verhogen van de server load en zelfs niet weten wat doet het betekent. 10 keer meer belasting van de server is NIET middelen die worden gebruikt 10 keer meer middelen. Het is gewoon betekent dat er meer draden zijn wachten in de wachtrij, wat is volkomen normaal, want op dit moment uw vragen te wachten op Google reactie als sommige vertaling is niet in de cache nog niet. Dus thread wacht op Google reactie en het duurt geen CPU OP ALLE gedurende deze tijd. Vanwege dat uw server load zal groter zijn, zelfs als vBET kon geen middelen te nemen op alle (wat natuurlijk niet mogelijk).
Over het crashen van uw server - het is uiteraard uw server probleem. Het gebeurt regelmatig. Ik had soortgelijk probleem op mijn server. Het werd veroorzaakt door een Apache-bug, zodat een Apache thread groeide en groeide met geheugengebruik tot hele geheugen was verteerd ans-server in de cache. Slechts een thread zich gedraagt als dat - andere Apache discussies die was normaal. Ik speelde met Apache configuratie en probleem is opgelost. Ik denk dat Apache gewoon wat geheugen lekkage had - zoals ik herinner ik lagere waarde van de verzoeken die kan worden ingedrukt door een draad. Er waren ook andere wijzigingen. Ik stel voor om uw geheugengebruik te controleren en het monitor voor bepaalde tijd. Ook kan het nuttig zijn om de gemiddelde hoeveelheid geheugen die wordt gebruikt door een Apache thread bekijken, maakte een aantal berekeningen en juiste waarde van max threads voor Apache in te stellen.
Als u nog meer vragen hebt just ask:)
Hey - ik was gewoon op je forum het vertaalt ULTRA FAST ... Dus wat je beweert over en waarom zo boos over de houding vBET, als je super snelle vertaaldienst? ...
Gelieve na te denken welke server belasting betekent. Inzicht in de betekenis ervan kan zeer nuttig zijn om te begrijpen wat er gebeurt op de server en hoe het kan worden gerelateerd aan onderwerpen die het waard zijn in de rij niet omdat je geen middelen, maar wachten op reactie van andere server (Google in dit geval).
Naar mijn mening heb je super snelle vertalingen en je hebt geen zorgen te maken over:)
Ik heb sites van gebouw 10 jaar, ik ben me volledig bewust 10x lading niet 10x resources betekenen, stop behandelen me als een idioot en lepel voeden me onzin. De koude feiten zijn met deze mod versus de andere gratis mod van uw lading is mega. En op piekmomenten mijn site is nu traag en reageert niet. Ja, pagina's te vertalen snel daluren, maar tegen een kostprijs van een trage server later op de dag. Ik heb een quad core, raid 15k SAS-server, die geoptimaliseerd is prima, maar 0,50 voor een hele dag lang voordat dit met grote verkeer. Het is de VBET code die belasting toevoegt en maakt de server traag op piekmomenten, het is een feit, het is niet toename van het verkeer, ik heb dezelfde verkeers-en bots had en de server omgegaan prima, het is de vertaling product. Periode. Schiet op en bevestig het, ik echt niet willen naar een andere 300 pond te betalen per maand voor een server upgrade alleen maar om een MOD lol run.
Hoeveel talen heb je ingeschakeld? Hoeveel berichten heb je? Heeft u vBSEO en sitemap generator geïnstalleerd? Hoeveel bots zijn het raken van de site een dag?
Hi!
32 talen ingeschakeld.
100.000 berichten.
vBSEO en sitemap geïnstalleerd.
sitemap plugin zegt 1000.000 pagina's kroop een dag.
Het feit is, als ik schakel de mod en herstart de server, bot en gebruikers zijn nog steeds mijn server het raken van de dezelfde als voorheen, dezelfde pagina's zijn in nog in googles index en dus krijg ik hetzelfde verkeer is ingeschakeld of niet.
Het enige verschil is dat met de mod met een handicap de bots en Google zoekers krijgen de engels pagina, zodat,, het verkeer identiek is, is het enige verschil dat ze niet zien van een vertaalde pagina, dus het vermijden van mods database issues.
Het is duidelijk als de dag voor mij deze mod is vrijgegeven zonder de juiste testen, en duidelijk de eigenaar is niet geïnteresseerd in de aanpak van de problemen.
Fail.
Michael, je fout bent, wordt deze belasting niet wordt veroorzaakt door een toename van het verkeer, wordt het veroorzaakt door het lezen en schrijven vertalingen mysql.
Als vBulletin team kan lezen en schrijven naar MySQL met een lage belasting waarom cant u?
Slechte code mijn vriend.
Ik heb sites van gebouw 10 jaar, ik ben me volledig bewust 10x lading niet 10x resources betekenen, stop behandelen me als een idioot en lepel voeden me onzin. De koude feiten zijn met deze mod versus de andere gratis mod van uw lading is mega. En op piekmomenten mijn site is nu traag en reageert niet. Ja, pagina's te vertalen snel daluren, maar tegen een kostprijs van een trage server later op de dag. Ik heb een quad core, raid 15k SAS-server, die geoptimaliseerd is prima, maar 0,50 voor een hele dag lang voordat dit met grote verkeer. Het is de VBET code die belasting toevoegt en maakt de server traag op piekmomenten, het is een feit, het is niet toename van het verkeer, ik heb dezelfde verkeers-en bots had en de server omgegaan prima, het is de vertaling product. Periode. Schiet op en bevestig het, ik echt niet willen naar een andere 300 pond te betalen per maand voor een server upgrade alleen maar om een MOD lol run.
Ik begrijp dat u al bekend was met informatie over belasting van de server die ik je gaf. Houdt u er rekening mee dat ik geen kennis over hoe geavanceerd is elk van de duizenden onze gebruikers en elke keer zal ik kont volledige informatie te geven als het kan nuttig zijn. Het doet er niet betekent dat ik je behandelen als idioot - het betekent dat ik zorg over zodat u informatie die nuttig kan zijn voor u en evaluatie van uw server conditie. Gelieve punt mij de andere gratis mod die je het over hebt ik graag zal enige vergelijking te maken:) Ook wanneer u bent vrij om de beste oplossing te kiezen voor je.
Ik controleerde het forum opnieuw en opnieuw lijkt te reageren zeer snel. Geef me de beste tijd om te kunnen waarnemer wat je schrijft over je trage reacties op piekuren.
Als u wilt controleren hoe uw verkeer veranderd door vBET - gelieve te genereren sommige rapport dat zal u tonen al het verkeer naar vertaalde pagina's - dit is wat je dankzij verdiend aan vBET.
Je hebt volkomen gelijk dat vertalingen extra middelen nodig heeft - er is geen andere manier en je zult nooit vinden product dat uw site zal vertalen zonder enige kosten. Zoals ik al zei de meeste tijd nodig te wachten op Google vertaling wanneer het niet in de cache, en gedurende deze tijd uw discussies moeten wachten op antwoord wat hebben grootste impact op de belasting van de server. U kunt de grotere cache tijd om te leven - dan vaak nodig vertalingen worden al in de cache. Maar voor het niet in de cache vertalingen een product zullen moeten wachten voor de vertaling. Er is geen andere manier.
Houdt u er rekening mee dat denkt moet worden gebroken om te kunnen repareren.
Zoals ik al schreef je, we voortdurend verbeteren vBET prestaties. En ik al schreef je, dat we klaar prestatieverbeteringen die nu op de beta-fase in vBET4.x hebben. Vandaag zullen we vrijgeven nieuwe vBET4.x versie met extra prestatieverbeteringen. En wanneer bugs voor die (indien aanwezig) zullen worden gecorrigeerd we zullen die verbeteringen verhuizen naar vBET3.x Het is niet nodig om te duwen.
Ook niemand dwingt je om een andere betaalde 300 pond per maand voor een server - je maakt je eigen beslissingen en je hebt veel opties hier. Zoals een daling van het aantal ondersteunde talen, of zelfs te schakelen op andere producten die u noemde is veel beter. We helemaal begrijpen dat oplossingen die u gebruikt moet passen aan uw behoeften en mogelijkheden. We zijn blij om onze klanten beter en beter product. En we zijn ervan bewust dat in situaties waarin verzoek moet wachten op antwoord formulier een andere server uw server load zal groter zijn, ongeacht welke oplossingen we zullen gebruiken. We zullen blij zijn als je verblijf bij ons product en configureren om yo passen bij uw mogelijkheden. En we geven u graag een hand in dit gebied:)
Houdt u er rekening mee dat we net nieuwe oplossing gaf om te integreren met Sitemap Generator. Als u geïntegreerd - kunt u hier nieuwe integratie instructies:
Het verhoogt dramatisch snelheid van de sitemap generatie (op ons forum meer dan 12 keer).
Het is duidelijk als de dag voor mij deze mod is vrijgegeven zonder de juiste testen, en duidelijk de eigenaar is niet geïnteresseerd in de aanpak van de problemen.
Fail.
Als u twijfelt over de juiste testen Ik stel voor om de geschiedenis van vBET check - het werd getest door honderden echte forums voordat hij gevorderd tot betaalde versie:)
Over de aanpak van het probleem. Het spijt me. Ik heb ten onrechte aangenomen dat het geven van je in de eerste reactie van deze informatie, ik was duidelijk dat we het probleem aanpakken:
Houdt u er rekening mee dat we al hebben gepland ter ondersteuning van andere cache-systemen en onze vertaling algoritmen zijn direct geoptimaliseerd. Wil zeggen dat we net ontdekt hoe drastisch afneemt PHP prestaties bij het werken op grote strijkers en we ons algoritme aangepast. Het is al uitgebracht in vBET 4.2.0 met extra configuratie-opties. En we zullen ook u alle verbeteringen aan vBET 3.x die nog steeds wordt ondersteund:)
...
Onze bedenken is: "We hebben heel wat te veranderen". En dat is waarom we experimenteren, veranderende algoritmen, profilering en besteden veel tijd aan het zoeken naar oplossingen die vereist minder middelen. Nog steeds weten we geen mod dat kan geen concurrentie te vBET worden en er zijn enkele andere vertaling mods. We hebben heel veel algoritme veranderingen die we moesten trow weg omdat ze niet helpen, tijdens dit proces hebben we ook ontdekt veel verbeteringen. U kunt uw indruk baseren op je server problemen, maar overweeg dan heb je een betere oplossing? Wat zou je een hint geven dat misschien vBET niet verkeerd oplossing aangezien werkt op duizenden fora, misschien heb je gewoon proberen om 20 liter water in 10 liter emmer. Nog steeds - we hebben veel te veranderen en grote TODO lijst in optimalisatie deel (ongeveer 70% om te experimenteren zal het helpen of niet):) En je bent 100% goed - we kunnen beter doen, zullen wij en we doen het allemaal de tijd:) Wacht maar tot we verhuizen alle verbeteringen die we gemaakt tijdens vBET4.x uitvoering:)
Als ik kan u enkele tips - controleer hoe je kunt vBET te optimaliseren: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html
Vooral beste uitschakelen enkele talen en het blokkeren van irrelevante pagina's door robots.txt
Ik voel me volledig verantwoordelijk voor dit misverstand. Nogmaals erg jammer. Laat ons weten, welke kant moeten we u vertellen dat we vBET het verbeteren van de hele tijd, en hoe kunnen we weer u verzekeren dat vBET3.x weer een performance verbeteringen zijn, om je duidelijk dat we het probleem aanpakken? Wij zullen altijd graag verbeteren van onze manier van communiceren met de klant:)
Michael, je fout bent, wordt deze belasting niet wordt veroorzaakt door een toename van het verkeer, wordt het veroorzaakt door het lezen en schrijven vertalingen mysql.
Als vBulletin team kan lezen en schrijven naar MySQL met een lage belasting waarom cant u?
Slechte code mijn vriend.
Je was al opgemerkt dat we gepland hebben ondersteunen van cache-systemen (file en bestaande motoren). Overweeg dan wat zijn je intenties in deze discussie en doet het gaat in de goede richting op tournee server toestand te verbeteren - als is het nog steeds het punt.
Uw vraag gaat ervan uit dat belasting wordt veroorzaakt door de communicatie met mysql. Kunt u ons de bron van deze diagnose? Wij zullen graag bestuderen:)
Ik had hetzelfde probleem, verbreken overbelasting. Tenslotte heb ik uitgeschakeld VBET van mijn forum en alles is normaal nu. :)
Ik had hetzelfde probleem, verbreken overbelasting. Tenslotte heb ik uitgeschakeld VBET van mijn forum en alles is normaal nu. :)
Welke versie u gebruikt? Please update naar de laatste versie - we grote performance verbeteringen. Veel gebruikers schreven hun dank uitgesproken voor dat het zien van groot verschil - vooral in de server load gebied:)
EDITED:
Ik heb net gecontroleerd uw forum en vBET is er aan het werk - dan niet schrijven van valse verklaringen over vBET conditie.
Automatic Translations (Powered by Google, Microsoft®,
Yandex, SDL Language Cloud, IBM Watson and Apertium):
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.
