Geocache.fi kuormitus & ongelmat

[haksu10]

Hei,

Geocache.fi jälleen tänä sunnuntaina sulki itsensä hetkeksi kuormituksen takia, lisäksi jouduin pari kertaa potkaisemaan webbiserveriä jotta uskoisi minua. Kuormitusongelmat ovat siis tiedossa ja tässä hieman selvitystä tilanteesta.

- Geocaching.com:n api -dataliityntä on varsinkin sunnuntaisin todella hidas (apin ping-aikakin välillä kymmenissä sekunteissa). Tämä on merkittävä ongelma joka aiheuttaa kuormitusta joka heijastuu sitten kokonaisuuteen.

- Geocaching Live pyörii toistaiseksi vielä täällä Suomen päässä. Tämä toivottavasti muuttuu pian ja tällöin merkittävä määrä apin käyttöä jää pois.

- Datan määrä on nykyisellään valtava. 25.000 käyttäjän osalta täytyy laskea tilastoja ja muodostaa listoja käyttäen pohjana 1.7 miljoonaa loggausta. Normaalisti tämä ei ole ongelma mutta kuormituksen kasautuessa se heijastuu tähänkin.

- Sivujen automaattipäivitys on todella monella käytössä. Esimerkiksi etusivu on kuitenkin kohtuullisen raskas koska (kirjautuneella käyttäjällä) sivu ei voi olla staattinen vaan sivupohjaan pitää ennen esitystä lisätä etäisyyksiä ja suuntia kätköihin, mahdollisia korostusvärejä jne.

Kuormitusseurantaa varten on nyt käytössä tarkemmat tilastoinnit joista saa taustatietoa mistä kuormitus muodostuu. Näistä tilastoista on huomannut että monella on etusivu pyörimässä minuutin välein tapahtuvalla automaattipäivityksellä ympäri vuorokauden. Lisäksi joukosta on löytynyt muutamia tilanteita joissa on jostain syystä (usessa välilehdessä?) ollut auki monta eri etusivua automaattipäivityksellä.

Niinpä toivonkin kohtuullista käyttöä automaattipäivityksen suhteen. Toki jos tarpeen on se voi olla (yhdessä välilehdessä) avoinna minuutin välein päivittyvänä mutta jos todellista tarvetta ei ole niin mahdollisuuksien mukaan pidentää päivitysväliä taikka kytkeä (ainakin sunnuntai-iltapäiviksi) automaattipäivitys pois.

Mikäli pakottava tilanne (kriittinen ylikuormitus tai sen uhka) niin vaatii saatan palvelimen päästä komentaa automaattipäivityksen pois tai muilla keinoilla rajoittaa sivulatauksia. Nämä ovat hetkellisiä toimenpiteitä eivätkä kohdistu käyttäjään tai kritisoi hänen toimintaansa vaan ovat pakollisia toimenpiteitä palvelimen toiminnan suojaamiseen.


Muutenkin teen jatkuvaa parannusta sivuston taustatekijöihin tavoitteena saada kuormitus pysymään kurissa. Tällä hetkellä radikaaleimmat muutokset ovat kuitenkin jäissä odottamassa että tuo gc live poistuu kuormittamasta ja saa selvyyden sen vaikutuksesta kuormitukseen. Esimerkiksi lisäpalvelinta ei siis tällä hetkellä ole järkevää alkaa hankkimaan.

Kaikin keinoin koitan siis taustalla pitää pyörät pyörimässä mutta pahoittelen mahdollisia kuormitusrajoituksen aiheuttamia katkoksia taikka mahdollisia tarpeita hetkeksi kytkeä webbiserveri pois päältä tilanteen rauhoittamiseksi.

[kimppikoo]

Itsehän käytän mottoa "Kun taidot loppuu, niin lisää rautaa"
No vitsi vitsi, ymmärrän hyvin kuormitusongelmat ja jos olisi rahaa niin kuin on mieli, niin olisi elo paljon helpompaa!

[arisoft]

Tässäpä oiva tilaisuus ja syy pistää automaattipäivitysoptio vain sponsoreille!

[H&I.]

