When Kika gently weeps

[kristjanjansen]

Koormus ja jõudlus

Meie populaarsus tõuseb päev-päevalt, kui pool aastat tagasi kui sai tehtud hinnangud vajalikule stackile oli meie koorumus 1-2 rps (requests per second), neist ca 80% anonüümsed kasutajad, siis praegu naeme tihedamatel tundidel 5100 rph (requests per hour). Statistiliselt teeb see küll 1.4 rps kuid peak'id v6ivad olla 10 rps ja palju rohkemgi.

Load testing

Web tools:

• http://loader.io Vajab authentimist, st serveris peab olema kindla nimega fail kattesaadav. Ilmselt on m6istlik teha spetsiaalne route ja .env failis anda ette vastav parameeter a la get('/{env('LOADERIO_ID')}.txt') vms Vaja teha issue

Command line tools

• ab
• siege Vaja kirjutada juhised

  Cache

  HTTP server cache

Vaja otsustada HTTP server cache tyyp ja teha arendus

HTTP server cache on mõeldud anonüümsete, sisselogimata kasutate jaoks (Sisseloginud kasutajate jaoks tuleb midagi juba Laravelis endas teha). Kontrollimata andmetel on enamus meie FB kampaaniate aegsest loadist anonüümsed kasutajad, st HTTP server cache on ilmselt üsna mõistlik.

Siin on mitu varianti:

Varnish cache

Meil on Laravelis Varnishi suppordiks teatud töö juba tehtud :

• Me saadame vastavad cache headerid: https://github.com/tripikad/trip2/blob/master/app/Http/Controllers/FrontpageController.php#L109
• Meil on (kergelt toores) Varnish conf olemas mida tuleb uuendada, puhastada ja testida https://github.com/tripikad/trip2_vagrant/blob/master/trip2.vcl. Viimane testimine ca 6 kuud tagasi toimis, välja arvatud Laraveli redirectid mis andsid http 500 staatuskoodi https://github.com/tripikad/trip2_vagrant/issues/24
• Kuna Laravel saadab iga requestiga valja paar cookiet mida Varnish ei salli, siis meil on middleware, mis saadav välja spetsiaalse http headeri https://github.com/tripikad/trip2/blob/master/app/Http/Middleware/AuthenticatedHeader.php#L19 mida siis Varnish puhul kontrollitakse ja cookied kustutatakse https://github.com/tripikad/trip2_vagrant/blob/master/trip2.vcl#L48
• Varnishi cachet saab Laraveli seest värskendada https://github.com/lhj1982/Acetone, see kood on kirjutamata ja vastavat issuet veel ei ole

Plussid:

• + Väga populaarne
• + Efektiivne anonüümsetele kasutajatele
• + (Loodetavasti) lihtne cache värskendamine

Miinused:

• - Kui tahame edaspidi HTTPSi ja HTTP/2 peale minna siis on see raskendatud, Varnish toetab neid minimaalselt, sisuliselt on vaja kolmekihilist server setuppi: request--->nginx1=>varnish=>nginx2--->response

  Nginx microcache

On olemas Varnishist lihtsam variant, Nginxi cache https://github.com/tripikad/trip2_vagrant/issues/23 mis teeks serverisetupi edaspidi lihtsamaks: request--->nginx--->response

Plussid:

• + HTTP/2 ja HTTPS peale minek (loodetavasti) väga lihtne

Miinused:

• - Vähe infot, vähe kasutatud
• - Ilmselt vajab cachefailide jaoks mäluketta tegemist
• - Cache värskendamine ebaselge ja nõuab spetsarendust (tuleb vist kustutada õige fail sügaval failisüsteemis)

  Response cache

https://github.com/spatie/laravel-responsecache

See on küll Laraveli lisajubin, kuid peaks umbes samamoodi töötama kui eelmised

Plussid:

• + Servericonf jääb ära
• + Lubatakse cacheda ka sisselogind kasutajad, vähemalt paberil

Miinused:

• - Kiirel esimesel testimisel ei andnud efekti (võis olla ka testimise viga)
• - Olemuslikult ei saa olla nii kiire kui eelmised lahendused

  Laraveli sisemine cache

Vaja otsustada kohad kus kasutada Laraveli sisest cachet

Järgmine cache kiht on Laraveli cache. Praegu me seda peaaegu ei kasuta, välja arvatud keerukate queryte cache siin-seal (ja vist ka Atom feed?) Siin on aga palju võimalusi, saaks cacheda rohkem päringuid, html jupikesi kui ka suuremaid regioone.

