Proxy TTL
Proxy TTL
Ku vi ikke fået skruet ned for den proxy TTL der gør at debatten her ikke glider, eller sat nogle ordentlig expire informationer.
Jeg har f.eks. lige fået en mail om en kommentar, men det går rum tid før jeg kan læse kommentaren.
(det er også derfor folk opretter ens tråde/svar).
/m
Nogle bedre svartider
Nogle bedre svartider generelt ville bestemt heller ikke være at foragte.
På det helt lavpraktisk niveau tager det cirka dobbelt så lang tid at pinge dds.dk som det tager at pinge min gruppes domæne, der er placeret på et webhotel der skal forblive anonymt.
MVSH.
Jesper - TL/KL Svend Grate Gruppe
Morten, det er en god pointe
Morten, det er en god pointe - det vil vi kigge på, f.eks. ifm. næste ITG weekend i starten af december (eller før, anyone ITG?)
Jesper, hverken jeg eller andre i ITG kan reproducere dine resultater. Både fra hosts tæt på DIX eller ~10 hops væk er pingtider til dds.dk sammenlignelige og konkurrencedygtige med andre (store) hostede sites, så det siger nok mere om din "nærhed" til dit unævnelige webhotel end om DDS' netværk. Post gerne dine resultater her, så vi kan få syn for sagen.
Mvh Anders
HejsaMine resultater er
Hejsa
Mine resultater er her:
jesper@jesper-laptop:~$ ping dds.dkPING dds.dk (62.243.225.167) 56(84) bytes of data.64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=1 ttl=54 time=3.31 ms64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=2 ttl=54 time=3.24 ms64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=3 ttl=54 time=4.22 ms64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=4 ttl=54 time=3.01 ms64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=5 ttl=54 time=3.09 ms64 bytes from proxy.dds.dk (62.243.225.167): icmp_seq=6 ttl=54 time=3.82 ms^C--- dds.dk ping statistics ---6 packets transmitted, 6 received, 0% packet loss, time 5009msrtt min/avg/max/mdev = 3.010/3.450/4.220/0.433 msjesper@jesper-laptop:~$ ping svendgrate.dkPING svendgrate.dk (217.116.232.208) 56(84) bytes of data.64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=1 ttl=55 time=1.93 ms64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=2 ttl=55 time=1.06 ms64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=3 ttl=55 time=1.15 ms64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=4 ttl=55 time=1.88 ms64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=5 ttl=55 time=1.18 ms64 bytes from web8.gigahost.dk (217.116.232.208): icmp_seq=6 ttl=55 time=1.82 ms^C
Jeg har kørt dem fra min arbejdspladsforbindelse, der har en ganske betragtelig forbindelse. Da min arbejdsplads ikke har det fjerneste med spejderbevægelsen eller med gigahost at gøre, er der altså tale om en valid "tilfældig" forbindelse. Om problemet ligger "inden i huset" hos jer, eller om der er tale om en kedelig ISP kan jeg naturligvis ikke vide, og det er da klart at det rent tilfældigt kan tænkes at jeg er meget tæt på gigahost (jeg er uden internet i min bolig i disse dage, så jeg har ikke kunnet teste herfra). Endelig er et ping naturligvis et øjebliksbillede, og det kan da sagtens være at der netop i disse dage er tryk et eller andet krydsfelt, men det er jo vilkårne med de her ting (:
Når det så er sagt, er der nok andre steder i protokolstakken, der med fordel kan sættes ind hvis der skal optimeres på svartider.
MVSH.
Jesper
Hej Jesper Ping tider
Hej Jesper
Ping tider fortæller ikke så meget om hastigheden af et website, hvor belastningen tydeligevis ligge et helt andet sted end i connectiviteten.
Rent ping mæssigt virker det som om din arbejdsplads har en lang og/eller tricky route til dds siten, en traceroute kunne være interessant.
TDC servercamp i Herlev:--- svendgrate.dk ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9000msrtt min/avg/max/mdev = 1.049/1.099/1.125/0.029 ms--- dds.dk ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9005msrtt min/avg/max/mdev = 1.779/1.974/2.363/0.162 msInterXion I Ballerup--- svendgrate.dk ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9011msrtt min/avg/max/mdev = 0.899/1.072/1.467/0.169 ms, pipe 2--- dds.dk ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9012msrtt min/avg/max/mdev = 1.993/2.261/2.581/0.171 ms, pipe 2
/morten
Hej Jesper, Nu kom Morten mig
Hej Jesper,
Nu kom Morten mig i forkøbet mht. traceroute.
Når det er sagt, så kan jeg da godt se at du har ca. dobbelt så høj ping til dds.dk som til gigahost. Hvis du oplever pingtider på 3-4ms som et problem, så har du behov for at komme ud i den virkelige verden af og til.
Som Morten så rigtigt skriver ligger root cause ikke i latency (og ejheller båndbredde), men et helt andet sted.
Mvh Anders
Morten og Jesper, jeg er enig
Morten og Jesper,
jeg er enig i at sidernes svartider har større betydning end ping tid. TTL tiden er, som jeg husker det, sat højt for at kunne give aflastning af den server, som laver siderne - proxy'en kan nemt fylde den 10 MBit/s linie, korpskontoret har. Den anden ting som påvirker svartiderne er at vores Apache somme tider er gået ned i den seneste tid. Jeg har som forsøg lavet lidt om på levetiderne for Threads, så en evt. u-dekteret memory leak ikke kan akkumulere. Med andre ord: Først stabilisere, så optimere. Det er i hvert fald min holdning. Det skulle ikke undre mig om vi kan sætte TTL ned generelt, hvis "backend" serveren bliver stabil. Mvsh. Ænkå
Hejsa "jeg er enig i at
Hejsa
"jeg er enig i at sidernes svartider har større betydning end ping tid."
Lad mig med det samme sige klart og tydeligt, at jeg ikke har hævdet det modsatte - det skal man jo nærmest være fra Det Unævnelige Universitet for at tro. Mit ping var ment som e hurtig test, for at se om der måske var et problem alleere i IP laget - intet andet.
Med hensyn til apache, kan man overveje at køre med processer istedet for tråde - på MMP hardware giver det typisk en fordel. Jeg skrev på et tidspunkt en webserver, som studieprojekt, og forskellen på tråde og processer var næsten en faktor 10, men jeg snød selvfølgelig også og tilpaseede mine tråd/proces layout til at matche den underliggende hardware præcist (:
MVSH.
Jesper
Hejsa "Når det er sagt, så
Hejsa
"Når det er sagt, så kan jeg da godt se at du har ca. dobbelt så høj ping til dds.dk som til gigahost. Hvis du oplever pingtider på 3-4ms som et problem, så har du behov for at komme ud i den virkelige verden af og til."
Her skal du så lære at absolute tal ikke er interesante i denne her sammenhæng. Det interessante er naturligvis forholdet mellem tallene. Som sagt er min arbejdspladsfrbindelse ganske betydelig (jeg har ikke lov at gå i detaljer). Sad jeg nu der hjemme med min - lidt fesne - forbindelse fra danskNet, ville jeg forvente at de absolutte tal var betydeligt højere (måske oven i købet MEGET højere). Når du snakker om mit forhold til den virkelige verden, snakker du altså som du har forstand til. Jeg har ALDRIG påstået at det er et problem at latenstiden på en ip pakke (ovenikøbet round trip time) er i størrelsesordenen 3-4ms, men det er interessant at det er dobbelt så højt som til et webhotel.
"Som Morten så rigtigt skriver ligger root cause ikke i latency (og ejheller båndbredde), men et helt andet sted."
Og det var vel også hvad jeg selv skrev, da jeg postede mine resultater. Dog tager du fejl,når du negligerer disse faktorer - det betyder oplagt noget, omend en underdimensioneret, eller dårligt implementeret server, selvfølgelig kan overtrumfe disse - det kan vi brugere bare ikke se, og det skal vi heller ikke kunne.
MVSH.
Jesper
Hejsa "Ping tider fortæller
Hejsa
"Ping tider fortæller ikke så meget om hastigheden af et website"
Det var vist også hvad jeg skrev. Men, men det vi måler er den "rene" latens tid i det netværk, der går fra min klient maskine, til serveren. Det var baggrunden for at jeg i første omgang talte om "helt lavpraktisk".
Det er klart at en traceroute giver mere info, men det jeg ville forholde mig til her er systemet som blackbox. Jeg er en tilfælig bruger, på et tifældigt netværk, og er er latenstiden betydeligt større til dds.dk, end til en server i et webhotel.
Det er helt klart at der mange andre steder at sætte ind, mht. svartider: databasen der ligger bagved CMS systemet, en eventuel firewall, måske proxy'en er sløv og mange andre muligheder - noget af det har jeg kendskab til gennem møder jeg har deltaget i, og det kommer ikke på debatten fra min side.
MVSH.
Jesper
Hej Jesper, Hvis du
Hej Jesper,
Hvis du _virkeligt_ mener at du kan mærke forskel på at browse to ens websites på to forskellige netværk med latency-forskel på 2ms har du behov for at komme ud i den virkelige verden...
Mvh Anders
Hejsa Du har så endnu ikke
Hejsa
Du har så endnu ikke lært forskellen på relative og absolutte værdier.
Så længe du ikke kender til mit arbejde, bør du nok stikke piben lidt ind - specielt når du ikke engang gidder læse hvad jeg skriver.
MVSH.
Jesper
Nu går jeg altså ud og henter
Nu går jeg altså ud og henter cola og popcorn!
/m
Desværre forgæves, for jeg
Desværre forgæves, for jeg agter ikke at fodre trolden yderligere ;-)
Mvh Anders
Drop nu ping - stabil drift,
Drop nu ping - stabil drift, dernæst svartider er vigtigst. Jesper, som jeg læser dit indlæg har du viden om trimning af Apache. Hvis du vil tage et kig på dingo.dds.dk's apache2.conf, så skal du være velkommen. (Ja, jeg ved godt at jeg prøver at tage hele armen når du rækker en finger i vejret...) Mvsh. Ænkå
Vel talt, Ænkå. Jeg ser frem
Vel talt, Ænkå.
Jeg ser frem til at høre hvilke konkrete tiltag Jesper kan foreslå for at bibringe stabil og hurtig drift.
Mvh Anders