Meer belasting probleme

[Snake]

Ok so ek het baie van die toets gedoen.

Oor 'n tydperk van 24 uur is my vrag styg steeds in die 30,00 se

'N herlaai fixes dit vir' n ander 24 uur.

As ek die mod afskakel Ek kry nie hierdie probleem.

Moet nie sê dat met mod gestremdes daar is minder verkeer, want dit is nie waar nie, stuur Google nog steeds dieselfde verkeer met mod ongeskik volgens my stats.

Verduidelik asseblief, las is ry my mal.

[tavenger5]

Klink soos bots is slaan die vertaalde bladsye wanneer die mod is. Jy moet kyk na die optimalisering van Apache of om 'n bediener met meer CPU krag. Is jy vboptimise of enige ander soort van cache meganisme, soos memcached?

[Snake]

Die feit is dat my forum 30,000 unieke per dag kry, as ek die mod-las onmiddellik deaktiveer, en bots en gebruikers wys steeds bladsye, so eis steeds bedienerkrag, dit is eenvoudig dat die vertoon van vertaalde bladsye 10x die hulpbronne gebruik as standaard vb bladsye van die normale databasis. Dit is swak geskrewe kode, en moet reggestel word! Die ander mods het dit nooit gedoen nie, net vbet, wens ek het nooit verander nie, maar om terug te gaan is nou te laat.

[moman]

