a) Jeg har aldrig set jeres definition i kraft nogle steder men derimod lyder webhotellets opfattelse som det normale - andet ville også næsten være umuligt i mine øjne.

b) jeg kan ikke helt se forskellen på de to definitioner, kan du prøve at forklare nærmere?

Generelt har "det normale" vide rammer, men mit bedste bud er:

a) Måling over en kalendermåned. Jeres bud på en definition er ikke kutyme.

b) Som jeg forstår det, så må det være jeres fortolkning, som er den rigtige.

Men for begge punkter gælder, at hvis det ikke er skrevet ind i kontrakten, så vil det normalt være en uvildig opmand, som skal afgøre det. Dette vil ske ud fra såvel det, der nu engang står i kontrakten og så branchekutyme.

> keysersoze

Jeg forstår ikke helt, hvorfor du mener det vil være "næsten umuligt" at foretage kontinuerlige målinger over oppetid per uge (30 timers perioder).
Se her:
http://en.wikipedia.org/ (...)
99% availibility svarer til 1,68 times nedetid over en 30 timers periode.
Problemet ved en måling over 6 måneder er jo, at portalen kan være nede i en hel dag, uden at krænke kontrakten, hvis den kører alle de andre dage i de 6 måneder, men for en forretningskritisk applikation (fx en netbank) vil dette scenarium jo være oplagt uacceptabelt.

Forsøg på forklaring på "B":
Requests på en webside på en portal modtages af serverens frontend, og er sendt fra kundernes web-klienter (browsere). Disse requests bliver behandlet af serveren i en kø-rækkefølge, eller søgt behandlet samtidig. Se fra slutbrugerens synspunkt opleves, at de har sendt requesten, og deres browser står og venter på at modtage alle sidens komponenter (særligt ved en side, der består at portlets/webparts. Det er efter vores mening det central at fx 1000 requests kan håndteres inden for en defineret svartid (tiden der går fra requestets afsendelse fra klienten (slutbrugeren) til siden er tegnet færdig i hans browser). Dette er efter min opfattelse der er vigtig for slutbrugeren.

At webserveren eller fx SharePoint rent teknisk ikke går helt død, hvis der ligger 1000 request i kø, er en mere akademisk problematik.

At 1000 brugere trykker ENTER på samme tid er endnu mere akademisk, dels fordi de ikke modtages samtidig hos serveren, dels fordi det er irrellevant for slutbrugeren. Slutbrugeren er interesseret i at hans requestede portalside eksekveres og færdigtegnes (inden for den aftalte responsetid).

>Natkatten
Ad A:
Jeg tolker din kommentar som, at den månedlige gennemsnitlige oppetid i en måned er kutyme. Altså uanset hvordan og hvor lange de enkelte nedeperiode er?

Ad B:
Har du nogle eksempler på, at andre har "vundet" vores fortolkning?

a) Det jeg mener med at det er besværligt er set fra en udbyders synspunkt at overholde (selvom jeg selvfølgelig godt ved at det ikke er i din interesse) for sker det uheldige at fx en server bryder ned og alt skal genskabes fra en backup vil det nok være meget få der kan opretholde sådan en oppetids-regel. Jeg mener ikke at det er hverken besværlig eller umuligt at måle men altså at overholde såfremt din definition var den lovede. Oppetiden har jeg som sagt kun set som værende over en vis periode og det er det jeg mener er definitionen - og loves andet ville det næsten være for godt til at være sandt (bare se på de udfordringer IBM har haft med Danske Bank (og/eller Carlsberg?) de seneste år - kan de set på dagsbasis er der nok ikke mange der kan).

b) Her må jeg faktisk være dig svar skyldig - havde du ikke givet jeres bud ville jeg umiddelbart have sagt på antal sessioner (hvilket egentlig er et lidt ubrugeligt tal), men at gætte på hvilket af jeres muligheder, der er korrekt nytter ikke meget.

Hvis du ikke allerede har været forbi så forsøg evt at stille samme spørgsmål på amino.dk - her sidder et par fyre med lidt mere viden om dette emne.

re a)

99% optid per døgn er max. 14 minutters nedtid per døgn

99% optid per måned er max. 7 timers nedtid per måned

Det første vil give masser af OK'er og enkelte Ooops'er, mens den anden vil give en fornuftig indikation af optiden.

Per døgn duer ikke.

re b)

Ingen af definitionerne kan efter min mening bruges.

I bør bruge antal sessioner.

For det første er det det som belaster serverens memory.

For det andet så er det vel hvad der giver logisk mening (hvis web sitet har en lille kasse med "X brugere online" så er det antal sessioner der vises).

> Alle, der har skrevet et indlæg.
Smid et svar.
Jeg prøver at hæve points og fordele.

.

svar :)

Har netop opdaget, at man ikke længere kan hæve points for et allerede oprettet spørgsmål.
Derfor fordeler jeg de oprindelige points.