Vaja otsustada cache draiver

Oluline on ka cache draiver. Stagingus ja laivis saaks kasutada kas Redise või Memcachedi cachet (filecache puhul ei saa teatuid cache APIsid kasutada ja andmebaasicache on liigne overhead).

Redis

Plussid:

• + Jooksutame ilmselt nagunii (queued, edaspidi ka websockets)

Miinused:

• - Kas me liiga palju ei ehita yhe teenuse peale?

  Memcache

Plussid:

• + Hajutab survet Redisele

Miinused:

• - Lisab keerulisust
• - Vajab eraldi serveri setuppi

  Frontend optimizations

Vaja teha minimaalsed frontendi kiirustestid ja siis otsustada palju optimeerida

Praegu me siin palju ei tee https://github.com/tripikad/trip2/issues?q=is%3Aopen+is%3Aissue+label%3Aperformance kuid siin oleks vaga palju kiiruste tõstmise võimalusi.

Turvalisus

Serveri turvaconf

Vaja uuendada serveri conf

Meie serveriskript https://github.com/tripikad/trip2_vagrant/blob/master/provision.sh ei ole piisavalt turvaline, vt https://github.com/tripikad/trip2_vagrant/issues/4

Kasutajate passwordide hashing

Vaja otsustada paroolide hashing

Praergu me kasutame kasutajate paroolide salastamiseks väga nõrka, md5() krüptimist sest me tahame et vana Tripi kasutajad saaks probleemideta sisse logida. Selleks on kirjutatud oma custom hasher https://github.com/tripikad/trip2/blob/master/app/Hashers/Md5Hasher.php

