GAE / Google App Engine - Ohjelmistokehitys

[Sami Lehtinen]

Päädyin tässä tekemään tällaisen testisovelluksen, joka kelpaa kyllä tuotantokäyttöön asti: Off The Record Messaging.

Tietokantayhteydet ja kaikki muukin sujui tuolla GAE alustalla uskomattoman helposti. Ainoastaan Pythonin 2 version merkistökonversiot ja erilaisten kirjastojen tavat ottaa dataa vastan tuottivat ajoittain päänsärkyä. Kokonaisuudessaan kävi helposti ja on toiminut sen jälkeen luotettavasti.

Onkos kukaan muu foorumilainen tuupannut tuonne mitään joka on tsekattavissa ja mitkä ovat olleet kehittäjien kokemukset kyseisestä ympäristöstä.

Seuraavaksi voisi kokeilla miten hyvin tuon saman softan saa pyörimään omalla koneella käyttäen opensource AppScale ympäristöä.  Sattuisiko kenelläkänä olemaan siitä kokemusta? Toinen vaihtoehto on TyphoonAE, mutta siitä ei näytä olevan oikein mitään kokemuksia vielä. Tuntuu siltä, että molemmat on melkoisen keskeneräisiä. Joskin AppScalen kehitys on selvästi tutkimuksen kohteena. Sekä AppScalesta on paljon laadukasta dokumentointia.

Linkkivinkki:
GAE = Google AppEngine linkki lisätty.

P.S. Jos sinulla on kokemuksia noista ympäristöistä, niin palautetta otetaan oikein mielellään vastaan. Näyttää kuitenkin siltä, että hyvää informaatiota on mahdotonta saada, ellei ota ja rakenna täyttä testiympäristöä itse.

KW: Google App Engine, pilvipalvelut, pilvipalvelu, SaaS, PaaS, Amazon EC2, GAE, cloud computing, TyphoonAE, AppScale.

Hmm. viestiketjuille ei näköjään saa määriteltyä avainsanoja.

EDIT: lisätty TyphoonAE

EDIT: Kiteytin hieman kokemuksiani tähän postaukseen. How to avoid Google App Engine Gotchas.

[Tomin]

Onkos kukaan muu foorumilainen tuupannut tuonne mitään joka on tsekattavissa ja mitkä ovat olleet kehittäjien kokemukset kyseisestä ympäristöstä.

Oli.

Aika jännä idea ja varmaan joissain tilanteissa jopa käytännöllinen. Kivasti toteutettu, vaikka tuo logo on vähän epäselvä (rakentavaa palautetta).

[Sami Lehtinen]

Aika jännä idea ja varmaan joissain tilanteissa jopa käytännöllinen. Kivasti toteutettu, vaikka tuo logo on vähän epäselvä (rakentavaa palautetta).

Logosta voi varmasti olla montaa mieltä. Samoin sivuston väreistä on tullut palautetta. Sivut on kuulemma  niin kasaria. Varmasti ovat. Tarkoitus on ollakkin kun olen tällainen retroilija.

Seuraavaksi voisi siirtää omat sivut varmaan Google Sites palvelusta tuonne, kasomalla jonkun sopivan GAE alustalla pyörivän Wikin tai CMS-ratkaisun. Kävin muutaman läpi mutta mitään sopivan kätevää ei helposti löytynyt. Miksi turhaan maksaa hostingista, kun Google tarjoaa ilmaisen, tehokkaan, maailmanlaajuisen ja varmennetun CDN-ratkaisun.

Google Sites on superhelppo tapa perustaa sivusto ja siksi olen sen nykyiseksi ratkaisuksi valinnut. Kaipaisin kuitenkin enemmän mahdollisuuksia sivuston ulkonäkökontrolleihin mitä Google Sites sallii. Ottamalla jonkun kevyen Wikin ja puukottamalla vähän sourcea saisi ihan haluamansa näköisen lopputuloksen. Mutta tuskin on vaivan arvoista tässä käyttötarkoituksessa.