Minulla ei ole automaattipäivitys päällä, mutta silti etusivu näyttäisi koko ajan latailevan jotain. Siis (tuliketun) välilehden "tiimalasirinkula" pyörii jatkuvasti. Liittyneekö tuo mihinkään?

[haksu10]

Tässäpä oiva tilaisuus ja syy pistää automaattipäivitysoptio vain sponsoreille!

Tämä kävi kyllä mielessä mutta ainakin osa selaimista tukee mahdollisuutta asettaa välilehdelle oma automaattipäivitysväli. Tällöin myöskään ei olisi mitään tietoa automaattipäivittymisestä, toisin kuin nyt automaattilatauksen ladatessa sivua se samalla kertoo mihin kohtaan automaattilataus-ruksi pistetään ja sama tieto on myös palvelimella referenssitietona.

Samoin kriittisen kuormituksen johdosta tehtävää rajoittamista ei voisi kohdistaa "floodaaviin käyttäjiin" vaan täytyisi suoraan siis kaikki sivupyynnöt estää. Siksi automaattilataukseen ei kannata alkaa minun tekemään rajoituksia.

Mutta ongelman suhteen olen nyt tehnyt hommia hartiavoimin ja syntymässä on ongelman suurimpaan syyhyn paneutuva järjestelmä, eli gc.com -apipyyntöjen vasteaikoja keräävä ja keskiarvo- sekä maksimivasteajat kertova härveli. Tähän räpellykseen tulee myös logiikka joka käyttää hyväkseen palvelimen kuormitustietoa sekä kerättyä vasteaikatietoa ja näiden perusteella säätää tausta-ajoprosessien datanpyyntömääriä.

Tämä rakennelma lienee valmis viikonlopuksi ja pääsee tällöin tositöihin ohjaamaan prosessia. Rakennelma joko parantaa, heikentää taikka pitää ennallaan datan ajantasaisuuden

Tämä erikoisuus selittyy sillä että tällä hetkellä normaalitilanteessa kaikki data (kätköjen tiedot, loggaukset, attribuutit jne.) saadaan luettua noin 14 tunnin aikaikkunassa. Sunnuntaisin on täysin samaa tahtia laitettu lukukäskyjä härveleille mutta jumiintuva api on aiheuttanut niin suuren määrän keskeytyviä lukuja että aikaikkuna on revennyt yli vuorokauteen.

Teoriassa järkeämpi prosessiohjaus parantaa ajantasaisuutta, mm. mahdollistaen entistä suuremman lukupyyntöjen tiheyden optimaalisina aikoina eli kun palvelimen kuormitus ja apin nopeus on ihannetilassa. Mutta lopputuloksen näkee vasta kun on saanut mahdollisimman tehokkaan datankeruun ja kurissa pysyvän palvelinkuormituksen välisen kauhun tasapainon täydellisyyttä hipovaksi.

Minulla ei ole automaattipäivitys päällä, mutta silti etusivu näyttäisi koko ajan latailevan jotain. Siis (tuliketun) välilehden "tiimalasirinkula" pyörii jatkuvasti. Liittyneekö tuo mihinkään?

