Ytelsestest av Optimizely løsning

[borresundberg]

Description

Ny Optimizely DXP løsning må ytelsestestes. Det er flere aspekter som må avklares:

• hva skal ytelsestesten dekke? I første omgang vil vi teste antall sidevisninger pr sek. Kan starte med et mål om 500 pr.sek
• Skyløsningen har autoskalering, bør kanskje testes med "kald" rigg og "forhåndsoppvarmet" rigg // Dette punktet utgår da RP viste seg å ha ytelsesproblemer: Det må etableres reverse-proxy rigg i YT-miljøet - bestilling er sendt til Orange

Additional Information

Før yt-test kan starte, må følgende være på plass:

• reverse proxy
• funksjonelle feil være utbedret (https://github.com/Altinn/altinn-infoportal-optimizely/issues/4)

Tasks

No response

Acceptance Criterias

No response

[HenningNormann]

Testcase:

• Kall til / og /no/
• Varighet 10 minutter
• Lineær ramp up første 7 minutter
• Forventet resultat (fra eksisterende system): Throughput på 1400 hovedrequests per sekund (700 til / og 700 til /no/)

Kjøring 1, 15. september 12:34:14-12:44:14 - normal konfig med reversy proxy

• Stabil throughput på ca 70+70/s fra 3 minutter. Ingen økning under videre ramp up
• Responstider på ca 150ms på hovedrequests
• Oppsummert: stabilt men bare 10% throughput i forhold til eksisterende system

Kjøring 2, 15. september 13:31:27-13:41:27 - uten reverse proxy, direkte mot https://prod.altinn.cloud

• Som kjøring 1 bortsett fra:
• Feil (http 403) på alle dependent requests fra 7 minutter. Gjelder requests mot /Static og /bundles

[oyvindwh]

Vi er i dialog med Managed Services for å klargjøre til ytelsestest av Optimizely. Et par steg må gjøres i forkant.

• Jørgen må bekrefte WAF bypass reglene. Planlagt ferdig på mandag 18.09
• Task #13 må fikses slik at vi får logging i Application Insight. Planlagt ferdig fredag 15.09.
• Fra Managed Services: Please provide our team times (and time zone) for the scaling to be started/turned off

[oyvindwh]

prod.altinn.cloud er klar for ytelsestest fra i morgen onsdag kl.09.00 til torsdag kl.16.00. Trenger vi mer tid så si fra om det. Trenger vi mer ytelse så kan vi også si fra om det. Lurt å se i Application Insight samtidig som testen kjører for å se cpu / memory etc. mens testen pågår.

[oyvindwh]

Scale up of resources for digi02mstrcmw56prod has been completed. WAF Skip rule "ZD 1238566 Skip" on altinn.cloud Zone has been enabled as well.

[HenningNormann]

@oyvindwh @borresundberg Det virker ikke som waf regelen funker. Får samme feil som før (403) etter 2,5 minutt. (Kjøring startet 20.09.2023 09:40:59)

[oyvindwh]

@HenningNormann , hvilken ip adresse kjøres testen fra? VI har lagt inn ip adressene som testen ble kjørt fra 15.09.

[oyvindwh]

Ipadressen som er åpnet for: 89.250.125.7

[HenningNormann]

Det ser riktig ut

[oyvindwh]

From Managed Services:

We've reviewed the WAF logs. During the test there was a total of 572k requests that the WAF took action on. However, it all came in from the same IP but was handled in two different ways,

390k was met with a challenge, 182k was allowed due to the bypass rule that was setup.

The rule/service that started challenging these requests was a HTTP DDoS service. Which has a higher priority in the Cloudflare hierarchy, we'd have to get an override in place for that if these test are to be completely bypassed/allowed. Which requires an escalation to our Reliability Engineering team. We'll start the process now and will update you as soon as we've received feedback.

[oyvindwh]

I used a tool called Netling (https://github.com/hallatore/Netling) to do a simple loadtest to prod.altinn.cloud, this was the result.

1925 request/second from my computer.

[HenningNormann]

@oyvindwh Setter du opp en ny SSL forbindelse for hver request? Jeg tror det er der flaskehalsen ligger.

Vår test simulerer nettverksbruken til en vanlig bruker og nettleser. Scriptet itererer (i parallell) over følgende:

• Request / (vil alltid medføre en ny connection)
• Hent alt som refereres (css, js, grafikk osv) fra response i forrige punkt) (Vil simulere nettleser ved å bruke opp mot 6 connections i parallell)
• Request /no/ (vil typisk gjenbruke connection fra pool trigget i punktene over)
• Hent alt som refereres (ref. beskrivelse over)

Det er scriptet over som får throughput 91/s. Det er altså mange flere basis requests per sekund.

[oyvindwh]

Har purret Managed Services for å få satt opp bypass på statiske ressurser.

[oyvindwh]

Flytter ticketen til @HenningNormann da fokuset til ytelsestesten er nå på BigIp og Nginx.