Scala veebiarendajad ei arvesta sageli tagajärgedega, kui tuhanded kasutajad samal ajal meie rakendustele juurde pääsevad. Võib-olla sellepärast, et meile meeldib kiiresti prototüüpida; võib-olla sellepärast, et selliste stsenaariumide testimine on lihtsalt raske .

Vaatamata sellele väidan, et mastaapsuse ignoreerimine pole nii hull, kui see kõlab - kui kasutate õigeid tööriistu ja järgite häid arendamistavasid.

Skaalautuvuse ignoreerimine pole nii hull, kui see kõlab - kui kasutate õigeid tööriistu.

Lojinha ja näidend! Raamistik

Mõni aeg tagasi alustasin projekti Lojinha (tõlkes portugali keeles 'väike pood'), oma katset ehitada oksjonisait. (Muide, see projekt on avatud lähtekoodiga ). Minu motivatsioon oli järgmine:

• Tahtsin väga müüa mõnda vana kraami, mida ma enam ei kasuta.
• Mulle ei meeldi traditsioonilised oksjonisaidid, eriti need, mis meil siin Brasiilias asuvad.
• Tahtsin koos mänguga 'mängida' Mängi! Raamistik 2 (sõnamäng mõeldud).

Nii et ilmselgelt, nagu eespool mainitud, otsustasin kasutada Mängi! Raamistik . Mul pole täpset arvu, kui kaua selle ehitamine aega võttis, kuid kindlasti ei läinud kaua aega enne, kui olin oma saidi üles seadnud ja töötanud lihtsa süsteemiga, mis oli juurutatud http://lojinha.jcranky.com . Tegelikult kulutasin vähemalt poole arendusajast disainile, mis kasutab Twitteri alglaadimine (pidage meeles: ma pole disainer ...).

Eespool olev lõik peaks vähemalt ühe asja selgeks tegema: ma ei muretsenud jõudluse pärast liiga palju, kui üldse Lojinha loomisel.

Ja see on täpselt minu mõte: õigete tööriistade kasutamine - tööriistad, mis hoiavad teid õigel teel, on tööriistad, mis julgustavad järgima parimaid arendustavasid juba oma konstruktsioonilt.

Sel juhul on need tööriistad Play! Raamistik ja Skala keel , koos Akka mõned külalisesinemised.

Las ma näitan sulle, mida ma mõtlen.

Muutmatus ja vahemällu salvestamine

Üldiselt ollakse nõus, et mutatiivsuse minimeerimine on hea tava. Lühidalt, muutlikkus muudab teie koodi mõistmise raskemaks, eriti kui proovite kehtestada mis tahes paralleelsust või samaaegsust.

Play! Scala raamistik paneb suure osa ajast kasutama muutumatust ja nii ka Scala keel ise. Näiteks kontrolleri genereeritud tulemus on muutumatu. Mõnikord võite seda muutumatust pidada 'häirivaks' või 'tüütuks', kuid need 'head tavad' on põhjusel 'head'.

Sel juhul oli kontrolleri muutumatus absoluutselt ülioluline, kui otsustasin lõpuks mõned jõudlustestid läbi viia: avastasin kitsaskoha ja parandasin selle muutumatu vastuse lihtsalt vahemällu.

Kõrval vahemällu salvestamine , Ma mõtlen vastuse objekti salvestamist ja identse eksemplari teenimist, nagu see on, kõigile uutele klientidele. See vabastab serveri tulemuse uuesti arvutamisest. Kui see tulemus oleks muudetav, ei oleks võimalik sama vastust pakkuda mitmele kliendile.

Negatiivne külg: lühikese aja jooksul (vahemälu aegub) saavad kliendid vananenud teavet. See on probleem ainult stsenaariumides, kus kõige värskematele andmetele juurdepääsuks on klient kindlasti vajalik, ilma et viivitused oleksid lubatud.

Viitamiseks on siin Scala kood, mis laadib avalehe koos toodete loendiga ilma vahemällu salvestamata:

def index = Action { implicit request => Ok(html.index(body = html.body(Items.itemsHigherBids(itemDAO.all(false))), menu = mainMenu)) }

Vahemälu lisades:

def index = Cached('index', 5) { Action { implicit request => Ok(html.index(body = html.body(Items.itemsHigherBids(itemDAO.all(false))), menu = mainMenu)) } }

Päris lihtne, kas pole? Siin, 'Register' on vahemälusüsteemis kasutatav võti ja 5 on aegumisaeg sekundites.

hankige kuupäev ja kellaaeg javascript

Pärast vahemällu salvestamist tõusis läbilaskevõime kuni 800 taotlust sekundis. See on vähem kui kahe koodirea parandamine rohkem kui 4x.

