Mange av oss installere (PHP, CGI eller ASP) serverskript på våre nettsider, og mange av denne skript lagrer data på serveren. Dårlig utformet skript kan imidlertid oppleve ytelsesproblemer og noen ganger også dataødeleggelse på webområder for opptatt (og ikke så opptatt).
Hvis du ikke er en programmerer, hvorfor skal det noe til deg?
Svar: selv om du bare installerer og bruker serverskript, må du sørge for at skriptene du velger ikke tilfeldig bryte eller korrupte data.
Først, ta med noen eksempler på hvilke typer skript som lagrer data på web-servere:
(Selvfølgelig mange skript i hver av disse (og andre) kategorier er godt utformet, og kjøre helt bra selv på veldig opptatt nettsteder).
1. Oppfølging autoresponders vanligvis lagre liste over abonnenter til autosvarer, samt hvor i sekvensen av meldinger, hver enkelt abonnent er. Eksempler på autosvarer skript: http://www.scriptcavern.com/scr_email_auto.php
2. Rubrikkannonse skript lagre (minst) en liste over alle annonser plassert av besøkende. Eksempler på denne typen skripet: http://www.scriptcavern.com/scr_classified.php
3. Gratis for alle koblinger skript lagre en liste over alle koblinger som er skrevet av besøkende. Hvis du vil se noen eksempel-skript som er oppført på: http://www.scriptcavern.com/scr_ffa.php
4. Topp området skript vanligvis lager en liste over medlemmene i det øverste området samt informasjon om hvor mange "stemmer" som hver har mottatt. Hvis du vil se eksempler på denne typen skript, se http://www.scriptcavern.com/scr_topsite.php
Så hva slags skript har problemer? Og hva slags problemer jeg snakker om?
Vel prinsippet problemene alle forholde seg til hva som skjer når biter med data fra flere brukere trenger å bli lagret på oppdatert på samme tid. Noen skript til å håndtere slike situasjoner godt, men andre ikke...
DATAFEIL
Her er en vanlig data korrupsjon problem som kan oppstå med mange skript:
1. Når noen bit av data må oppdateres, en kopi av serverskript begynner å kjøre, og starter deretter oppdatere den.
2. Hvis en annen bruker kommer og gjør en oppdatering før den første kopien av skriptet er fullført, starter en ekstra kopi av skriptet kjører samtidig.
3. Det finnes en rekke måter ting kan nå gå galt, på for eksempel:
(a) hva hvis den første kopien av skriptet leser i dataene, og den andre kopien leser de samme dataene, deretter den første kopien deretter oppdaterer dataene, og deretter den andre kopien oppdateres dataene? Svar: alle endringer som er gjort av den første kopien av skriptet kan bli brutt.
(b) hva om den første og andre kopien av skript er begge legge flere biter med nye data til store samtidig? Tenk deg for eksempel hver trenger å lagre overskriften, beskrivelse og navnet på personen som legger en klassifisert annonsen. Vel, hva som kan skje (med noen skript) er to annonser kan komme sammen, slik at du kan få (for eksempel) overskrift-1, Beskrivelse-1, Overskrift 2, PERSON-1, Beskrivelse-2, PERSON-2. Eller verre ennå, kan du få biter av hver del av hver rubrikk annonse, blandet med biter av den andre. Denne type ting er vanligvis virkelig dårlige nyheter som dataene kan derfor bli ubrukelig fra dette tidspunktet.
Betyr dette høres for usannsynlig et problem å bekymre deg? Ikke banken på ut..., selv om det skjer bare en gang i 1000, eller 1 i 10.000, til slutt vil det skje: du trenger en løsning.
Så det virkelige spørsmålet er: er det mulig for programmerere å opprette skript uten disse typer problemer? Heldigvis svaret er Ja, og det finnes en rekke måter at programmerere kan ta det:
1. De kan lagre hver bit av data i en separat fil. Dette er ikke nødvendigvis en totalløsning av seg selv (i særlig et skript som bare gjør dette kan fortsatt har problemer hvis flere kopier av et skript som oppdaterer den samme filen på samme tid), men det gjør gjøre dataødeleggelse mindre sannsynlig, og hvis det oppstår skade, minst det vil ikke ødelegge hele datalageret samtidig.
2. De kan bruke fillåsing. Dette betyr at hvis én kopi av et skript er arbeider med en fil, en annen kopi av manuset er forhindret fra å arbeide på denne filen til den første kopien er ferdig. Fillåsing fungerer hvis det gjøres riktig, men programmering den inn i et skript må gjøres svært nøye og presist, for hver enkelt mulige saken... selv en liten feil eller utelatelser kan tillate muligheten for data-korrupsjon i gjennom bakdør!
3. De kan bruke en database (for eksempel MySQL) til å lagre dataene. Forutsatt at dataene er riktig strukturert i databasen, håndterer databasen låsing automatisk. Og som programmerer ikke behøver å skrive sine egne spesielle låse rutiner, muligheten for feil og utelatelser reduseres mye.
YTELSESPROBLEMER
Selvfølgelig, å unngå å ha dataene skadet bør paramount betraktning når du velger et skript, men er det noe annet vi trenger å være bekymret?
Svar: ytelse
Selvfølgelig, alle webmasters tar sikte på å bygge opptatt høy trafikk web-områder... men skriptene skal kunne håndtere belastningen?
Gå tilbake og re-lese avsnittet på fillåsing. Nå Tenk på hva som ville skje hvis alle annonser på klassifisert siden ble lagret i en enkelt fil (eller alle koblinger på nettstedet toppen eller alle abonnenter til autosvarer osv.).
Hva ville skje?
Svar: Fordi hver oppdatering kan bare utføres etter at den forrige oppdateringen er helt ferdig, nettstedet kan være treg, eller selv ute av stand til å håndtere alle brukernes forespørsler.
Så hva er løsningen?
Det er to alternativer som programmerere kan bruke:
1. De kan bruke mange små filer og filen-låser hver individuelt (for eksempel en per klassifisert, ett per øverste område, osv.). Selvfølgelig, må dette behandles svært forsiktig...
2. De kan bruke en database (som MySQL), som databaser tillater alle én enkelt post ("rad") skal oppdateres, selv når en annen også blir oppdatert.
AVSLUTNINGSVIS
Nå, la oss oppsummere:
1. Skript som lagrer data i filer må bruke fillåsing for å unngå ødeleggelse av data, og de må også bryte dataene i separat oppdaterbar biter å unngå ytelsesproblemer på travle web-områder.
2. Skript som lagrer data i databaser (som MySQL), forutsatt selvfølgelig at de har blitt riktig kodet, er vanligvis mindre sannsynlig å lide fra ødeleggelse av data eller ytelse problemer.
Og ett ekstra punkt:
3. Selv det beste manuset er ikke uimottakelig til harddisken maskinvarefeil, webverten blir truffet av lyn, og alle andre snafus som kan skje. Så, ta vanlige back-ups av data som du ikke har råd til å tape!
Kort sagt, selv om din ikke ' en skript-programmerer, må du være klar over data storage problemer. I fremtiden, når du vurderer et skript for web-området, ikke vær redd for å spørre noen vanskelige spørsmål om hvordan det lagrer data og hvor godt det håndterer flere brukere.
No comments:
Post a Comment