Dit klink regtig asof jy op 'n onvoldoende versterk bediener. Ek is op 'n 8-core nehalem masjien (so ons kyk na 8 virtuele cores as gevolg van die HT, vir' n totaal van 16). Ek het ook uitgebrei geoptimaliseer hierdie masjien deur gebruik te maak van my eie tegnieke asook wysers van die mense by vbulletin.com.

vBET roep my vrag van ongeveer 2,5 tot 3,0-3,5, afhangende van die aantal gebruikers, en hierdie is natuurlik groei wat gebaseer is op die kas grootte. Maar ek dink nie dis te sleg nie, as my gelyktydige gebruikers wissel van 'n redelik hoë 800 tot' n selfs hoër 1200.

[vBET]

Hi Natuurlik vertaling moet n paar hulpbronne - daar is geen magie. Vertaal bladsy beteken dat die uitset tot gevolg hê en dit verander. As gevolg van die vertaling sal altyd langer neem as die normale bladsy.

Ek verstaan dat jy nie so gelukkig om meer server load, maar asseblief daarop let dat vBET hulpbronne is SLEGS VIR VERTALING neem. Vir normale bladsye voeg net vlae. So kom al hierdie bykomende belasting van bykomende verkeer te vertaal bladsye. As jy geskryf het jou verkeer het nie gaan af onmiddellik na die aanskakel van vBET (as jy het dit 'n rukkie, dan is dit sal afneem te skakel - glo my) en server load laer is - dit is duidelik - robots is steeds soek van URL's te vertaal bladsye, gebruikers is nog steeds bevinding in Google skakels na jou vertaalde bladsye. So jy het nog steeds dieselfde verkeer, maar nou onder vertaal skakels is eenvoudig gedupliseer inhoud - die normale bladsy wat nie vertaal. As jy wil bly met gestremde vBET ons sterk aanbeveel reël by te voeg in jou htaccess lêer wat redirect alle vertaalde bladsye normale een, anders kan jy los jou SEO as gevolg van gedupliseer inhoud.

Let asseblief daarop dat ons reeds beplan het om ander kasstelsels te ondersteun en ons vertaalalgoritmes is onmiddellik geoptimaliseer. Dit wil sê ons het net ontdek hoe drasties verminder PHP prestasie wanneer ons aan groot snare werk en ons het ons algoritme verander. Dit is reeds vrygestel in vBET 4.2.0 met bykomende konfigurasie opsies. En ons sal alle verbeterings ook na vBET 3.x skuif wat steeds ondersteun word

Ek verstaan dat in jou mening is ons kode is swak is. Ek weet nie wat jy baseer jou verwagtinge. Ons het die vinnigste vertaling mod vir vB - daar is niks wat werk beter nie. Vertaling sal 'n paar hulpbronne, en ons mod neem dit minder as enige ander. Jy kan sien hoe vinnig vBET kan werk op baie forums. As jy op jou bediener, dan oorweeg dit asseblief configuration of bediener hulpbronne toe te voeg. Jy sal nie 20 liter water in 10 liter emmer.

Ons bedink is: "Ons het baie om te verander". En daarom eksperimenteer ons, verander algoritmes, profilering en spandeer baie tyd op soek na oplossings wat minder hulpbronne benodig. Tog weet ons geen mod wat enige kompetisie vir vBET kan wees nie en daar is 'n paar ander vertaalmods. Ons het baie algoritmeveranderinge gemaak wat ons moes wegsteek omdat hulle nie gehelp het nie, tydens hierdie proses het ons ook baie verbeterings ontdek. U kan u indruk op u bedienerkwessies plaas, maar oorweeg dit asseblief dat u 'n beter oplossing het? Wat kan jy 'n wenk gee dat miskien vBET nie verkeerde oplossing is nie, aangesien jy aan duisende forums werk, miskien probeer jy net 20 liter water in 10 liter emmer sit. Tog - ons het baie om te verander en 'n groot TODO lys in optimalisering afdeling (ongeveer 70% om te eksperimenteer sal dit help of nie) En jy is 100% reg - ons kan dit beter te doen, sal ons en ons doen dit al die tyd Wag net totdat ons beweeg van alle verbeterings wat ons gemaak is tydens vBET4.x implementering

As ek kan gee jou 'n paar wenke - check hoe jy kan optimaliseer vBET: http://www.vbenterprisetranslator.co...rformance.html
Veral oorweeg aanskakel van sommige tale en blokkeer irrelevant bladsye deur robots.txt

Wat is die tyd van die reaksie vir vertaalde bladsye? Wat is jou CPU gebruik? Wat is jou geheue gebruik? As dit aanvaarbaar is, dan het jy niks om oor bekommerd te wees nie. Mense is dikwels bang deur die bediener belasting te verhoog en nie eens weet wat dit beteken. 10 keer meer server load nie NIE beteken 10 keer meer hulpbronne gebruik. Dit beteken net meer drade wag in die tou, wat is heeltemal normaal, aangesien nou jou drade het om te wag vir Google reaksie as sommige vertaling is nie Cached nog. So draad wag vir Google reaksie en dit neem geen CPU TE ALLE gedurende hierdie tyd. As gevolg van dat jou bediener belasting sal groter selfs as vBET kon geen hulpbronne nie (wat natuurlik nie moontlik is nie).

Oor die gekraak van jou bediener - dit is natuurlik jou bediener probleem. Dit gebeur van tyd tot tyd. Ek het 'n soortgelyke probleem op my server. Dit was veroorsaak deur sommige Apache-bug so een Apache draad groei en groei met die geheue gebruik totdat die hele geheue is ans bediener Cached. Slegs een draad optree soos dit - ander Apache drade was normaal. Ek het gespeel met Apache konfigurasie en probleem opgelos is. Ek dink dat Apache net 'n paar geheue lekkasie - soos ek dit onthou Ek sit laer waarde van die versoeke wat kan hou deur' n draad. Daar was ook ander veranderinge. Ek stel voor jou geheue gebruik te monitor en monitor dit vir 'n geruime tyd. Ook kan dit nuttig wees om die gemiddelde bedrag van die geheue wat gebruik word deur een Apache draad om seker te maak, het sommige berekeninge en toepaslike waarde van die maksimum-drade vir Apache te stel.

As jy nog vrae het kan jy net vra

[vBET]

Hey - ek het net op jou forum was dit vertaal ULTRA FAST ... So wat jy beweer oor en hoekom so kwaad houding oor vBET, wanneer jy van super-vinnige vertaling diens?

Oorweeg dit asseblief wat server load beteken. Die verstaan van die betekenis daarvan kan baie nuttig wees om te verstaan wat gebeur op die bediener en hoe dit kan verband hou met die drade wat wag in die ry nie, want jy het geen hulpbronne, maar wag vir die reaksie van ander bediener (Google in hierdie geval).

In my mening het jy 'n super-vinnige vertalings en jy het niks om oor bekommerd te wees nie

[tavenger5]

Hoeveel tale moet jy in staat gestel het? Hoeveel poste moet jy doen? Het jy vbseo en sitemap kragopwekker geïnstalleer? Hoeveel bots slaan die werf 'n dag?

[Snake]

Hi!

32 tale aangeskakel.

100,000 poste.

vbseo en sitemap geïnstalleer.

sitemap plugin sê 1000.000 bladsye gekruip 'n dag.


Die feit is, as ek die mod en die bediener, bot en gebruikers herlaai nog steeds slaan my bediener dieselfde as voorheen, dieselfde bladsye is nog in googles indeks en dus kry ek dieselfde verkeer aktief is of nie.

Die enigste verskil is dat met die mod afgeskakel die robotte en Google is die Engelse bladsy, ja, die verkeer is identies, is die enigste verskil dit is nie 'n vertaalde bladsy te sien, so die mods databasis kwessies te vermy.

Dit is duidelik dat as die dag vir my hierdie mod vrygestel is sonder behoorlike toetsing, en duidelik is die eienaar is nie geïnteresseerd om die kwessies aan te spreek.

Misluk.

[vBET]

Dit is duidelik dat as die dag vir my hierdie mod vrygestel is sonder behoorlike toetsing, en duidelik is die eienaar is nie geïnteresseerd om die kwessies aan te spreek.

Misluk.

As jy twyfel oor behoorlike toetsing ek stel voor om die geskiedenis van vBET na te gaan - dit is getoets deur honderde werklike forums voordat dit gevorder het tot betaalde weergawe

Oor die kwessie aan te spreek. Ek is jammer. Ek het verkeerdelik aangeneem dat jy te gee in die eerste reaksie is hierdie inligting, ek was duidelik dat ons die probleem aanspreek:

Let asseblief daarop dat ons reeds beplan het om ander kasstelsels te ondersteun en ons vertaalalgoritmes is onmiddellik geoptimaliseer. Dit wil sê ons het net ontdek hoe drasties verminder PHP prestasie wanneer ons aan groot snare werk en ons het ons algoritme verander. Dit is reeds vrygestel in vBET 4.2.0 met bykomende konfigurasie opsies. En ons sal alle verbeterings ook na vBET 3.x skuif wat steeds ondersteun word

...

Ons bedink is: "Ons het baie om te verander". En daarom eksperimenteer ons, verander algoritmes, profilering en spandeer baie tyd op soek na oplossings wat minder hulpbronne benodig. Tog weet ons geen mod wat enige kompetisie vir vBET kan wees nie en daar is 'n paar ander vertaalmods. Ons het baie algoritmeveranderinge gemaak wat ons moes wegsteek omdat hulle nie gehelp het nie, tydens hierdie proses het ons ook baie verbeterings ontdek. U kan u indruk op u bedienerkwessies plaas, maar oorweeg dit asseblief dat u 'n beter oplossing het? Wat kan jy 'n wenk gee dat miskien vBET nie verkeerde oplossing is nie, aangesien jy aan duisende forums werk, miskien probeer jy net 20 liter water in 10 liter emmer sit. Tog - ons het baie om te verander en 'n groot TODO lys in optimalisering afdeling (ongeveer 70% om te eksperimenteer sal dit help of nie) En jy is 100% reg - ons kan dit beter te doen, sal ons en ons doen dit al die tyd Wag net totdat ons beweeg van alle verbeterings wat ons gemaak is tydens vBET4.x implementering

As ek kan gee jou 'n paar wenke - check hoe jy kan optimaliseer vBET: http://www.vbenterprisetranslator.co...rformance.html
Veral oorweeg aanskakel van sommige tale en blokkeer irrelevant bladsye deur robots.txt

Ek is ten volle verantwoordelik vir hierdie misverstand. Nogmaals baie jammer. Vertel ons asseblief, op watter manier ons moet jou vertel dat ons die hele tyd vBET verbeter, en hoe ons jou weer kan verseker dat vBET3.x nog 'n prestasieverbeterings sal hê, om jou duidelik te maak dat ons die probleem aanspreek? Ons sal altyd graag ons manier van kommunikasie met kliënte verbeter

[Snake]

Michael, jy is verkeerd, hierdie las is nie veroorsaak deur 'n toename in die verkeer, is dit veroorsaak is deur die lees en skryf van vertalings aan MySQL.

As vBulletin span kan lees en skryf aan MySQL met lae lading why cant jy?

Swak kode my vriend.