Linkkivinkki:
GuteCMS sivun kautta pääsee GAE CMS asiassa alkuun. Sivulla on myös linkkejä useisiin muihin samoihin tavoitteisiin pyrkiviin projekteihin.

[Tomin]

Aika jännä idea ja varmaan joissain tilanteissa jopa käytännöllinen. Kivasti toteutettu, vaikka tuo logo on vähän epäselvä (rakentavaa palautetta).

Logosta voi varmasti olla montaa mieltä. Samoin sivuston väreistä on tullut palautetta. Sivut on kuulemma  niin kasaria. Varmasti ovat. Tarkoitus on ollakkin kun olen tällainen retroilija.

Niin no... http://validator.w3.org/check?uri=http%3A%2F%2Foff-the-record.appspot.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

[Sami Lehtinen]

Uudelleen formatoituna ja postattuna, yhdistin viestini yhdeksi artikkeliksi.

Niin no... http://validator.w3.org/check?uri=http%3A%2F%2Foff-the-record.appspot.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

Kieltämättä aika mielenkiintoista, että puolet virheistä oli noiden leikkaa ja liimaa laajennusten aiheuttamia. Esim. Google Analytics ja AddThis.

Myös suoraan Google Sites palveluun Wikinä toteutetut kotisivuni eivät läpäise testiä. Huomatuksena voisin sanoa että Google Sites palvelussa en pysty mitenkään vaikuttamaan sivujen HTML rakenteeseen. Kaikki tulee suoraan WYSIWYGINÄ kun naputtelen tekstin sivuille. Tästä herää suuri kysymys, onko Googlen porukka epäpätevää vai onko validaattori päässyt vanhentumaan? Mainittakoon että myös www.google.com ei läpäise testiä.

Mielestäni validaattorin voi ainakin jollain tasolla kyseenalaistaa. Tarkistin ~20 suosittua sivustoa sillä, eikä yksikään mennyt läpi tarkastuksesta virheittä.

OTR sivusto on myös testattu Firefoxilla, Skyfirellä, Opera Minillä, S60 OSS Browserilla, Operalla, Internet Explorer 8:lla ja on toiminut kaikilla moitteitta, kuten on tarkoitus. Myös käyttämäni formi kikkailu jossa sivu skaalataan sopivaksi ruudulle myös pystysuunnassa on toiminut. Vaikka se ei välttämättä ole standardein mahdollinen ratkaisu. CSS:n puolelta voisi löytyä paljon korrektimpi vaihtoehto nykyaikana.

Toisaalta erilaiset layout kikkailut sotivat perusajatustani vastaan. Mitä yksinkertaisempaa ja selkeämpää, sitä parempaa. Turhat CSS ja flash pelleilyt ja muut roskat pois ja sivustojen selkeys, nopeus ja käytettävyys paranee usein olennaisesti. Valitettavasti nykyinen kehityssuunta webin suhteen tuntuu johtavan johonkin aivan muualle.

Voisin joskus tuunata periaatteen vuoksi tuo sivuston kuntoon. Joskin se vaatisi ylitsepursuavaa pilkuviilaus energiaa.

Kotisivullani muotoilu on aikalailla hassua Googlen toimesta. S60 browserilla (3rd edition) sivusto näkyy siten, että vasen menu on normaalikokoinen ja sitten oikealla puolella oleva teksti rivittyy todella lyhyiksi riveiksi. Sivusta tulee erittäin pitkä ja usein riville mahtuu vain yksi sana. Mobiili päätteitä varten pitäisi suosilla tehdä oma XHTML MP sivusto. mm. Yahoo näyttää kunnostautuneen tämän asian osalta. Useimmista palveluista löytyy erinomaiset XHTML MP versiot.

Löysin sivuston joka on suosittu ja menee läpi tarkistuksesta. Se on Wikipedia. Epäilinkin, että tuolla porukalla voisi olla sitä tarvittavaa pilkuviilaus energiaa tarvittavissa määrin. Joskin tuo sivu johon tässä viittasin, ei mene läpi varoituksitta. Mutta englanninkielinen etusivu menee.

OTR sivustolla taustakuva ja logo ovat todellakin tarpeettoman raskaita. Ne voisi korvata kevyemmällä mustalla taustalla ja tiukasti pakatulla JPEG logolla. Nykyiset graafiset komponentit ovat PNG muodossa. Myös bittejä on turhan paljon käytössä / pikseli, jos viilaamaan ruvetaan. Tiedostan kuvien olevan isoja ja siksi olen asettanut niille vuoden TTL:n. Mikäli tietoja ei poisteta selaimen välimuistista, ei kyseisiä kuvia tarvitse ladata uudelleen tai edes tarkistaa ovatko ne päivittyneet. Jos muutan kuvia olennaisesti julkaisen uudella osoitteella.

Huviskeen voisi katsoa kuinka monella web-sivustolla jokaisen komponentin cache parametrit mm. TTL on asetettu järkevästi ja tarjotaanko myös etag:ia, onko http:n kanssa gzip/deflate pakkaus käytössä, onko tukea keep-alivelle ja pipeliningille. Sekä tietysti mikäli sivustolla käytetään käyttäjätunnuksia ja salasanoja pitäisi HTTPS olla jatkuvasti käytössä. Samalla voi tarkistaa onko SSL session resume / cache käytössä. Jos ei ole, suorituskyky laskee olennaisesti.

Mitä tuli vielä tuohon ettei mene validaattorista läpi, niin mainittakoon että sentään merkistöt toimivat moitteitta sivustolla.

Olen törmännyt viimeaikoina useisiin Web-sivustoihin joissa merkistöt on pielessä. mm. http://www.sofia.fi/ Kun vaihdat selaimen oletusmerkistön joksikin kummalliseksi, alat huomaamaan pian että monilla sivustoilla merkistöasiat eivät ole kunnossa. Käytettävä merkistö pitäisi aina ilmoittaa.

http://www.huuto.net/ palvelussa on myös vastaavia ongelmia.

JavaScriptin kanssa ei tietenkään ole mitään ongelmia eri selaimilla, eihän. Aika epäkiitollisena voisin tuota hommaa pitää.

http://www.jumbofiles.com/ download ei toimi Chromella tai Operalla.

Niin no... http://validator.w3.org/check?uri=http%3A%2F%2Foff-the-record.appspot.com%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

Totta se turisee, ei mene läpi validoinnista mutta toimii kaikilla testaamillani selaimilla mainiosti. Kotin äsken laittaa sivuston kuntoon ja korjata tuon taulukoon perustuvan virityksen CSS:llä. Noin kahden tunnin manaamisen jälkeen totesin että ei taida olla vaivan arvoista. Pitänee yrittää myöhemmin uudelleen. Näyttää siltä että CSS ihmiset tekevät juuri sen perusvirheen, eli tekevät sivuston aina jollekkin tietylle pikseli korkeudele tai leveydelle. Henkilökhotaisesti pidän tuota suunnitteluvirheenä. Oikein tehty sivusto muovautuu erilaisille näytöille aivan hyvin. Optimi tilanteessa sivustosta on vielä eri versiot riippuen käytettävästä selaimesta.

Verkkosivustoja testaavia palveluita on verkko pullollaan:
http://www.webpagetest.org/result/100411_6W5K/1/performance_optimization/

Juuri mainitsemani etagit ja cache-expiret puuttuvat aika monelta komponentilta. CDN jakelu staattiselle sisällölle puuttuu. Koska TTL / expire arvot eivät ole kunnossa, tulee turhia kyselyitä  staattiseen sisältöön koska selain ei tiedetä onko sisältö muuttunut vai ei.

Mutta muuten tuo http://www.webpagetest.org/ on kyllä mainio palvelu. Tuosta ETagin käytöstä on useita mielipiteitä. Riippuu nimittäin taas palvelinalustasta toimiiko ETag hyvin. Optimi tilanteessa revalidointi aika on ilmoitettu. Tai vaihtoehtoisesti ETag on olemassa. Mutta jotkut suosittelee että ETagia ei käytetä, koska ETagin generointi on usein serveri kohtaista ja klusteroidussa ratkaisussa tämä voi johtaa turhiin uudelleen latauksiin. Staattisen sisällön kanssa siis ei kannattaisi käyttää ETagia vaan riittävän pitkää TTL / revalidate / expire aikaa ja kokonaan uutta polkua jos sisältö muuttuu. Tietysti ratkaisusta riippuen ETag voidaan järjestää samaksi myös klusteroidussa ratkaisussa jolloin sen käyttö on suositeltavaa myös expiren lisäksi. Tämä tilanteissa joissa ei voida ennakoida sisällön päivittymistä ja refreshiä ei voi tehdä järkevästi esim. 5 minuutin välein.

Lopuksi pakko todeta, että kaiken kuntoon sätämisessä ja laittamisessa on ihan uskomattomasti duunia. Olisi hauska nähdä tilastoja, onko edes 1% web-sivustoista ns. hyvässä kunnossa. Todennäköisesti ei ole. Useimmat eivät tiedä, eivätkä ymmärrä ja nekin jotka tietää, niin eivät todennäköisesti välitä.

Ja hyvää välipalaa iltalukemiseksi: http://developer.yahoo.com/performance/rules.html

Palataanko sitten sovelluskehitykseen ja GAE alustasta keskustelemiseen HTTP/HTML/CSS/JS aiheen sijasta. Niistä on nimittäin pitkät turinat monessa foorumissa.

P.S. Jos jostain löytyy referenssi miten body-tagin stylellä saa koko sivun sisällön keskitettyä sen kuten se on nyt keskitettynä taulukkoa käyttäen, niin otan mielelläni vastaan. Se on myös syy miksi DOCTYPE määrittely puuttuu OTR sivustolta. Jos lisään doctypen sinne, nykyinen table height="90%" valign="middle" ratkaisu lakkaa toimimasta. Kaikki validaattorin ilmoittamat virheet on korjattu, poislukien tuo puute ja "plugin" komponenttien tuomat virheet.

[Sami Lehtinen]

Viikonloppuna oli tylsää. Tein URL Shortenerin / Osoitteenlyhentäjän App Enginelle.

http://9ox.net/

Domaini lainattu pitkäaikaiselta frendiltä, en jaksanut rekisteröidä omaa. Tällä hetkellä beta-versio, joten jos bugaa jotenkin hämärästi niin tiedätte ketä syyttää. Seuraavana projektina CSS3 facelift noille, kun tekniikka on todettu kerran toimivaksi. Pitäisi olla aika helppo homma kun otin kerran templatet käyttöön, eli HTML / web roina on täysin eristettynä koodista.

Palautetta saa pistää. Osoitteet on rajattu max 3 merkkiin, sen jälkeen tulee tyly ilmoitus siitä että url pooli on täynnä. Vanhenemisen ehtoina on joko 31 päivää käyttämättömänä tai 365 päivää julkaisusta. Laskelmani mukaan tuonne sopii siis 238328 osoitetta. Silloin viimeinen osoite on http://9ox.net/ZZZ

Syynä tekemiseen oli opiskelu. Kun kerran opiskelen jotain, miksen tekisi saman tien verisiota joka on yleisesti käytettävissä. Nyt on Google App Enginen transaktiot ja database-sharding tms. hallussa.

App Enginen dev_appserver toimii ikävästi eri tavalla mm. datastoren suhteen kuin tuotantoympäristö. Eka versio jonka julkaisin läpäisi kaikki testit testiympäristössä, mutta kun siirsin sen tuotantoon alkoi ongelmat. Ikäväkseni totesin, että ID kentät eivät etene yhtenäisessä sarjassa tuotannossa. Testiympäristössä kaikki toimi täydellisesti. Nyt on toteutettuna globaalisti synkronoitu laskuri uusille allokoitaville osoitteille. Shardattuna ja transaktio pohjaisena.

[Sami Lehtinen]

Vielä yksi ongelma tuli korjattua tuota.

Syystä tai toisesta App Enginen self.redirect(_url-string_) funktio ei tue UTF-8 merkistö ollenkaan, vaan vaatii että sisältö on ASCIIna. Oli pakko tehdä tosi fiksu veto ja implementoida http-equiv redirect niihin tilanteisiin jolloin URL sisältää unicode merkkejä.

Älytöntä? Kyllä.
Toimiiko? Kyllä.

Jos ei toimi tavalla, niin sitten toimii toisella.

[mrl586]

Miksi ASCII-merkistön ulkopuoliset merkit tulisi sallia URI:ssa?

[Sami Lehtinen]

Miksi ASCII-merkistön ulkopuoliset merkit tulisi sallia URI:ssa?

Hyvä kysymys, mutta kun sellaisia sivustoja vaan on.

Esimerkisi:
1) http://ä-neukölln.de/
2) http://en.wikipedia.org/wiki/%C3%84

Nuo poimin logeista koska olivat johtaneet käsittelemättömään poikkeukseen koodissa.

Alkoi sen verran ottamaan noi spammerit pannuun, että lisäsin myös kohdesivuston WOT rating tarkistuksen koodiin.

Eipä muuten tämä foorumin URL-tunnistin osannut laittaa oikein tuota esimerkkiä 1.

Sitten vielä ihmetellään miten niin monta systeemiä on rikki, kun ihmiset tekevät virheellisiä olettamuksia. Testasin kasan URL-lyhentäjiä ja suurin osa ei toiminut oikein tuolla 1. esimerkillä. goo.gl ja bit.ly toimi, mutta muut eivät käytännössä toimineet.

Kertokaa ihmeessä jos olen missannut jotakin. Selaimet kyllä sallivat edelleenohjauksen osoitteisiin joissa on unicode-merkkejä.

Edit: Eipä näköjään tämä foorumikaan tunnista http://ä-neokölln.de/ osoitetta urliksi ilman erillisten url tagien käyttöä.

[mrl586]

IDN:t voi esittää myös ASCII-muodossa: http://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode

[Sami Lehtinen]

IDN:t voi esittää myös ASCII-muodossa: http://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode

Kiitokset!

Katsoin tuota urlia ja selvähän se, onhan noista puhuttu ja nähty. Ei vaan juuri ongelmaan törmätessä tullut muistista mitään vastausta. Ehdottivat myös stackoverflowssa http-equiv metan:n käyttämistä, joka on todellakin hölmö ratkaisu.

Kiitokset vihjauksesta, laitoin sen sittenkin sinne kun kävi niin nopeasti kun tiesi mitä etsi.

EDIT:

Helpompi ja parempi vaihtoehto encodings.idna.ToASCII(u'ÖÄÅöäå') -> u'ÖÄÅöäå'.encode('idna')

Lisäsin tässä samalla myös eventual consistent tilan, jossa kantaa voidaan lukea tarpeen vaatiessa muulta kuin master database serveriltä. Pitäisi riittää varsin hyvin redirectien tarpeeseen. Joskus GAE alustalla on ollut tietokanta tahmaa, tuo samalla toivottavasti vähentää sitäkin ongelmaa. 99% tietokannan käytöstä kun on kuitenkin lukuja.

[Sami Lehtinen]

Näköjän keskusteluun ei ole tullut päivityksiä.

Otetaan seuraavat asiat esille Google App Enginen osalta koska ne ovat melkoisen tärkeitä.

Google App Enginen hinnasto uusittiin. Tämä johtuu lähinnä siitä, että palvelu alkaa olemaan valmis ja menettää beta statuksen.

Muutamia lievennyksiä hinnastoon. Ilmainen palvelu saa pyöriä 28 tuntia vuorokaudessa, joten se kestää pienet ylitykset yhdestä instanssista. Tuo on hyvä asia, koska aikaisemmin jos sattui tulemaan pyyntöjä siten, että palveluun käynnistyi kaksi instanssia, tuli palveluun jossain vaiheessa vuorokaudessa väkisin katko, ellei palvelusta makseta.

Mielenkiintoista tuo uudessa hinnastossa oleva ajattelumallim, jossa ennakkoon varatut palvelinresurssit (instanssit) ovat 37,5% halvempia kuin on-demand resurssit. Tuo tavallaan taistelee koko maksa käytön mukaisesti ajattelua vastaan.

9ox.net URL lyhennin on toiminut nyt melkoisen hyvin tuolla. Suurimmat haasteet on aiheuttaneet link-spammerit, joita vastaan on pitänyt ruveta taistelemaan useilla erilaisilla tekniikoilla. Nykyisin tarkistan URLin domainin arvostukset WOT:ista. Kuitenkin venäläiset spammerit rekisteröi kasoittain uusia domaineita, tekee niille heti lyhennykset ja alkaa spammaamaan myöhemmin. Tuolla tavoin pyrkivät kiertämään kohde domainin arvostuksen romahduksesta johtuvia ongelmia ja sysäämään ne lyhennyspalvelun niskaan. (mm. spam emailit)

Tämän vuoksi jouduin muuttamaan palvelua niin, että jokaisen domainin arvostus tarkistetaan uudelleen kerran 24 tunnissa. Näin spam-domaineiksi merkityt domainit putoavat tietokannasta ja memcache välimuistista viimistään 24 tuntia alkuperäisen lisäämisen jälkeen. Tämä tietenkin heikentää hieman vähemmän käytettyjen lyhenteiden ohjausaikaa, koska uuden hinnaston mukaisella toimintamallilla en voi käyttää ilmaisessa palvelussa taustaprosesseja noiden asioiden hoitamiseen. Vaan ne suoritetaan samanaikaisesti itse ohjauksen suorittamisen kanssa. Toisaalta tämä johtaa myös aukottomaan tarkistukseen, eli edes yhtä käyttäjää ei ohjata tunnettuun spam-urliin. Taustaprosessilla ohjaisin käyttäjän ensin kohde urliin ja tarkistaisin urlin statuksen myöhemmin ja sitten mitätöisin sen cachesta ja tietokannasta.

Onkos täällä ketään muita jotka ovat väilleet mitään pientä testisettiä tuonne palveluun tai ottaneet sen jopa tuotantokäyttöön.

[Sami Lehtinen]

Muutamiin App Enignen rajoituksiin olen tuossa törmännyt. mm. DNS tietoja ei pysty mitenkään noutamaan App Enginellä, käyttämättä erillistä omaa Web service DNS proxyä.

Pystyttelin tuossa huvikseni kaksi DNS proxyä;
1) Debian, Nginx, uWSGI ja Python 2.7.1+ paketilla sekä kirjoittamallani pienellä proxy softalla.
2) Ubuntu, Apache2, CGI, Python 3.2, sekä samalla proxy softalla joka on modifioitu CGI käyttöön.

Softa hoitaa load balancingin noiden kesken ja samoin jos jompi kumpi palvelin ei toimi luotettavasti, niin pistää sen sisäiselle ban-listalle määräajaksi.

Unicodejen kanssa on tullut vielä säädettyä lisää, nykyinen ratkaisu toimii melkolailla hienosti, mutta en ole vieläkään varma toimiiko se kaikissa tilanteissa. Todella mahtavaa huomata miten järjettömän monimutkaiseksi nykyjään yksinkertaisetkin asiat saadaan. Varsinkin siinä tilanteessa, että käytettävä työkalu ei täysin maskaa tuota järkyttävää monimutkaisuutta.

Sähköpostista ja selaimista tämä on varmasti kaikille tuttua. Milloin liitteet, milloin merkistöt rikki, milloin kuvat viestissä hajalla jne. Eli standardit on monipuolisia, laajoja ja toteutukset eivät kata niitä kokonaan, sekä toteutukset eivät välttämättä toimi täysin oikein. Siitä se mahtava soppa syntyykin.

Jos joku haluaa, niin tuonne voi koittaa tunkea muutaman kurjan urlin ja kertoa millaisissa tilanteissa 9ox.net hajoaa.

uWSGI ei muuten ole ihan helpoimmasta päästä, toisaalta kehittäjätkään eivät sitä väitä. Ne sanoo että tää on gurujen työkalu loputtomalla määrällä optioita. Joiden dokumentointi on sitten vähän niin ja näin. Eli kokeilemisen ja epäonnistumisen kautta löytyy sopivat konfigit sitten aikanaan.

Nyt riittää koodailut, eilinen päivä tuli väännettyä vähän liiankin tiukasti.

[Sami Lehtinen]

Uusi 1.6.0 App Engine plattari toi mukavia ominaisuuksia. Olen nyt siirtänyt sovellukset käyttämään HDR tietokantaa, jossa kaikki tiedot on saatavissa aina useammalta kuin yhdeltä palvelimelta. Tämä tarkoittaa sitä, että teoriassa palvelussa ei pitäisi olla palvelukatkoja.

Samalla muutin parin testi softan toimintaa niin, että ne toimivat täysin asynchronisesti. Aivan requestin alussa, tehdään kasa RPC-kutsuja (tietokanta, web-servicet jne). Tehdään perusrutiinit ja lopuksi kerätään nuo tulokset. Aikaisemmin toimenpiteet tehtiin jonossa, nyt ne tehdään rinnakkain. Varsinkin DNS lookuppien osalta tämä nopeuttaa prosessia ratkaisevasti, aikaisemmin kolme peräkkäistä DNS lookuppia (kesto noin 700ms/lookup) vai tehdäänkö ne rinnakkain. jolloin pärjätään tasan 700ms:llä. Lisäksi kaikki tietokanta rutiinit tehdään tuossa välissä, jotka nekin kestivät sarjassa prosessoituna noin 100 ms.

Mikäli hommaa haluaisi vielä tästä tehostaa, pitäisi tietyt tietokanta toimenpiteet siirtää kokonaan rinnakaiseen prosessiin (task queue). Silloin voitasiin ensin tehdä käyttäjän requestin kannalta välttämättömät asiat ja sen jälkeen hoitaa loput asiat omana prosessinaan. Alunperin protoillessa lähdin vaan siitä, että kaikki asiat tehdään käyttäjän kutsun yhteydessä. Tämä luonnollisesti ei ole suorituskyvyn kannalta paras ratkaisu, vaikka se onkin helpoin toteuttaa.

Saas nähdä jaksaako vielä leikkiä tuon kuntoon tässä päivänä jonain. Vielä on yksi inhottava unicode/urlencoding ongelma, jolla lienee korkeampi prioriteetti. Koska se oikeasti häiritsee käyttävyyttä joissain tilanteissa. (Silloin kun URL-sisältää sopivan kasan unicode roinaa.)

[Sami Lehtinen]

Pistin WSGI hostingiin ep.io palveluun nslookup web-servicen, koska App Enginellä ei ole DNS-API:a. Täällä on: http://nslookup.sami-lehtinen.net/

Valitettavasti tuo palvelu vastaa vain autentikoituihin web-kyselyihin, koska ilmaisen palvelun quota on rajallinen.