Debat
Hej Vi kører betatest på et caching system til SSL, prøv denneher https://www.simplesolution.dk/ på f.eks pingdom og se en responstid :-) Mvh WebHosting A/S |
Hej Dette er en frontend cache man smider i fronten af sit webhotel, ikke en backend cache, der er forskel. Mvh WebHosting A/S |
|
Jo men det har servere som LiteSpeed haft i langtid, og FastCGI Cache, samt Squid, et setup kan sågar også laves med Varnish som desværre ikke understøtter HTTPS i sig selv, så det kræver en front-end så som eks. nginx til at proxy videre, gættede nu heller ikke på det var backend cache. |
Hej Lige netop, og det er rimeligt nemt at lave hvis du har din egen server/vps, det er således ikke det vi taler om her da det jo netop er et modul man kan tilknytte som så kører som en layer 7 SSL termination proxy foran webserver (shared system uden at kende backend CMS). Har du et eksempel på en server der kører f.eks LiteSpeed og SSL, kunne være sjovt at teste responstiden. Mvh WebHosting A/S |
Jeg er ikke sikker på jeg forstår relevansen, men jeg mistænker at du stadig holder på at SSL er et performance downgrade som bør behandles? Jeg testede dit site på pingdom som du sagde: http://i.imgur.com/bCVskNm.png - umiddelbart synes jeg ikke 1.75 sekunder er meget imponerende, men du har også knap 13 MB data der skal indlæses, så det kan jo nemt være en forklaring. Du er velkommen til at teste https://simplenps.io også - her er mit eget resultat: http://i.imgur.com/amS1sia.png - her bruger jeg også væsentligt mindre data og forespørgsler end du gør. Det jeg til gengæld synes der er mere interessant er den reelle implementering. Hvis du tester din SSL implementering på SSLLabs.com, får du den laveste karakter mulig: https://www.ssllabs.com/ssltest/analyze.html?d=www.simplesolution.dk - det har ingen indvirkning på hastigheden, men det fortæller lidt om implementeringens sårbarheder. Min egen implementation kan testes her: https://www.ssllabs.com/ssltest/analyze.html?d=simplenps.io |
PHP Freelancer med speciale i Laravel og API integrationer
Valg af ciphers har faktisk stor indvirkning på hastigheden, jo flere bits du har jo længere tid tager det for CPUen at lave dit handshake og generelt med encryption og decryption af dine data - det er ikke uden grund at man oftest vælger EECDH ciphers med en lavere kryptering over en række ældre ciphers - fordi EECDH bringer samme eller højere sikkerhed, selv ved 128 bit encryption sammenlignet med ældre normale RSA 256 bit encryption, så ikke nok med det er samme sikkerhed eller bedre, så er det også langt hurtigere CPU mæssigt at lave disse - og det kan have kæmpe betydning i et miljø med en hel del trafik. Et meget godt eksempel ved at gå fra et ikke gennemtænkt cipher-suite til et der prioritere EECDH-AES128 - på en box med en hel del trafik:
Og selvfølgelig ved stadig at have en god score på SSL labs :-) |
Hosting4Real - High performance webhoteller.
Når jeg lige tænker mig om, så ved jeg jo godt at det er tilfældet - kryptering har altid været resourcekrævende, naturligvis. Det var lige en tankeprut fra min side. Det skal ikke forstås sådan at jeg betvivler at det faktisk har et performance impact, mit postulat er blot at for en gennemsnitlig webshop eller blog, så er det nok ikke noget som man vil bemærke hverken som besøgende eller ejer af sitet. |
PHP Freelancer med speciale i Laravel og API integrationer
Hej Vi tog faktisk cachen af tidligere igår da der var et mindre problem, responstid var under 0.2 sekunder, på regner at sætte det på igen sandsynligvis imorgen, kigger lige dine, men ved ikke hvad der ligger bag, kan du beskrive dette? Mvh Supporten
|
Hej Satte cache på igen, dette er resultatet af en pingdom test (andet forsøg så det er cached)
Sitet tager 1.5 sek ca, men har også en video og en del embedded materiale fra eksempelvis facebook. Synes det er ret imponerende. Mvh WebHosting A/S
|
Bliv gratis medlem
Opret bruger