Itse en FF:ssä saanut indikaattoria näkymään (en löytänyt koko indikaattoria mutta sinänsä mitään varsinaista latausta ei tapahdu sivun latautumisen jälkeen tai en ainakaan keksi miten/miksi tapahtuisi (toki kun on haksu10-koodista kyse niin kaikki on mahdollista

Mutta uskoisin että kyseessä on epämääräiset javakikkareet, ehkäpä uusien kätköjen listan alta löytyvän sponroriruudun java, joka aiheuttaa indikaattorin pyörimisen.

[arisoft]

Tämä kävi kyllä mielessä mutta ainakin osa selaimista tukee mahdollisuutta asettaa välilehdelle oma automaattipäivitysväli. Tällöin myöskään ei olisi mitään tietoa automaattipäivittymisestä, toisin kuin nyt automaattilatauksen ladatessa sivua se samalla kertoo mihin kohtaan automaattilataus-ruksi pistetään ja sama tieto on myös palvelimella referenssitietona.

Sen verran on tullut tehtyä hieman speciaalimpaa http viritystä että tuohon saattaisi olla apu tiedossa. Refresh pyynnöille voi näet vastata, ettei ole mitään muutoksia, jolloin ei jää mitään ladattavaa ja generoitavaa ja siirrettävää. Eli siis kuormituspiikin aikana jos tulee päivitys itse tehdyn automaatin taikka selaimessa olevan automaatin taikka manuaalisen refreshin muodossa niin sille voi sanoa että ei muutoksia. Silloin selain näyttää aiemman version "uutena".

Itse tein tällaisen sivun siten, että sivun ETAG paljastaa lsivun latauspyynnössä onko kyseessä päivitys ja onko sivulla mitään aihetta uuteen päivitykseen. Jos pyyntö on turha niin pyyntöön vastataan HTTP_NOT_MODIFIED ja se siitä. ETAG on sikäli varma systeemi että siihen ei vaikuta cookie asetukset. Jotkut sivut käyttääkin sitä menestyksellisesti cookien sijaan.

[haksu10]

Tämä kävi kyllä mielessä mutta ainakin osa selaimista tukee mahdollisuutta asettaa välilehdelle oma automaattipäivitysväli. Tällöin myöskään ei olisi mitään tietoa automaattipäivittymisestä, toisin kuin nyt automaattilatauksen ladatessa sivua se samalla kertoo mihin kohtaan automaattilataus-ruksi pistetään ja sama tieto on myös palvelimella referenssitietona.

Sen verran on tullut tehtyä hieman speciaalimpaa http viritystä että tuohon saattaisi olla apu tiedossa. Refresh pyynnöille voi näet vastata, ettei ole mitään muutoksia, jolloin ei jää mitään ladattavaa ja generoitavaa ja siirrettävää. Eli siis kuormituspiikin aikana jos tulee päivitys itse tehdyn automaatin taikka selaimessa olevan automaatin taikka manuaalisen refreshin muodossa niin sille voi sanoa että ei muutoksia. Silloin selain näyttää aiemman version "uutena".

Itse tein tällaisen sivun siten, että sivun ETAG paljastaa lsivun latauspyynnössä onko kyseessä päivitys ja onko sivulla mitään aihetta uuteen päivitykseen. Jos pyyntö on turha niin pyyntöön vastataan HTTP_NOT_MODIFIED ja se siitä. ETAG on sikäli varma systeemi että siihen ei vaikuta cookie asetukset. Jotkut sivut käyttääkin sitä menestyksellisesti cookien sijaan.

Kiitokset hyvästä ja ammattitaitoisesta infosta, itselläni onkin tietämys kaikesta hienommasta perin heikko. Tekniikka on näköjään vallan toimiva ja osasin sitä käyttääkin

Siinpä nyt sivusto käyttääkin tätä tekniikkaa kriittisissä tapauksissa kuormaa leikkaamaan. Tutkin tekniikan mahdollisuuksia laajemmin ajan kanssa eli tapoja leikata pois turhat lataukset (joissa tosiaan ei ole mitään uutta tarjolla) mutta tämän toteutus vaatii jo järjenkin käyttöä.

Nyt myös uusi prosessien ohjaaja on palveluksessa, eli härveli joka säätää gc.com -apipyyntöjä perustuen palvelimen kuormitukseen ja apin 100 viimeisimmän teknisesti toisiaan vastaavan kätködatapyynnön vasteaikaan. Härveli luokittelee pyynnöt nopeisiin, keskitasoisiin ja hitaisiin ja muodostaa näiden suhteellisen osuuden sekä maksimilatausajan perusteella tiedon apin suorituskyvystä.

Uusi härveli osaa myös estää taustadatan keräyksen kokonaan mikäli olosuhteet ovat niin järjettömät että datan latauksen onnistuminen olisi enää teoreettista, samoin härveli estää kyseisen datatiedon latausprosessin käynnistymisen mikäli vanha prosessi onkin jäänyt elämään liian pitkäksi aikaa. Yhdistettynä hiljattain käyttöön tulleeseen automaattiseen prosessien tappamiseen tämä muodostaa teoreettisesti mahdollisimman täydellisen pohjan datan lataukselle ilman turhia taukoja sekä päällekkäisyyksiä.

Kuulostaa vallan hienolta mutta aika näyttää härvelin vaikutuksen datan läpilatauksen aikaikkunaan, samoin seurantaa ja säätöä on vielä edessä jotta kauhun tasapaino on täydellinen. Varsinainen tulikaste odottaa jälleen sunnuntaina ja täysinhän apiliikennettä (tai edes yrittämistä) ei kuitenkaan voi estää koska uudet kätköt ja niiden FTF-loggausten valvonta on kuitenkin prosesseja mitkä pyörivät täydellä teholla ilman että tämäkään härveli niihin pääsisi estoja tekemään.

Odotettavissa siis jo viikolla hanskasta lähtevää kuormitusta, viikonloppuna täydellinen romahdus... tai toivottavasti ei

[kimppikoo]

Haksu, sie oot nörtti

[luomanperhe]

Oletteko harkinneet gc.fi -palvelun siirtämistä pilveen (esim. Amazonin palikoiden päälle)?

Nopeasti ajatellen tämän plussat olisivat melkein rajaton skaalautuvuus ja kehittäjäresurssin käyttö parempaan (so. tulipalojen sammuttelusta saitin kehittämiseen). Vastaavasti miinuksena olisi että prosessointi-, levy- ja verkkokapasiteetista pitäisi jotain maksaa.

[ZeroOne]

Kuulostaa vallan hienolta mutta aika näyttää härvelin vaikutuksen datan läpilatauksen aikaikkunaan, samoin seurantaa ja säätöä on vielä edessä jotta kauhun tasapaino on täydellinen. Varsinainen tulikaste odottaa jälleen sunnuntaina ja täysinhän apiliikennettä (tai edes yrittämistä) ei kuitenkaan voi estää koska uudet kätköt ja niiden FTF-loggausten valvonta on kuitenkin prosesseja mitkä pyörivät täydellä teholla ilman että tämäkään härveli niihin pääsisi estoja tekemään.

Itse en kuitenkaan pitäisi FTF-loggausten valvontaa niin tärkeänä että se olisi pidettävä päällä jos palvelimet käyvät ylikierroksilla. Tuo sinun härvelisi kuulostaa kyllä hienolta. Ehkä voisit laittaa sen tulostamaan etusivulle automaattisesti jonkinlaisen varoituksen jos apiliikenne hidastelee? Tyyliin "Huh huh, geocaching.comin palvelimet ovat nyt niin kovan rasituksen alla että tälläkin sivustolla lokiseuranta on tilapäisesti poissa käytöstä!". Tällöin ihmiset ainakin tietäisivät missä mättää eikä sinunkaan tarvitsisi postailla sivuston uutisiin jotta taas kaikki hidastelee. Ja jos halutaan lähteä hifistelemään, voit tehdä gc.comin apin vasteaikagraafinkin sivustolle näkyviin.

Oletteko harkinneet gc.fi -palvelun siirtämistä pilveen (esim. Amazonin palikoiden päälle)?

Nopeasti ajatellen tämän plussat olisivat melkein rajaton skaalautuvuus ja kehittäjäresurssin käyttö parempaan (so. tulipalojen sammuttelusta saitin kehittämiseen). Vastaavasti miinuksena olisi että prosessointi-, levy- ja verkkokapasiteetista pitäisi jotain maksaa.

Tuskin se nykyisinkään ihan ilmaista on. Mutta ihan hyvä idea. Periaatteessahan tuolla voisi jopa säästää kun gc.fi -kapasiteetti on nykyisin arvatenkin kiinteästi mitoitettu tasolle x, ja pilvi voisi tarvittaessa pudottaa palvelimia eli kustannuksia pois kun kapasiteetin tarve laskee, esimerkiksi öisin.

[Seq]

Pilvi on jees, jos tarvitsee hetkellisesti paljon tehoa, mutta jatkuvassa palvelussa se tulee kalliiksi. Kokemusta on.

[haksu10]

Kuulostaa vallan hienolta mutta aika näyttää härvelin vaikutuksen datan läpilatauksen aikaikkunaan, samoin seurantaa ja säätöä on vielä edessä jotta kauhun tasapaino on täydellinen. Varsinainen tulikaste odottaa jälleen sunnuntaina ja täysinhän apiliikennettä (tai edes yrittämistä) ei kuitenkaan voi estää koska uudet kätköt ja niiden FTF-loggausten valvonta on kuitenkin prosesseja mitkä pyörivät täydellä teholla ilman että tämäkään härveli niihin pääsisi estoja tekemään.

Itse en kuitenkaan pitäisi FTF-loggausten valvontaa niin tärkeänä että se olisi pidettävä päällä jos palvelimet käyvät ylikierroksilla. Tuo sinun härvelisi kuulostaa kyllä hienolta. Ehkä voisit laittaa sen tulostamaan etusivulle automaattisesti jonkinlaisen varoituksen jos apiliikenne hidastelee? Tyyliin "Huh huh, geocaching.comin palvelimet ovat nyt niin kovan rasituksen alla että tälläkin sivustolla lokiseuranta on tilapäisesti poissa käytöstä!". Tällöin ihmiset ainakin tietäisivät missä mättää eikä sinunkaan tarvitsisi postailla sivuston uutisiin jotta taas kaikki hidastelee. Ja jos halutaan lähteä hifistelemään, voit tehdä gc.comin apin vasteaikagraafinkin sivustolle näkyviin.

Itse asiassa automaattiviestiä olen miettinyt, tosin ensin täytyy sisäänajaa uusi härveli kunnolla. Täällä muuten on tuollainen epävirallinen seurantaversio apin senhetkisestä tilanteesta. Ihannetulos on että kaikki tulokset ovat 1-2 sekunnin välissä ja sen olen todennut aamupäivisin Suomen aikaa toteutuvankin... mutta odottakaahan kun koittaa sunnuntai-ilta, uskoisin että sitten näkee taas jotain uskomattoman suuria lukuja

Mutta katsotaan mitä tapahtuu geocache.fi:n suhteen sunnuntaina. Eilen uuden systeemin otettuani käyttöön kuormat pomppasivat entistä korkeammalle joka näytti jo huolestuttavalta. Mutta yön jälkeen palvelimet ovat olleet koko päivän normaalia pienikuormaisempia ja sivujen keskimääräinen latausaika romahti peräti alle sekuntiin, eli 0.8 sekuntiin 57598:n sivulatauksen perusteella (joka toki ei sulje pois sitä että jotkut sivut kuten lokiseuranta toki ottaa aina aikaa).

Joko olen siis unohtanut jonkun päivityshärvelin laittaa päälle (vaikka kaikki ajantasaisuustiedot näyttää hyvältä) taikka sitten uusi härveli tosiaan toimii ja palvelimet saivat yön aikana siivottua törkynsä levynnurkalta ja ovat taas innokkaana uudesta tehosta palvelemassa.

Odotan siis edelleen sunnuntaita ja katastrofia

Oletteko harkinneet gc.fi -palvelun siirtämistä pilveen (esim. Amazonin palikoiden päälle)?

Nopeasti ajatellen tämän plussat olisivat melkein rajaton skaalautuvuus ja kehittäjäresurssin käyttö parempaan (so. tulipalojen sammuttelusta saitin kehittämiseen). Vastaavasti miinuksena olisi että prosessointi-, levy- ja verkkokapasiteetista pitäisi jotain maksaa.

Tuskin se nykyisinkään ihan ilmaista on. Mutta ihan hyvä idea. Periaatteessahan tuolla voisi jopa säästää kun gc.fi -kapasiteetti on nykyisin arvatenkin kiinteästi mitoitettu tasolle x, ja pilvi voisi tarvittaessa pudottaa palvelimia eli kustannuksia pois kun kapasiteetin tarve laskee, esimerkiksi öisin.

Pilviajatukseen tulikin jo tätä rustatessani maininta hinnasta... ja varmasti näin onkin. Lisäksi nykyisellään (kiitos mmd.net -palvelun, mainostetaan nyt kiitoksena palvelinpaikkojen hinta on enemmän kuin kilpailukykyinen ja edes teoriassa ei ole mahdollista saada halvempaa ratkaisua. Hyvä näin koska taloudelliset faktat tähän harrastelijan puuhastelun suhteen olen kertonutkin

Sinänsä toki olisi erittäin helppo ratkaisu siirtää kapasiteettiongelmat historiaan: palata aikoinaan olleeseen käytäntöön että data on enimmillään 2 vuorokautta vanhaa, tai edes tinkiä tavoitteesta saada materiaalin ajantasaisuus aina vaan paremmaksi. Mutta ilman pyrkimystä täydellisyyteen ei tämä räpellykseni olisi näin kehittynyt ja vaikka täydellisyyttä en ikinä saavutakaan niin askel, edes pieni sellainen, kerrallaan sitä kohden

[Seq]

Pilviajatukseen tulikin jo tätä rustatessani maininta hinnasta... ja varmasti näin onkin. Lisäksi nykyisellään (kiitos mmd.net -palvelun, mainostetaan nyt kiitoksena palvelinpaikkojen hinta on enemmän kuin kilpailukykyinen ja edes teoriassa ei ole mahdollista saada halvempaa ratkaisua. Hyvä näin koska taloudelliset faktat tähän harrastelijan puuhastelun suhteen olen kertonutkin

Toivottavasti hinnat eivät ole sivustolla näkyvän mukaisia, koska noi on jotain vuosia vanhoja hintoja. Ei kukaan maksa nykyään tuollaisia.

[haksu10]

Pitkästä aikaa palaan tähän aiheeseen; tällä kertaa positiivisissa merkeissä.

Liven siirtyminen jenkkien riesaksi vapautti odotusten mukaisesti palvelintehoja ja varsinkin viikonloppuina vaivannut liian suuri ylikuormitus on toistaiseksi pysynyt poissa. Koska Livessä oli paljon apiin kohdistuvia "pakko ladata" -toimenpiteitä niin tämä osaltaan hankaloitti tilannetta. Nykyisellään onkin vain uusien kätköjen valvonta sekä uusimpien kätköjen FTF-lokivalvonta pakollisia ei koskaan -rajoitettavia latauksia.

Kun tehoa on ollut enemmän on myös muutamia pullonkauloja käynyt ilmi ja niitä olen myös fiksaillut lisätehon käyttöön saamsekseksi. Nyt myös aiemmin mainitsemani latausohjausjärjestelmä, eli "härveli" on nyt päässyt tositoimiin ja se pystyykin kuormahuippuja leikkaamaan hienosti.

Niinpä viikonlopun ja tämän päivän käytin järjestelmän päivitykseen, pyrkimyksenä päästä parempaan ajantasaisuuteen. Ennen vanhin lokidata oli 14 tunnin ikäistä ja kätködata 12 tunnin ikäistä; toki kohtuullisen ajantasaista sekin mutta pakkohan sitä on koittaa parantaa. Koska apin vasteaika on seikka mihin Liven poistuminen ei vaikuttanut on nyt mm. viritetty useampia prosesseja rinnakkain lukemaan dataa.

Tehokkaammaksi viritelty järjestelmä on pysynyt kurissa ja datan ajantasaisuus on parantunut merkittävästi. Palvelimen peruskuormitustaso on noussut huomattavasti mutta pysyen kuitenkin normaalikuormitusalueella. Kevään edetessä ja aktiivisuuden taas kasvaessa on mahdollista että ajantasaisuus laskee mikäli kuormitukset menevät tasolle missä latausohjausjärjestelmä rajoittaa latausprosesseja, ja tarvittaessa täytyy vähentää prosesseja mikäli kuormitukset hakkaa koko ajan maksimitasolla.

Mutta nyt kun lukemat ovat mallikelpoisia niin ne ovat myös käyttäjille nähtävissä tällä sivulla, sivun alusta löytyy datan ajantasaisuustiedot

Juuri tällä hetkellä lokidata on entiseen (vanhin data 14 tuntia) verrattuna uskomattoman pienellä viiveellä mutta lokitietojen osalta vaihtelu toisaalta on suurinta. Lokien lukemista ohjaa myös gc.comin recent logs -osuudesta saatu data; jos sieltä saa raavittua Suomen loggauksia niin kyseisten kätköjen loggaukset luetaan välittömästi lisäprosessissa. Tämä tuo siis lisää poweria lokikeruuseen ja pienentää aikoja.

Mutta katsotaan miten homma etenee, nyt palvelin tekee tosiaan hartiavoimin hommia mutta ehkä vieläkin koitan sitä lisää kyykyttää kun näkee miten se tähän mennessä tehdystä pidemmän päälle selviää

[___MIKKI___]

Ootko haksu10 muuten harkinnut että alkaisit koodaaman geocaching.comille? Samalla ratkeisi sponsoroinninkin tarve .
Sinäänsä on hassua geocache.fi:ssä on paljon hienoja ominaisuuksia jotka puuttuvat pääsivulta. On kuitenkin nähtävissä miten gc.comin featurelista pikkuhiljaa kasvaa. Tulevaisuudessa on vaarana että gc.fi näivettyy gc.comin kehittyessä. Käy niin sanotusti Nokiat .

Älkää ottako loukkauksena tai pahastuko, en halua ajaa erinomaista palvelua alas. Kunhan vain tulin kävellessä pohtineeksi...

Ehkä heille kelpaa alihankkijatkin, jos et halua Seattleen muuttaa . Tosin vaimon mukaan se on ihan mukava kaupunki
http://www.groundspeak.com/about.aspx#Jobs

[aku506]

Ootko haksu10 muuten harkinnut että alkaisit koodaaman geocaching.comille? Samalla ratkeisi sponsoroinninkin tarve .
Sinäänsä on hassua geocache.fi:ssä on paljon hienoja ominaisuuksia jotka puuttuvat pääsivulta. On kuitenkin nähtävissä miten gc.comin featurelista pikkuhiljaa kasvaa. Tulevaisuudessa on vaarana että gc.fi näivettyy gc.comin kehittyessä. Käy niin sanotusti Nokiat .

Älkää ottako loukkauksena tai pahastuko, en halua ajaa erinomaista palvelua alas. Kunhan vain tulin kävellessä pohtineeksi...

Ehkä heille kelpaa alihankkijatkin, jos et halua Seattleen muuttaa . Tosin vaimon mukaan se on ihan mukava kaupunki
http://www.groundspeak.com/about.aspx#Jobs

Onhan se jo liven koodannu gs:älle

[haksu10]

Ootko haksu10 muuten harkinnut että alkaisit koodaaman geocaching.comille?

Se vaatisi ohjelmointitaitoa

Tulevaisuudessa on vaarana että gc.fi näivettyy gc.comin kehittyessä.

Geocache.fi ja minä näivetymme yhdessä, ja samaan kuoppaan meidät haudataan...

[___MIKKI___]

Kyllähän tämä sivusto kävisi työnäytteestä . Sivuston tyytyväiset käyttäjät voivat varmasti kirjoittaa muutaman suosituskirjeen.

Sen verran hidasta tuo GC.comin kehitys on ollut, ettei lähiaikana tarvitse vielä gc.fi hautajaisia viettää.

Ootko haksu10 muuten harkinnut että alkaisit koodaaman geocaching.comille?

Se vaatisi ohjelmointitaitoa

Tulevaisuudessa on vaarana että gc.fi näivettyy gc.comin kehittyessä.

Geocache.fi ja minä näivetymme yhdessä, ja samaan kuoppaan meidät haudataan...

[haksu10]

Kyllähän tämä sivusto kävisi työnäytteestä . Sivuston tyytyväiset käyttäjät voivat varmasti kirjoittaa muutaman suosituskirjeen.

Tää on vaan rääpimistä, ei kunnon ohjelmointia

Samalla mainitsen että datankeruun tehostukseen liittyen parin kätkön lokit on taas kadoksissa, palasivat täyttämään lokiseurannan.

Jostain syystä tehostettu lokinkeräys on tehnyt logiikkaongelman jota en ole pystynyt selättämään ja tämä on jyrännyt satunnaisesti jonkun kätkön kaikki lokit. Jotta gc.com:sta poistuneet lokit poistuisi automaattisesti geocache.fi:stäkin on käytetty lokien läpikäynnissä rutiinia joka merkkikentän arvolla määrittelee onko loki vielä mukana.

Tässä malli varmistetusta toiminteesta määrineen jonka ainakin olisi pitänyt turvata homma - mutta malli kertoo miten kävikään:

- Päivitetään käsiteltävän kätkön lokeihin "lippukentän" arvoksi 1 niihin lokeihin jotka olivat mukana kätkön lokien käsittelyssä (tulos: 245 riviä)
- Kantakyselyllä kysytään monenko lokin lippukenttä on 0 ja jos on alle 3 niin silloin saa tuhota (tulos: alle 3 riviä)
- Tuhotaan lokit joiden lippukenttä on 0 (ja tuloksena oli: 245 riviä !!!)

Eli käsittämättömästä syystä muutaman kerran päivässä tuo logiikka yskii... mutta luovuin koko osuudesta, täytyy tehdä tuo erillisenä osuutena.

Nyt kuitenkin uskoisin ettei enää massatuho kohtaa minkään kätkön lokeja. Pahoittelut yskimisestä. Sentään datan ajantasaisuuslukemat ovat vallan nättejä, joku hyöty säätämisestä sentään

[haksu10]

Välillä taasen tästä aiheesta...

Pientä yskimistä on vielä ollut liikkeellä. Enää ei lokeja pitäisi olla kadonnut mutta reaaliajassa havaitsemattomien lokien osalta viive palveluun mukaantulossa on tilastosivun datatilanteen kertomaa suurempi. Dataa tulee nyt sitä tahtia sisään että käsittelyosuus olikin jäänyt jälkeen

Koitin nopeuttaa asian päivittymistä moniprosessilla mutta sitten alkoikin tulemaan tuplalokeja tietokantaan. Siispä ennen kuin ehdin tehdä moniajoturvallisen systeemin noita lokeja parsii yksi prosessi mutta täydellä teholla - uskoisin että tilanne korjaantuu yön aikana.

Tällä viikolla olen muutenkin vielä hionut rutiineja ja koittanut saada kaiken tyhjäkäynnin pois. Prosessien suoritus on nyt ajastettu aivan viimeisen päälle ja härveleihin on lisätty erilliset tapporutiinit jotta esim. apiongelman vuoksi liian pitkään elävät prosessit katoaa maan alle.

Palvelin huriseekin melkoisella kuormituksella ja saa nähdä täytyykö hieman tinkiä sellaisen datan ajantasaisuudesta mikä keskimäärin ei muutu niin nopeasti. Esimerkiksi attribuuttimuutoksia tulee 8 tunnin latauskierron aikana vain hyvin pieneen määrään kätköistä joten nykyisentasoinen tehokkuus ei ole tältä osin perustelua. Apin "hienouteen" kun kuuluu ettei attribuutit tule kätködatan mukana vaan ne täytyy kätkö kerrallaan ladata erikseen (samoin kuin lokit erikseen ja kuvatiedot erikseen...)

Mutta seuraan palvelimen keskimääräisiä sivupyyntöaikoja ja jos ajat tuntuvat venähtävän niin sitten pistän hieman kevennystä peliin. Sitten hieman nörttikieltä: Vaikkakin uptime kertookin jatkuvasta ylikuormasta niin iostat lohduttaa noin 50% idle-ajan kanssa joten vielä en näppejäni datan ajantasaisuuteen tunge.

Pahoittelen näitä (pieniä) ongelmia tämän projektin kanssa. Mahdollista on että vieläkin jotain lokisekoilua tapahtuu koska järjestelmä muuttuu entisestä rauhallisesti yksi kerrallaan tapahtuvasta toiminnosta moniajon suuntaan eikä kaikkea selvästi osaa huomioida, mutta koitan pitää ongelmat mahdollisimman pieninä. Muutos (jälleen kerran) kuitenkin on tarpeen koska vaikkakin dataprosessointi entisellä tavallakin pysyi kohtuullisessa viiveessä niin ensi kesänä taas kätkötaivaat aukeaa ja ladattava datamäärä lisääntyy ja sen myötä viiveetkin.