{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Hvordan vi klarede en pludselig stigning i belastningen x10 p\u00e5 distancen og hvilke konklusioner vi gjorde","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr! I de sidste par m\u00e5neder har vi v\u00e6ret i en meget interessant situation, og jeg vil gerne dele vores historie om skalering af infrastrukturen. I denne periode er SberMarket vokset fire gange i antal ordrer og har lanceret servicen i 17 nye byer. Den eksplosive v\u00e6kst i eftersp\u00f8rgslen efter levering af dagligvarer har kr\u00e6vet, at vi skalerer infrastrukturen. L\u00e6s om de mest interessante og nyttige konklusioner nedenfor.<\/p>\n

\"Hvordan
\n<\/a><\/noindex>
\nMit navn er Dima Bobylev, jeg er teknisk direkt\u00f8r for SberMarket. Da det er det f\u00f8rste indl\u00e6g i vores blog, vil jeg sige et par ord om mig selv og virksomheden. Sidste efter\u00e5r deltog jeg i konkurrencen om unge ledere i Runet. Til konkurrencen skrev jeg en lille historie<\/a><\/noindex> om hvordan vi i SberMarket ser p\u00e5 den interne kultur og tilgangen til udviklingen af servicen. Selvom jeg ikke vandt konkurrencen, s\u00e5 formulerede jeg de grundl\u00e6ggende principper for udviklingen af IT-\u00f8kosystemet. <\/p>\n

N\u00e5r man leder et team, er det vigtigt at forst\u00e5 og finde balancen mellem, hvad der er n\u00f8dvendigt for forretningen, og behovene hos hver enkelt udvikler. I \u00f8jeblikket vokser SberMarket 13 gange \u00e5r for \u00e5r, og dette p\u00e5virker produktet, da det kr\u00e6ver konstant at \u00f8ge m\u00e6ngderne og udviklingstempoet. P\u00e5 trods af dette afs\u00e6tter vi tilstr\u00e6kkelig tid til udviklerne til foranalyse og kvalitetskodning. Den etablerede tilgang hj\u00e6lper ikke kun i skabelsen af et fungerende produkt, men ogs\u00e5 i dets videre skalering og udvikling. Som resultat af denne v\u00e6kst er SberMarket allerede blevet en leder blandt tjenester til levering af dagligvarer: vi leverer dagligt omkring 18.000 ordrer om dagen, selvom der i begyndelsen af februar var omkring 3500.<\/p>\n

\"Hvordan
\nEn gang bad en kunde SberMarket-kureren om at levere dagligvarer til ham kontaktl\u00f8st - direkte p\u00e5 balkonen.<\/i><\/p>\n

Men lad os komme til sagen. I de seneste par m\u00e5neder har vi aktivt arbejdet p\u00e5 at skalere vores virksomheds infrastruktur. Behovet for dette skyldtes b\u00e5de eksterne og interne faktorer. Samtidig med udvidelsen af kundebasen er antallet af tilknyttede butikker steget fra 90 i starten af \u00e5ret til mere end 200 i midten af maj. Vi forberedte os selvf\u00f8lgelig ved at reservere den grundl\u00e6ggende infrastruktur og regnede ogs\u00e5 med muligheden for b\u00e5de vertikal og horisontal skalering af alle virtuelle maskiner placeret i Yandex's cloud. Men erfaringen viste, at alt, hvad der kan g\u00e5 galt, vil g\u00e5 galt. Og i dag vil jeg dele nogle af de mest interessante situationer, der opstod i l\u00f8bet af disse uger. Jeg h\u00e5ber, at vores erfaringer vil v\u00e6re nyttige for dig.<\/p>\n

Slave er i fuld beredskab<\/h3>\n

\nAllerede f\u00f8r pandemiens begyndelse oplevede vi en stigning i foresp\u00f8rgslerne p\u00e5 vores backend-servere. Tendensen til at bestille produkter med hjemlevering begyndte at tage fart, og med indf\u00f8relsen af de f\u00f8rste selv-isoleringsforanstaltninger i forbindelse med COVID-19, voksede belastningen dramatisk i l\u00f8bet af dagen. Der opstod et behov for hurtigt at aflaste master-serverne i den prim\u00e6re database og overf\u00f8re en del af l\u00e6seforesp\u00f8rgslerne til slave-replikaservere.<\/p>\n

Vi forberedte os p\u00e5 dette skridt i god tid, og for at kunne foretage et s\u00e5dant man\u00f8vrer var der allerede sat 2 slave-servere i drift. Disse servere blev prim\u00e6rt brugt til batch-opgaver med generering af informationsfeeds til datadelingspartnere. Disse processer skabte un\u00f8dig belastning og blev helt berettiget flyttet \"uden for boksen\" et par m\u00e5neder tidligere.\u00a0<\/p>\n

Da der fandt replikation sted p\u00e5 Slave, overholdt vi konceptet om, at applikationerne kun kunne arbejde med dem i read only-tilstand. Disaster Recovery Planen foruds\u00e5, at i tilf\u00e6lde af en katastrofe kunne vi blot montere Slave p\u00e5 pladsen for Master og omdirigere alle skrive- og l\u00e6seforesp\u00f8rgsler til Slave. Men vi \u00f8nskede ogs\u00e5 at bruge replikaterne til analytiske behov, s\u00e5 serverne blev ikke helt overf\u00f8rt til read only-status, og hver v\u00e6rt havde sit eget s\u00e6t brugere, hvoraf nogle havde skriveadgang til at gemme mellemresultaterne af beregningerne.<\/p>\n

Indtil et bestemt niveau af belastning havde vi nok kapacitet i b\u00e5de l\u00e6sning og skrivning ved behandling af http-foresp\u00f8rgsler. I midten af marts, lige da Sbermarket besluttede at g\u00e5 helt over til remote arbejde, begyndte vi at opleve en markant stigning i RPS. Flere og flere af vores kunder gik i selvisolering eller arbejdede hjemmefra, hvilket p\u00e5virkede belastningsniveauerne.<\/p>\n

Ydelsen fra \"master\" blev ikke l\u00e6ngere tilstr\u00e6kkelig, s\u00e5 vi begyndte at flytte nogle af de tungeste l\u00e6seforesp\u00f8rgsler til en replika. For at transparent styre foresp\u00f8rgsler til skrivning til master og l\u00e6sning til slave, brugte vi ruby gem \"Octopus<\/a><\/noindex>\". Vi oprettede en speciel bruger med suffikset _readonly uden skriveadgang. Men p\u00e5 grund af en fejl i konfigurationen af en af v\u00e6rterne, blev nogle skrivesp\u00f8rgsler sendt til slave-serveren i navnet p\u00e5 en bruger, der havde de relevante rettigheder.<\/p>\n

Problemet viste sig ikke straks, da den \u00f8gede belastning fik slaverne til at h\u00e6nge efter. Datainkonsistens blev opdaget om morgenen, da slaverne ikke havde \"indhentet\" master efter natlige importer. Vi tilskrev dette den h\u00f8je belastning p\u00e5 selve tjenesten og importen forbundet med opstarten af nye butikker. Men at levere data med flere timers forsinkelse var uacceptabelt, og vi omdirigerede processerne til den anden analytiske slave, da den havde st\u00f8rre ressourcer og ikke var belastet af l\u00e6seforesp\u00f8rgsler (hvorfor vi ogs\u00e5 forklarede for os selv, at der ikke var lag i replikationen).fleste af<\/strong>Da vi fandt frem til \u00e5rsagerne til \"udvidelsen\" af hoved-slaven, var den analytiske allerede ude af drift af samme \u00e5rsag. P\u00e5 trods af at vi havde to ekstra servere, som vi planlagde at flytte belastningen til i tilf\u00e6lde af masterfejl, viste det sig, at der i kritiske \u00f8jeblikke ikke var nogen.<\/p>\n

Men da vi ikke kun lavede dump af databasen (gendannelsen p\u00e5 det tidspunkt tog omkring 5 timer), men ogs\u00e5 snapshot af master-serveren, lykkedes det at starte replikationen inden for 2 timer. Dog ventede vi efter dette p\u00e5 at n\u00f8dvendigg\u00f8re replikationsloggen i en l\u00e6ngere periode (fordi processen k\u00f8rer i en enkelttr\u00e5d, men det er en helt anden historie).<\/p>\n

Men da vi ikke kun lavede en dump af databasen (gendannelsen tog omkring 5 timer p\u00e5 det tidspunkt), men ogs\u00e5 en snapshot af master-serveren, lykkedes det at starte replikatet inden for 2 timer. Dog ventede der os derefter en langvarig rulling af replikationsloggen (fordi processen k\u00f8rer i en enkelttr\u00e5det tilstand, men det er en helt anden historie).<\/p>\n

Output:<\/strong> Efter en s\u00e5dan h\u00e6ndelse blev det klart, at vi skulle opgive praksis med at begr\u00e6nse skrivning for brugere og erkl\u00e6re hele serveren som readonly. Med denne tilgang kan vi v\u00e6re sikre p\u00e5, at replikaerne vil v\u00e6re tilg\u00e6ngelige p\u00e5 kritiske tidspunkter.<\/p><\/blockquote>\n

<\/p>\n

Optimering af selv \u00e9n tung foresp\u00f8rgsel kan \"bringe databasen tilbage til livet\".<\/h3>\n

\nSelvom vi konstant opdaterer kataloget p\u00e5 hjemmesiden, havde de foresp\u00f8rgsler, vi sendte til slave-serverne, en lille forsinkelse i forhold til master. Den tid, det tog at opdage og l\u00f8se problemet med de \"pludselig ude af drift\" slaver, var l\u00e6ngere end den \"psykologiske gr\u00e6nse\" (i mellemtiden kunne der v\u00e6re blevet opdateret priser, og kunderne ville have set for\u00e6ldede data), og vi blev n\u00f8dt til at omdirigere alle foresp\u00f8rgsler til den prim\u00e6re databaser server. Som f\u00f8lge heraf k\u00f8rte hjemmesiden langsomt... men den k\u00f8rte i det mindste. Og mens slaverne blev genoprettet, havde vi ikke andet valg end at optimere.\u00a0<\/p>\n

Mens slave-serverne blev genoprettet, trak minutterne sig langsomt, master forblev overbelastet, og vi kastede alle kr\u00e6fter ind p\u00e5 at optimere aktive opgaver i henhold til \"Pareto-reglen\": vi valgte de top-foresp\u00f8rgsler, der gav den st\u00f8rste del af belastningen, og begyndte tuning. Dette blev gjort direkte \"on the fly\".<\/p>\n

En interessant effekt var, at en overbelastet MySQL reagerer selv p\u00e5 ubetydelige forbedringer i processerne. Optimering af et par foresp\u00f8rgsler, som kun gav 5 % af den samlede belastning, viste allerede en m\u00e6rkbar lettelse af CPU'en. Som f\u00f8lge heraf lykkedes det os at sikre et acceptabelt ressourceoverskud til Master's arbejde med databasen og f\u00e5 den n\u00f8dvendige tid til at genoprette replikaerne.\u00a0<\/p>\n

Output:<\/strong> Selv en lille optimering g\u00f8r det muligt at \"overleve\" ved overbelastning i flere timer. Det var pr\u00e6cis, hvad vi havde brug for under genoprettelsesprocessen for serverne med replikaer. Forresten vil vi diskutere den tekniske del af optimering af foresp\u00f8rgsler i et af de kommende indl\u00e6g. S\u00e5 husk at abonnere p\u00e5 vores blog, hvis det kan v\u00e6re nyttigt for dig.<\/p><\/blockquote>\n

<\/p>\n

Organiser overv\u00e5gning af partner-tjenesternes funktionalitet.<\/h3>\n

\nVi h\u00e5ndterer kundeordrer, og derfor interagerer vores tjenester konstant med tredjeparts-API'er - det er gateways til at sende SMS'er, betalingsplatforme, routing-systemer, geokodere, FNS-tjenester og mange andre systemer. Og da belastningen begyndte at stige hurtigt, begyndte vi at st\u00f8de p\u00e5 begr\u00e6nsningerne fra API'erne hos vores partner-tjenester, som vi ikke tidligere havde t\u00e6nkt p\u00e5.<\/p>\n

Uventede overskridelser af kvoterne for partnerskaber kan f\u00f8re til nedetid for din egen service. Mange API'er blokerer kunder, der overskrider gr\u00e6nserne, og i nogle tilf\u00e6lde kan et overskud af foresp\u00f8rgsler overbelaste produktionen hos partneren.\u00a0<\/p>\n

For eksempel, da antallet af leveringer voksede, kunne de tilknyttede tjenester ikke h\u00e5ndtere distributionen og rutebestemmelsen. Resultatet blev, at ordrer blev afgivet, men tjenesten, der skabte ruten, ikke fungerede. Det skal siges, at vores logistikere gjorde det n\u00e6sten umulige under disse forhold, og et klart samarbejde i teamet hjalp med at kompensere for de midlertidige fejl i tjenesterne. Men en s\u00e5 h\u00f8j m\u00e6ngde foresp\u00f8rgsler kan ikke behandles manuelt konstant, og efter et stykke tid ville vi have st\u00e5et over for en uacceptabel kl\u00f8ft mellem ordrer og deres opfyldelse.\u00a0<\/p>\n

Der blev truffet en r\u00e6kke organisatoriske foranstaltninger, og et velfungerende team hjalp os med at vinde tid, mens vi indgik nye aftaler og ventede p\u00e5 modernisering af tjenesterne fra visse partnere. Der findes ogs\u00e5 andre API'er, der imponerer med h\u00f8j udholdenhed og urimelige takster ved h\u00f8j trafik. For eksempel brugte vi i starten et velkendt kort-API til at bestemme leveringsadressen. Men i slutningen af m\u00e5neden modtog vi en regning p\u00e5 n\u00e6sten 2 millioner rubler. Derefter besluttede vi hurtigt at erstatte det. Jeg vil ikke lave reklame, men jeg vil sige, at vores omkostninger blev betydeligt reduceret.
\n\"Hvordan<\/p>\n

Output: <\/strong>Det er n\u00f8dvendigt at overv\u00e5ge driftbetingelserne for alle partnerskaber og have dem i mente. Selv hvis det i dag synes, at de er \"med stor margen\", betyder det ikke, at de i morgen ikke kan blive en hindring for v\u00e6ksten. Og selvf\u00f8lgelig er det bedre at forhandle om finansielle betingelser for de \u00f8gede foresp\u00f8rgsler til tjenesten p\u00e5 forh\u00e5nd.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Nogle gange viser det sig, at \u201cman har brug for mere guld<\/a><\/noindex>\u201d (c) ikke hj\u00e6lper<\/h3>\n

\nVi kender til \"flaskehalse\" i den prim\u00e6re database eller p\u00e5 applikationsservere, men ved skalering kan problemerne vise sig der, hvor man mindst forventer dem. Til fuldtekst s\u00f8gning p\u00e5 vores hjemmeside bruger vi Apache Solr. Med stigende belastning bem\u00e6rkede vi en nedgang i svartiden, og serverens CPU-belastning n\u00e5ede op p\u00e5 100%. Hvad kan v\u00e6re enklere \u2014 vi giver Solr-containeren flere ressourcer.<\/p>\n

I stedet for det forventede l\u00f8ft i ydeevnen, \"d\u00f8de\" serveren bare. Den blev straks belastet op til 100% og svarede endnu langsommere. Oprindeligt havde vi 2 kerner og 2 GB RAM. Vi besluttede at g\u00f8re det, som normalt hj\u00e6lper \u2014 vi gav serveren 8 kerner og 32 GB. Alt blev meget v\u00e6rre (hvordan og hvorfor, vil vi fort\u00e6lle i et separat indl\u00e6g).\u00a0<\/p>\n

Efter et par dage havde vi forst\u00e5et detaljerne i sp\u00f8rgsm\u00e5let og opn\u00e5et optimal ydeevne med 8 kerner og 32 GB RAM. Denne konfiguration g\u00f8r det muligt stadig at forts\u00e6tte med at \u00f8ge belastningen, hvilket er meget vigtigt, fordi v\u00e6ksten ikke kun sker i antallet af kunder, men ogs\u00e5 i antallet af tilsluttede butikker \u2014 inden for 2 m\u00e5neder er deres antal fordoblet.\u00a0<\/p>\n

Output: <\/strong>Standardmetoder som \"tilf\u00f8j mere hardware\" virker ikke altid. S\u00e5 ved skalering af enhver service er det vigtigt at forst\u00e5, hvordan den bruger ressourcer, og p\u00e5 forh\u00e5nd teste dens ydeevne under nye forhold.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 n\u00f8glen til enkel horisontal skalering<\/h3>\n

\nGenerelt f\u00f8lger vores team den kendte tilgang: tjenester skal v\u00e6re stateless og uafh\u00e6ngige af k\u00f8rselmilj\u00f8et. Dette gjorde det muligt for os at h\u00e5ndtere v\u00e6ksten i belastningen med simpel horisontal skalering. Men vi havde \u00e9n undtagelse i servicen \u2013 en behandler for lange baggrundsopgaver. Den h\u00e5ndterede afsendelse af e-mails og sms'er, behandling af events, generering af feeds, import af priser og lagre samt behandlingen af billeder. Det viste sig, at den var afh\u00e6ngig af lokal filopbevaring og kun eksisterede i \u00e9t eksemplar.\u00a0<\/p>\n

Da antallet af opgaver i behandlingsk\u00f8en steg (hvilket naturligt skete med stigningen i antallet af bestillinger), blev v\u00e6rtens ydeevne, hvor b\u00e5de behandlingssystemet og filopbevaringen var placeret, en begr\u00e6nsende faktor. Dette resulterede i, at opdateringen af sortimentet og priserne, samt udsendelsen af notifikationer til brugerne, stoppede, og mange andre kritiske funktioner sad fast i k\u00f8en. Ops-teamet migrerede hurtigt filopbevaringen til en S3-lignende netv\u00e6rkslagring, hvilket gjorde det muligt for os at finde flere kraftfulde maskiner til at skalere baggrundsbehandleren.<\/p>\n

Output: <\/strong>Reglen om Stateless skal overholdes for alle komponenter uden undtagelse, selvom det virker som om 'her vil vi bestemt ikke st\u00f8de ind i problemer'. Det er bedre at bruge lidt tid p\u00e5 korrekt organisering af arbejdet for alle systemer, end hastigt at gen skrive koden og reparere en tjeneste, der oplever overbelastning.<\/p><\/blockquote>\n

<\/p>\n

7 principper for intensiv v\u00e6kst<\/h2>\n

\nP\u00e5 trods af tilg\u00e6ngeligheden af ekstra kapaciteter, l\u00f8b vi ind i flere forhindringer under v\u00e6ksten. I denne periode er antallet af bestillinger steget med mere end 4 gange. Vi leverer nu over 17.000 bestillinger om dagen i 62 byer og planl\u00e6gger at udvide geografien endnu mere \u2014 i f\u00f8rste halv\u00e5r af 2020 forventes starten af en tjeneste over hele Rusland. For at kunne h\u00e5ndtere den voksende belastning, med hensyn til de allerede gjorde erfaringer, har vi formuleret 7 grundprincipper for at arbejde under konstant v\u00e6kst:<\/p>\n

    \n
  1. Incident Management<\/strong>. Vi har oprettet et board i Jira, hvor hver h\u00e6ndelse afspejles i form af en ticket. Dette vil hj\u00e6lpe med effektivt at prioritere og udf\u00f8re opgaver relateret til h\u00e6ndelsen. I bund og grund er det ikke skr\u00e6mmende at lave fejl \u2014 det skr\u00e6mmer at lave de samme fejl to gange. I de tilf\u00e6lde, hvor h\u00e6ndelser gentager sig, f\u00f8r vi kan rette \u00e5rsagen, skal der v\u00e6re en handlingsinstruktion klar, da det er vigtigt at reagere lynhurtigt under h\u00f8j belastning.<\/li>\n
  2. Overv\u00e5gning <\/strong>kr\u00e6ves for alle elementer i infrastrukturen uden undtagelse. Netop takket v\u00e6re det kunne vi forudsige belastningsv\u00e6ksten og korrekt v\u00e6lge 'flaskehalse' til prioritering af afhj\u00e6lpning. Sandsynligvis vil alt, hvad du ikke havde t\u00e6nkt p\u00e5, g\u00e5 i stykker eller begynde at h\u00e6nge ved h\u00f8j belastning. Derfor er det bedst at oprette nye alarmer straks efter de f\u00f8rste h\u00e6ndelser for at overv\u00e5ge og forudse dem.<\/li>\n
  3. Korrekte alarmer<\/strong> er helt n\u00f8dvendige ved pludselige belastningsstigninger. For det f\u00f8rste skal de informere om, hvad der pr\u00e6cist er g\u00e5et i stykker. For det andet, der m\u00e5 ikke v\u00e6re for mange alarmer, da en overflod af ikke-kritiske alarmer f\u00f8rer til, at alle meddelelser ignoreres helt.<\/li>\n
  4. Applikationer skal v\u00e6re stateless. <\/strong>Vi har konstateret, at der ikke b\u00f8r v\u00e6re undtagelser fra denne regel. Der er brug for fuld uafh\u00e6ngighed fra k\u00f8remilj\u00f8et. Til dette kan du gemme delte data i en database eller f.eks. direkte i S3. Og endnu bedre at f\u00f8lge reglerne https:\/\/12factor.net<\/a><\/noindex>. Under en pludselig stigning i belastningen er der ikke tid til at optimere koden, og man m\u00e5 h\u00e5ndtere belastningen ved direkte at \u00f8ge beregningsressourcerne og implementere horisontal skalerings.<\/li>\n
  5. Kvoter og ydeevne fra eksterne tjenester. <\/strong>Ved hurtig v\u00e6kst kan problemet ikke kun opst\u00e5 i din infrastruktur, men ogs\u00e5 i den eksterne tjeneste. Det mest frustrerende er, n\u00e5r det sker ikke p\u00e5 grund af en fejl, men p\u00e5 grund af n\u00e5ede kvoter eller gr\u00e6nser. S\u00e5 eksterne tjenester skal kunne skalere lige s\u00e5 godt som dig selv.\u00a0<\/li>\n
  6. Opdel processer og k\u00f8er. <\/strong>Det hj\u00e6lper meget, n\u00e5r der opst\u00e5r flaskehalse p\u00e5 en af gatewayene. Vi ville ikke have oplevet forsinkelser i datatransmissionen, hvis fyldte SMS-udsendelsesk\u00f8er ikke havde forstyrret udvekslingen af meddelelser mellem informationssystemerne. Og det ville v\u00e6re lettere at \u00f8ge antallet af arbejdere, hvis de arbejdede separat.<\/li>\n
  7. Finansielle realiteter.<\/strong> N\u00e5r datastreams eksploderer, er der ikke tid til at t\u00e6nke p\u00e5 takster og abonnementer. Men de skal huskes, is\u00e6r hvis du er en lille virksomhed. En stor regning kan komme fra ejeren af enhver API, samt din hostingudbyder. S\u00e5 det er vigtigt at l\u00e6se kontrakterne grundigt.<\/li>\n<\/ol>\n

    <\/p>\n

    Konklusion<\/h2>\n

    \nIkke uden tab, men vi har overvundet denne fase, og i dag str\u00e6ber vi efter at f\u00f8lge alle de fundne principper, mens hver maskine har mulighed for nemt at \u00f8ge ydeevnen med op til 4 gange for at h\u00e5ndtere uventede situationer.\u00a0<\/p>\n

    I de kommende indl\u00e6g vil vi dele vores erfaring med at unders\u00f8ge fald i ydeevne i Apache Solr, samt tale om optimering af foresp\u00f8rgsler og hvordan samarbejdet med skattemyndighederne hj\u00e6lper virksomheden med at spare penge. Tilmeld dig vores blog for ikke at g\u00e5 glip af noget, og fort\u00e6l os i kommentarerne, om du har oplevet lignende problemer under stigninger i trafik.<\/p>\n

    \"Hvordan<\/p>\n

    Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

    Har du oplevet forsinkelse\/nedbrud af tjenesten ved pludselig stigning i belastningen p\u00e5 grund af:<\/h2>\n