See võib olla turvarisk. Kui tugevama, bcrypt() krüptimise jaoks peavad kõik vanad kasutajad oma paroolid ära muutma ning ilmselt tuleb neile kõigile ka vastav paroolivahetuse e-mail saata ja see nõuab oskuslikku e-maili saatmise lahendust (kasutajaid on kokku 42k, saata tuleks vast 10k-20k'le)

Oluline küsimus on kas teha uuele tripile yleminek koos paroolivahetusega ja tegeleda lisaarenduse + kasutajatyytamisega või lükata see kuskile ebamäärasesse tulevikku (kus korraga on saidis nii ebaturvalised kui turvalised paroolid, brrr).

Vt https://github.com/tripikad/trip2/issues/3

HTTP/2 ja HTTPS üleminek

Vaja otsustada KUNA tegeleda HTTP/2 ja HTTPSiga

Ei ole esmase launchi jaoks kriitilised, kuid poole aasta perspektiivis võiks siiski lauale tõsta. HTTP/2 annab (loodetavasti) kiirust juurde, HTTPS on H/2 eeltingimus ning lisab turvalisust ning seda on nüüd tänu letsencrypt.org'ile lihtne käima ajada. Forge, vt allpool, teeb seda automaatselt.

Niipea kui trippi (taas)tekivad maksvad kommertskasutajad, on HTTPS kohustuslik.

Vt ka

http://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https https://ma.ttias.be/firefox-nightly-starts-marking-login-forms-in-http-as-insecure/

Meie issued:

https://github.com/tripikad/trip2_vagrant/issues/26 https://github.com/tripikad/trip2_vagrant/issues/25 https://github.com/tripikad/trip2_vagrant/issues/32

Deploy

Vaja otsustada deploy tehniline lahendus

Deploy on automaatne Gihubist värkse koodi võtmine ja test/stagingu ja live serverisse panemine. Meil on mitu varianti:

Isetehtud deploy:

Võtame olemasoleva deployskripti https://github.com/tripikad/trip2_vagrant/blob/master/scripts/update_code.sh ja paneme selle lihtsa NodeJS teenuse abil jooksma iga kord kui keegi Githubis midagi uuendab.

Plussid:

• • kiire, lihtne ei sõltu kellestki

Miinused:

• - deploy skript asub samas masinas kui deploytakse. Kui see maha kukub?
• - rollback ja multi-server käib meile üle jõu

  Envoyeri deploy

$10/kuu

https://laracasts.com/series/envoyer

Plussid

• Võimaldab rollbackida ebaõnnestunud deploysid
• Deploy ajaks ei pea saiti offlinesse panema
• Deployda saab mitmesse serverisse korraga

Miinused

• Kulu
• Mõnda aega tagasi ei töötanud teenus pool nädalat sest Linode USA datacenterile tehti DDoS rünnak
• Arendab üks bizi mees, hobikorras, teenus ei arene

  Serveri haldus

Vaja otsustada serveri haldaja

Kaks varianti:

A: Haldame ise

Spinnime serveri üles oma skriptiga https://github.com/tripikad/trip2_vagrant/blob/master/provision.sh mis põhineb Forge skriptil https://github.com/laravel/settler/blob/master/scripts/provision.sh

Plussid

• + Kokkuhoid
• + Sõltumatus

Miinused

• - Turvariskid
• - Pidevalt vaja servereid tundvaid ja valdavaid inimesi

  Forge

$10/kuu

https://laracasts.com/series/server-management-with-forge

Plussid

• + Ei pea oskama Linuxi serverit installida
• + Automaatne SSL

Niijanaa

• ~ Forge ei paku küll automaatseid turvaparandusi, kuid seal saab kergesti kergesti turvalisust tõstvaid skripte jooksutada
• ~ Võimaldab ka automaatset deployd kuid tunduvalt piiratumat kui Envoyer

Miinused

• - skriptide jooksutamine on väga tüütu ja aeglane (skript output tuleb vaid e-maili peale)
• - Varnishit ei ole (küll aga saab muuta Ngixi confi st saaks kasutada Nginxi turva)
• - Arendab üks bizi mees, hobikorras, teenus ei arene

  Muud teemad

  Serverid ja hinnad

Vaja otsustada mitut ja milliseid servereid esialgu jooksutame

Hetkel:

• Live: Linode 4GB $40/kuu, Trip maksab
• Staging: Linode 2GB $20/kuu, Kika maksab

Launchi ajal:

• Live: Linode 4GB $40/kuu, Trip maksab
• Staging: Linode 2GB $20/kuu (või Linode 1GB $10/kuu või Linode 4GB $40/kuu), Trip maksab
• Vana Trip: Kas me jätame selle käima? Hea oleks Linode 2GB $20/kuu aga kettamaht on ilmselt probleem, võib olla vajalik Linode 4GB $40/kuu

Ilmselt peame populaarsuse kasvades minema multiserver setupi peale:

Tulevik A:

• 1 web + 1 DB/Redis

Tulevik B:

• 1 loadbalancer, 2 web, 1 db/Redis + image CDN

Selleks on vaja välja mõelda, kus me hoiame kasutajasessioone, pilte ja cachet.

Fotod

Vaja liigutada pildid ja asi ara testida

Eelmisega võrreldes mitte nii oluline teema kuid natuke siiski: kui me tahame kasutada Envoyeri automaatset deployd, siis on meil vaja liigutada praegused pildid uude kataloogi https://github.com/tripikad/trip2/issues/269. See annaks ka võimaluse edaspidi pilte mõnest muust serverist / CDNist serveerida ja minna üle multi-server setupile. Probleemiks võib siin saada Windowsi all arendamine (Mikk), ma ei tea kuidas see tema masinas toimiks.

Sessioonid

Vaja otsustada kus hoida sessioone

Samuti multi-server setupi puhul ei saa sessioone hoida veebiserveris failidena, nad peavad olema kas Redises või Memcachedis (andmebaas on liiga suur overhead)

Email

Vaja leida meiliprovaider

Mailiprovideri valimisel tekkis vist arusaamatus. Teemaks ei olnud newsletterite saatmine (Mailchimp) vaid transactional email, mida pakuvad tihti newsletterite saatjad, kuid eraldi nime all, eraldi APIdega ja eraldi hinnaga. Me peame valima Mandrilli (by Mailchimp), Mailguni ja CampaignMonitori vahel https://github.com/tripikad/trip2/issues/98

Reklaam

Vaja leida reklaami tehniline lahendus ja see ara testida

Vaja on kiiremas korras mingit näidisreklaami et saaks hakata reklaamikasutust testima, näiteks Google Doubleclick for Publishers https://www.google.com/dfp

[mikkpokk]

Ausalt öeldes ma tahaks teada, mis laadimisaeg praegusel tripil on (päringud ja üldine). Arvestades, et praegune trip on vanal drupalil siis ma arvan, et ega see tegelt süsteemi poolest väga kiire ei ole. Meie suurim murekoht hetkel minu silmis ongi frontendi laadimisaeg (pildid, skriptid, olematu apache conf) ja päringute ülesehitus.

• Pildid ära optimeerida - kasutada pngquanti näiteks ja jpegtrani - vajab serverisse installimist (sama lahendust kasutab tinypng.com, kus saab testida, kui võimas tool see on)
• Css/js minify. Ideaalne, kui saaks js ja css failid teha iga vaate jaoks eraldi. Praegusel juhul tõmbad 509KB jsi browserisse + 222KB cssi - vaates kasutatakse sellest 5-10% ja iga refreshi / lingile minekuga laetakse need uuesti alla
• Failide/HTML'i gzipimine
• HTML minify - meil see html ülipikk ja väga palju spacingut ja nodi sees. Gzip + minify = kiirem laadimisaeg
• Cache

See, mis koormab serverit rohkem (laraveli enda out of the box seda ei tee) on mysql päringud / üldine süsteemi ülesehitus. Need tuleb kompaktsemaks ajada, mõni ULME päring korda teha. Vältida ühe vaate ajal päringute kordamist. Võtta ühe päringuga välja võimalikult palju ja töödelda, kus mis kuidas alles koodis. Hakkan selle osaga peagi ise tegelema.

Võin päris kindel olla, et kui need punktid ära teha siis laadimisaeg tuleb sama või isegi parem kui trip.ee-l. Jah, tööd sellega palju.

Tõsi, kui kõik jätta nii nagu on siis serveri boostimisega kõva peavalu :) Aga alustama peaks ikkagi sealt, kus viga tekib.