Selle muudatuse mõju testimiseks tegin mõned JMeteri testid (mis sisalduvad GitHubi repos) kohapeal. Enne vahemälu lisamist saavutasin umbes 180 taotlust sekundis. Pärast vahemällu salvestamist tõusis läbilaskevõime kuni 800 taotlust sekundis. See on enam kui 4x vähem kui kahe koodirea jaoks.

Mälu tarbimine

Teine valdkond, kus õiged Scala tööriistad võivad suurt midagi muuta, on mälu tarbimine. Siin jälle Play! lükkab sind õiges (skaleeritavas) suunas. Aastal Java maailmas tavalise veebirakenduse jaoks, mis on kirjutatud servleti API (st peaaegu kõik sealsed Java või Scala raamistikud), on väga ahvatlev kasutaja seanssi palju rämpsposti panna, kuna API pakub hõlpsasti helistavaid meetodeid, mis võimaldavad teil seda teha:

session.setAttribute('attrName', attrValue);

Kuna kasutaja seansile on nii lihtne teavet lisada, kuritarvitatakse seda sageli. Selle tagajärjel on liiga suure mälu kasutamise põhjuseta põhjuseta oht võrdselt kõrge.

Play! raamistik, see pole valik - raamistikul pole lihtsalt serveripoolset seansiruumi. Play! raamistiku kasutaja seanssi hoitakse brauseri küpsises ja peate sellega elama. See tähendab, et seansi ruumi suurus ja tüüp on piiratud: saate salvestada ainult stringe. Kui peate objekte hoiustama, peate kasutama vahemälumehhanismi, mida me eelnevalt arutasime. Näiteks võiksite sessiooni salvestada praeguse kasutaja e-posti aadressi või kasutajanime, kuid peate vahemälu kasutama, kui peate oma domeenimudelist salvestama terve kasutajaobjekti.

Mängi! hoiab teid õigel teel, sundides teid hoolikalt kaaluma oma mälukasutust, mis annab praktiliselt klastrivalmis esimese käigu koodi.

Jällegi võib see esialgu tunduda piin, kuid tegelikult mängige! hoiab teid õigel teel, sundides teid hoolikalt arvestama oma mälukasutusega, mis annab praktiliselt klastrivalmis esmakordse koodi - eriti arvestades, et pole serveripoolset seanssi, mida oleks vaja kogu klastris levitada, muutes elu lõpmatult lihtsam.

Asünkroonimise tugi

Järgmine selles näidendis! raamistiku ülevaatamisel uurime, kuidas Play! särab ka asünkroonis (hronoosses) toes. Ja peale oma loomulike omaduste, Play! võimaldab teil kinnistada Akka , võimas asünkroonitöötluse tööriist.

Altough Lojinha ei kasuta veel Akka täielikku eelist, selle lihtsat integreerimist Playga! tegi selle väga lihtsaks:

1. Plaanige asünkroonne e-posti teenus.
2. Protsessi pakkumised erinevatele toodetele samaaegselt.

Lühidalt öeldes on Akka programmi rakendamine Näitleja mudel kuulsaks teinud Erlang . Kui te pole Akka Actori mudeliga tuttav, kujutlege seda lihtsalt väikese üksusena, mis suhtleb ainult sõnumite kaudu.

E-kirjade asünkroonseks saatmiseks koostan kõigepealt õige sõnumi ja näitleja . Siis on mul vaja ainult midagi sellist:

EMail.actor ! BidToppedMessage(item.name, itemUrl, bidderEmail)

E-kirjade saatmise loogika on rakendatud näitleja sees ja sõnum ütleb näitlejale, millise e-kirja me soovime saata. Seda tehakse tule ja unustamise skeemis, mis tähendab, et ülaltoodud rida saadab päringu ja jätkab seejärel selle täitmist, mis meil pärast seda on (st see ei blokeeri).

Play! Emakeelse Asynci kohta lisateabe saamiseks vaadake ametlik dokumentatsioon .

Järeldus

Kokkuvõtteks: töötasin kiiresti välja väikese rakenduse, Pood , mis on võimeline väga hästi suurendama ja suurendama. Kui mul tekkis probleeme või avastasin kitsaskohti, olid parandused kiired ja lihtsad ning tänu kasutatavatele tööriistadele (Play !, Scala, Akka ja nii edasi), mis sundis mind järgima parimaid tavasid tõhususe ja mastaapsus. Vähese murega jõudluse pärast suutsin skaalata tuhandete samaaegsete taotlustega.

Järgmise rakenduse väljatöötamisel kaaluge hoolikalt oma tööriistu.