Avatar billede Slettet bruger
31. august 2010 - 04:41 Der er 8 kommentarer og
2 løsninger

a) Samtidige brugere b) oppetid - definitioner?

Vi har en tvist med en hostingleverandør om definitioner på:
a) oppetid
b) antal samtidige brugere.

Ad a:
Oppetidsdiskussionen går på, at vi i udbuddet har krævet 99% oppetid 24/7. Men det er nu sat til diskussion, over hvilket tidsrum målingen skal foretages. Den ene yderlighed (vores) er en måling over hvert kalenderdøgn (24 timer). Den anden yderlighed er en (gennemsnitlig) måling over et halvt år. Den første mulighed er jo klart til kundens fordel, den anden klart til hostingleverandørense fordel. Hvad er normalt i branchen?

Ad b)
Antal samtidige brugere. Diskussionen går på, hvordan samtidige brugere skal defineres. Jeg er med på, at HTTP er en stateless protokol. Den ene yderlighed er, at samtidige brugere defineres som antal brugere, der på sammme milisekund trykker ENTER på en request for en side på portalen. Den anden fortolkning (vores) er antalllet af brugere, der samtidig har requestet en webside fra portalen, og samtidig sidder og venter på at få færdigtegnet websiden i deres web-klient. Hvad er normalt i branchen?
Avatar billede keysersoze Guru
31. august 2010 - 07:41 #1
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?
Avatar billede natkatten Mester
31. august 2010 - 07:50 #2
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.
Avatar billede Slettet bruger
31. august 2010 - 08:43 #3
> 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/wiki/High_availability
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).
Avatar billede Slettet bruger
31. august 2010 - 08:53 #4
>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?
Avatar billede keysersoze Guru
31. august 2010 - 18:26 #5
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.
Avatar billede arne_v Ekspert
01. september 2010 - 01:14 #6
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).
Avatar billede Slettet bruger
20. oktober 2010 - 10:48 #7
> Alle, der har skrevet et indlæg.
Smid et svar.
Jeg prøver at hæve points og fordele.
Avatar billede arne_v Ekspert
20. oktober 2010 - 15:13 #8
.
Avatar billede keysersoze Guru
20. oktober 2010 - 23:53 #9
svar :)
Avatar billede Slettet bruger
25. oktober 2010 - 14:28 #10
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.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Uanset kodesprog, så giver vi dig mulighederne for at udvikle det, du behøver.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester