Uwchraddio ar ôl broblem llwyth gweinydd![]()
Uwchraddio ar ôl broblem llwyth gweinydd![]()
Oes gan unrhyw un unrhyw syniad pa mor fawr y gallai'r cache ffeil ei gael cyn iddo gael effaith negyddol ar berfformiad?
Cronfa Ddata cache cyfieithiadau caches yn unig. Ddim yn cynnwys HTML gyfan. Felly, pan fydd rhai dudalen cyfieithu yn cael ei gynhyrchu, yna dudalen cyntaf arferol yn cael ei gynhyrchu ac ar ôl ei fod yn parsed a chyfieithu. Yn ystod cache DB cyfieithu yn cael ei ddefnyddio a brawddegau cyfieithu yn cael eu cymryd oddi yno. Just brawddegau - nid HTML cyfan, oherwydd gall pob cyfieithiadau tro yn wahanol (hy breintiau gwahanol o ddefnyddwyr, cynnwys newid). Gall un tudalen HTML wedi cannoedd o frawddegau i gyfieithu - vBET yn cynnwys rhwng tagiau HTML. Diolch DB cache nad yw'r cyfieithiadau oes rhaid eu cymryd bob tro gan Google - beth yn defnyddio llawer o amser - yn lle hynny, y rhai yn cael eu cymryd gan eich DB lleol. Still - tudalen arferol wedi cael ei gynhyrchu ac ar ôl y cyfieithu.
Cache Ffeil Llawn I Gwesteion yn gweithio yn unig ar gyfer gwesteion. Diolch nad ydym yn rhaid i ni boeni bod defnyddwyr wedi breintiau gwahanol a gweld pethau yn wahanol. ll gwesteion yn gweld yr un cynnwys. Oherwydd nad oes raid i ni dosrannu canlyniad a gyfieithu bob yn dipyn, bob tro - fe allwn ni ei wneud yn syml ei bod yn un peth amser a cache allbwn HTML llawn. Felly, yn yr achos hwn pan nad tudalen llawn yn cached, neu cached cynnwys yn rhy hen, yna cyfieithiad arferol yn digwydd - yn union fel a ddisgrifir o'r blaen. Ond y tro hwn ar ddiwedd iawn cynnyrch llawn HTML cael ei ysgrifennu i ffeil. Felly, y tro nesaf pan fydd un cais yn dod o westai nid ydym yn cynhyrchu hyd yn oed yn cynnwys tudalen arferol - rydym yn syml ffrwd i westai ffeil sydd eisoes cached HTML. Dyna pam ein bod yn arbed llawer o ymholiadau SQL, CPU a chof. Rydym yn unig yn rhoi i gynnwys defnyddwyr o ffeil statig. Dyna pam ei bod yn bwysig er mwyn penderfynu pa mor hir y bydd hyn yn cache yn ddilys. Oherwydd os bydd rhywbeth yn newid - hy bydd swydd newydd yn cyrraedd i edau, yna ni fydd gwesteion yn gweld y swydd newydd hyd nes y ffeil yn barod cached dod i ben. Ar ôl hynny yn ystod y cais nesaf, bydd tudalen eto arferol cael ei greu, cyfieithu, a cached - a bydd hyn yn cynnwys gwesteion weld hy am awr arall (configurable). Ni fyddant yn gweld unrhyw newidiadau hyd nes y ffeil cached dod i ben eto. Wrth gwrs, bydd eich defnyddwyr yn gweld popeth, gan ei fod yn gweithio yn unig ar gyfer gwesteion (felly ar gyfer robotiaid hefyd, am fod robotiaid cropian eich fforwm fel gwesteion).
Dywedwch yn gwneud hynny yn helpu ac yn achos unrhyw gwestiynau dim ond gofyn - byddwn yn hapus i disgrifio yn fwy![]()
Bydd yn cael ei, bydd yn cael eiMae'r rhan fwyaf o bethau newydd yn cael eu profi yno'n barod. Mae gennym fwy i'w wneud rhag ofn Cache Ffeil Llawn ar gyfer Gwesteion ar vB4, oherwydd rydym yn cefnogi yno gyfieithu mwy o fathau o URLs ar gyfer vBSEO a hefyd URLs Cyfeillgar o vB. Ac o bob un o'r rhai y mae'n rhaid i ni ei brofi'n ofalus iawn ac mae'n rhaid i ni weithredu cefnogaeth o ailgyfeirio cynharach ar gyfer rhai o'r rheiny o hyd. Hefyd - byddwn yn defnyddio'r amser ychwanegol hwn i wirio unrhyw faterion posibl gyda Cache Ffeil Llawn Ar gyfer Gwesteion (a ystyrir yn BETA nawr) ar fforymau vB3. Rydyn ni'n ei brofi'n dda, ond mae bob amser yn well gofalu mwy am ansawdd da
![]()
mewn ffeil /images/vbet/flags/vbet.CSS
Disgrifiwch yn well beth mae'n ei olygu "rhyfedd" - efallai byddwn yn gallu eich helpu. Hefyd, rydym yn cynghori i'w defnyddio ar gyfer pethau megis Firefox ag plugin Firebug - bydd yn caniatáu i chi ddangos yn union pa arddulliau css yn cael eu defnyddio ar gyfer elfennau penodol. Mae'n wirioneddol ddefnyddiol![]()
Safon. Jyst gwnewch yn siŵr eich gwneud y cyfan. Bennaf yw defnyddwyr yn eisiau llwytho delweddau eto - mae'n rhaid i chi yn y fersiwn. Nawr mae gennym un ddelwedd ar gyfer yr holl baneri. Os na fyddwch yn gwneud diweddariad llawn, byddwch yn gweld baneri torri.
Rwy'n gwybod bod i bawb ei fersiwn ef yn fwyaf pwysigAc nid ydym am i ddadlau â hynny
Yn yr achos hwn yn gynharach vBET3.x am reswm da iawn: ANSAWDD. Rydym yn ychwanegu ymarferoldeb newydd pwysig (Cache Ffeil llawn ar gyfer gwesteion) yn hyn fersiwn, ac roedd yn llawer haws i ychwanegu i vB3, oherwydd mae unrhyw URLs cyfeillgar, a gallwn droi'r dim ond llinyn URLs ar gyfer vBSEO. Mewn vB4 mae'n fwy cymhleth-rhaid cefnogi pob URL cyfeillgar, a gallwn droi'r llawer mwy o fathau o URLs. Mae'n rhoi gyntaf yn vB3. caniatáu inni i brofi ei dda iawn ar fforymau go iawn, gwnewch yn siŵr ei fod yn gweithio'n iawn, efallai bydd yn dangos Mae rhai chwilod cyn iddo fynd i vB4. Ac ar ôl yr ydym yn hollol siŵr ei bod yn gwbl iawn, mae gennym i ychwanegu yn vB4 sy'n cysylltu cymorth (Friuendly URLs, mwy translted URLs). Hynny yw dal angen pam hwn vBET3.x amser cynharach a ydym 2 wythnos ar gyfer vBET4.x. A diolch y cewch ateb sydd â ewen o ansawdd da iawn os yw'n fwy cymhleth achos thatin o vB3
Ni ddylai fod unrhyw beth megis effaith negyddol berfformiad oherwydd cache ffeil. Mae'n oherwydd nad oes cache Ffeil dyfu ... Rydym yn creu ffeil ar wahân ar gyfer pob URL cais. Felly pob ffeil storfa, yn syml, statig HTML ffeil (allbwn cached am y cais). Pan fydd eich gweinydd caches vBET mwy a mwy syml yn creu ffeiliau yn fwy a mwy. Felly, bob tro pan ffeil o'r fath yn darllen:
1. Mae darllen yn ganlyniad dim ond ar gyfer yr URL arbennig
2. Rydym hyd yn oed yn darllen i gof - dim ond yn syml ffrwd i gleientiaid gan ddefnyddio PHP swyddogaeth: readfile
Oherwydd bod hyd yn oed os yw eich tudalen canlyniad yn fawr iawn - ffeil cache felly hefyd yn fawr, bydd yn cael unrhyw effaith negyddol perfformiad, gan y bydd yn jyst ffrwd y ffeil un heb hyd yn oed ddarllen cyfan i mewn cof. Felly, byddwch yn gweld manteision peidio anfanteision.