Märkuseks 1: Baum pole kena asi mida kasutada, kui otsid kiirust taga Märkuseks 2: HTTPS võtab tegelt kiirust maha mitte ei too juurde (küll mitte palju jah), aga aastal 2016 on see ikka must-have :) Kui turvalisus ei mängi rolli siis otsingupositsioon võiks ikka mängida.

[kristjanjansen]

Paar märkust:

• Kiirust toob juurde HTTP/2, maha võtab HTTPS. Kas nad ka üksteist tasandavad, saab näha. Nginxil on küll HTTP/2 tugi aga mitte eriti neid osi mis kiirust lisab (server push). Alternatiivsetel serveritel a la H2O pole jälle erilist cachemist.
• Kas meil on reaalselt PNGsid mida optimeerida? JPGga on teine lugu, seal annaks teha küll. kõige efektiivsem on kasutada midagi sellist: https://github.com/tripikad/trip2/issues/189 Lisaks võib ka CDNi kasutamine efekti anda...aga võibolla ei tasu setupi keerukus / arendus end ära.
• CSS-JS minification, muidugi, seda pole siiani lihtsalt arendusmugavuse pärast. Ilmselt tuleb gulpfile nii ümber töötada et oleks eri buildid gulp dev ja gulp production siis vastavalt ilma ja koos minificationiga.
• HTML minification https://github.com/GrahamCampbell/Laravel-HTMLMin
• Gzipping tuleb Ngixi confis teha https://mattstauffer.co/blog/enabling-gzip-on-nginx-servers-including-laravel-forge ning lisaks ka http cache header staatilistele assetitele
• Mis sa "olematu apache conf" all silmas pead kui meil on kõik Nginxile orienteeritud? Sa mõtled oma Windowsi confi?

[mikkpokk]

Minu viga, ei teadnud et nginx server, eeldasin et apache/linux.

Kuniks png, jpeg, jpg formaadid on lubatud piltide lisamiseks tasub png ka teha. Tõsiasi muidugi see, et PNG pilti annab kõvasti väiksemaks optimeerida kui jpeg/jpg. Ehk on üldse teemaks, et jpg/jpeg algselt tehakse pngks ja seejärel pngquantist läbi? Tulemuseks ainult optimeeritud png pildid serveris.

Pngquant annab väga head tulemust PNG piltide puhul, jpegtran võtab mahtu küll maha, aga mitte märkimisväärselt. Olen varasemalt teinud katsetuse, kus 1=1 pildi olen salvestanud jpeg formaati kui ka png formaati. Järgmiseks lasknud jpeg jpegtranist läbi ja png pnquantist. Kaalukalt võitjaks jäänud png nii kvaliteedi kui ka mahu poolest.

[kristjanjansen]

@mikkpokk "Baum pole kena asi mida kasutada, kui otsid kiirust taga " -- on sul alternatiive?

[mikkpokk]

@kristjanjansen Teen varsti alternatiivmeetodi. 1 query - töötleme array'id.

[kristjanjansen]

Ma enam ei nuta. Paneme kinni.