vBET 3.3.4 sluppet

[rootksk]

Oppgradert etter server last problem

[steve]

Har noen noen ide hvor stort filhurtigbufferen kunne få før det har en negativ innvirkning på ytelsen?

[vBET]

I dont forstår dette filhurtigbufferen, hvorfor ville du trenger en andre cache, det viktigste man allerede mellomlagrer sider, og bare oppdateringer når nytt innhold blir lagt til, så hvorfor cache det i 1 time igjen, er din forklaring vanskelig å forstå.

Database cache cacher bare oversettelser. Ikke hele HTML-innhold. Så når noen oversatt side genereres, deretter første normale siden er generert og etter at den er tolket og oversatt. Under oversettelse DB cache er brukt og oversatt setningene er hentet derfra. Bare setninger - ikke hele HTML, fordi hver gang oversettelser kan være forskjellig (dvs. forskjellige rettigheter for brukere, endret innhold). Man HTML-side kan ha hundrevis av setninger å oversette - vBET tar innhold mellom HTML-koder. Takket DB cache disse oversettelsene trenger ikke å bli tatt hver gang fra Google - hva bruker mye tid på - i stedet for det, er de hentet fra ditt lokale DB. Likevel - normal side må genereres og etter det oversatt.

Full filhurtigbufferen For gjester fungerer bare for gjester. Takket være at vi ikke trenger å bekymre deg for at brukerne har ulike privilegier og se forskjellige ting. ll gjestene se det samme innholdet. På grunn av at vi ikke trenger å analysere resultatet og oversette det bit for bit hver gang - vi kan bare gjøre det en en stund og cache full HTML-utgang. Så i dette tilfellet når full side ikke er bufret, eller bufret innholdet er for gammel, så normal oversettelse skjer - akkurat som beskrevet før. Men denne gangen helt på slutten full HTML-utgang er skrevet til fil. Så neste gang når samme forespørselen kommer fra gjest vi ikke generere enda normal sidens innhold - vi bare strøm til gjest allerede bufrede HTML-fil. Det er derfor vi sparer mye SQL-spørringer, CPU og minne. Vi bare gi brukeren innhold fra statisk fil. Det er derfor det er viktig å finne ut hvor lenge denne bufferen vil være gyldig. Fordi hvis noe vil forandre seg - dvs. nye innlegg kommer til tråden, da gjestene ikke vil se dette nye innlegget til allerede hurtigbufrede filen utløper. Etter at under neste forespørsel vil igjen normal siden bli generert, oversatt og bufret - og dette innholdet gjester vil se dvs. en time (konfigurerbar). De vil ikke se noen endringer før hurtigbufrede filen utløper igjen. Selvfølgelig brukerne vil se alt, fordi det fungerer kun for gjester (slik for roboter også, fordi roboter gjennomsøker forumet som gjester).

Rådfør gjorde det hjelpe og i tilfelle noen spørsmål bare spør - vi vil gjerne beskrive det mer

[vBET]

Super Mate!

Takket være en million,

Darn: Trodde dette var for 4.0.x. .. Cool uansett om ... Kan ikke vente på 4.0.x versjon.

Det vil bli, vil det være

[vBET]

Hvordan redigerer jeg css for flaggene please, trenger å endre måten de viser som det ser merkelig som det er.

i filen /images/vbet/flags/vbet.css
Beskriv bedre hva det betyr "rare" - kanskje vi vil kunne hjelpe deg. Også vi anbefaler å bruke til slike ting Firefox med plugin Firebug - det vil tillate å vise deg nøyaktig hvilke CSS-stiler er brukt for spesifiserte elementer. Det er virkelig nyttig

[vBET]

Er kundesupport tilgjengelige for øyeblikket? Denne nyeste oppdateringen er årsaken omdirigere loops og jeg trenger assistent snarest.

Vi fikk e-post og sjekke det. Vi kan ikke gjengi det på serveren din. Du fikk svar med spørsmål om eksakte URL som har dette loop. Vennligst sjekk det og svaret der

[vBET]

Ingen installasjon instruksjoner (eller oppgradere instruksjoner)?

Standard. Bare husk å gjøre det hele. Mostly brukere ikke ønsker å laste opp bilder igjen - du må i denne versjonen. Nå har vi ett bilde for alle flagg. Hvis du ikke gjort full oppdatering vil du se brutt flagg.

[vBET]

Ya hvorfor er vi oppdaterer vb tre ting når det vB4. nå.

Kom vbet vi bør få vbet oppgradert for vb 4 først!

Jeg vet at for alle hans versjon er viktigst Og vi ønsker ikke å argumentere med at I dette tilfellet vBET3.x er tidligere for svært god grunn: KVALITET. Vi legger til nye viktige funksjonalitet (Full File Cache for passasjerenei denne versjonen, og det var mye lettere å legge det inn vB3, fordi det ikke er noen Vennlige Nettadresser, og vi oversetter kun tråden Nettadresser for vBSEO. I tilfelle av vB4 det er mer komplisert - Vennlige Nettadresser må være støttet, og vi oversette mye mer typer url-er. Å sette den første i vB3. tillatt oss å teste det veldig godt på ekte fora, sjekk at det fungerer fint, kanskje vil vise noen feil før det går til vB4. Og etter at vi er helt sikker på at det er alt fint, vi har fortsatt å legge til i vB4 ekstra støtte (Friuendly Nettadresser, mer translted url-er). Det er derfor denne gangen vBET3.x er tidligere og vi trenger fortsatt 2 uker for vBET4.x. Og takk for at du vil få en løsning som har svært god kvalitet, ewen hvis det er mer komplisert thatin tilfelle av vB3

[vBET]

Oppgradert etter server last problem

Vennligst åpne ny tråd i avsnittet Feilsøking og beskrive det mer.

[vBET]

Har noen noen ide hvor stort filhurtigbufferen kunne få før det har en negativ innvirkning på ytelsen?

Det skal ikke være noe slikt som negative ytelsen innvirkning på grunn av filhurtigbufferen. Det er fordi filhurtigbufferen ikke vokser ... Vi skaper separat fil for hver forespørsel URL. Så hver cache-fil er rett og slett statiske HTML-fil (bufret utgang for forespørsel). Når serveren skjulestedene mer og mer vBET skaper bare flere og flere filer. Så hver gang når en slik fil blir lest:
1. Det er skrivebeskyttet resultat for denne nettadressen
2. Vi har selv ikke lest den til minne - bare rett og slett streame den til klienten ved hjelp av PHP-funksjonen: readfile

På grunn av at selv om resultatet siden er virkelig stor - så cache filen er også stor, vil det ha noen negativ påvirkning på ytelsen, fordi det vil bare streame denne ene filen uten engang å lese hele den inn i minnet. Så du vil se fordelene ikke ulempene.