Millaisella raudalla tää klubbari oikein pyörii? Tuntuu toimivan todella sujuvasti ja jouheasti. Montako tonnia on isketty serveriin kiinni? Vai onko hajautettu useamman serverin klusteriin.
Kotin kovasti etsiä keskusteluista tällaista threadia, mutta en löytänyt hakutoiminnolla etsimääni. Joten linkki jo käytyyn keskusteluun ajaa luonnollisesti myös asian.
teknokraatti, 15.9.2007 18:15:
Millaisella raudalla tää klubbari oikein pyörii? Tuntuu toimivan todella sujuvasti ja jouheasti. Montako tonnia on isketty serveriin kiinni? Vai onko hajautettu useamman serverin klusteriin.
Vielä eiliseen asti pyöri kaikki (meilipalvelin, tietokanta, webbipalvelin, irkkishellit jne ja pari pienempää webisaittia) yhdellä P4 2.8 Ghz (HyperThread) missä 1.5 gigaa muistia.
Tällä hetkellä käytössä 2 konetta joista tehokkaampi lähinnä idlailee..
anqqa
yhdellä P4 2.8 Ghz (HyperThread) missä 1.5 gigaa muistia.
Ilmeisesti olet hieman panostanut optimointiin jne.
Olen tässä muutamaa web projektia seuraillut ja laitevaatimukset on täysin järjettömiä käyttäjämääriin verrattuna. Sivujen latausajat pienilläkin käyttäjämäärillä 3-5 sekuntia tms.
Koneina on juuri 2xDual Core Xeonint, 4 gigaa muistia SAS levyt jne. Ja silti resurssit finaalissa parilla kymmenellä käyttäjällä. Täysin käsittämätöntä, jossain pitää olla jotain pielessä.
Olen tässä muutamaa web projektia seuraillut ja laitevaatimukset on täysin järjettömiä käyttäjämääriin verrattuna. Sivujen latausajat pienilläkin käyttäjämäärillä 3-5 sekuntia tms.
Koneina on juuri 2xDual Core Xeonint, 4 gigaa muistia SAS levyt jne. Ja silti resurssit finaalissa parilla kymmenellä käyttäjällä. Täysin käsittämätöntä, jossain pitää olla jotain pielessä.
Suorituskykyongelmissa tulee hyvin se ilmi, että vaikka rautaa pistäisi rajalle niin mikään määrä ei auta jos suorituskyky ei ole tarpeeksi kova. Millä tahansa ohjelmointikielellä on äärettömän helppoa tehdä tehottomia toteutuksia, joiden optimoidut versiot voivat suoriutua hommasta mikrosekunneissa vuosien sijaan.
Se miksi ongelmat ovat päätyneet tuotantoon on kuitenkin enemmänkin liiketoimintalähtöinen ongelma. Jos ohjelmistotyön laatuun ja laatua edistäviin menetelmiin ei ymmärretä panostaa oikealla tavalla, tuloksena voi olla aivan muuta kuin mitä on tavoiteltu (tjeu soundchilds ).
anqalla on nähdäkseni hyvä paketti kasassa klubituksen suhteen...
Nyt kun tästä on kerran topikkikin, niin mikä on pullonkaula/issue klubbarin välillä tahmatessa? Tietokanta, siirtotie, rauta, koodi? U know, "klubitus erroroi pfffft" tai aivan jumalattoman pitkä refresh aika tms? Esiintyy paikka paikoin.
Mitään php:n optimoinnista tietämättömänä en pysty ottamaan kantaa tuohon koodin optimoimiseen yleisesti, hakuajat kyllä jokseenkin pienet normaalisti. Eli = kone ilmeisesti :P
Mark, 17.9.2007 17:14:
Nyt kun tästä on kerran topikkikin, niin mikä on pullonkaula/issue klubbarin välillä tahmatessa? Tietokanta, siirtotie, rauta, koodi? U know, "klubitus erroroi pfffft" tai aivan jumalattoman pitkä refresh aika tms? Esiintyy paikka paikoin.
Mitään php:n optimoinnista tietämättömänä en pysty ottamaan kantaa tuohon koodin optimoimiseen yleisesti, hakuajat kyllä jokseenkin pienet normaalisti. Eli = kone ilmeisesti :P
-M
Ylläpitäjien aiheuttamia tahallisia katkoksia useimmiten :) ts. säätöä
Pakko kyllä yhtyä muihin, klubitus on yksi parhaiten toimivista webapplikaatioista jota tiedä, lisäksi vielä kun käyttömukavuuteenkin on panostettu, niin ei voi valittaa.
Vielä kun huomioi mikä määrä jokaisella sivulla on kannasta haettavaa tauhkaa. Varsinkin tuolla palvelimella on ihme että pyörii siis niin loistavasti kun pyörii. Tietysti tahmaa tulee kun resurssit ylitetään, mutta raudanteho / sovellusten suorituskyky on mielestäni kyllä ihan huippuluokkaa.
19H + 86N + 96G = 201 eikä mitään lagia.
Hatunnosto!
Joo. Ongelma on just siinä meillä. Että on lähdetty funktionaalisesta koodaamisesta. On siis tehty asiat niin että ne toimii, mutta ei yhtään kiinnitetty huomiota siihen miten tehokkaasti ne toimii. Samoja lookuppeja saatetaan tehdä moneen kertaan ja muuta vastaavaa todella typerää. Loopin sisällä haetaan tietoja, jotka olisi voitu noutaa jo kertaalleen valmiiksi ennen looppia tms. Noista sitten kertautuu melkoinen roskakuorma. Profilointi on jo otettu suunnitelmaan. Koska systeemi imee mehut myllystä kuin myllystä ihan kevyesti.
Tietysti alusta mysql + tomcat on jo muutenkin törkeän raskas. Mutta vielä tekemällä toteutuksen suorituskykyä ajattelematta saadaan systeemistä järjettömän hidas ja raskas.
Nyt 20 samanaikaisen käyttäjän pyörittämiseen sujuvasti tarvitaan about 5 tonnin mylly. Huhhuh. No onneksi palvelu on rajattu pienelle käyttäjäkunnalle. Mutta kuitenkin jotain ihan käsittämätöntä.
Muistan vaan kun yhdessä projektissa muutin linked listin hashtableksi ja koko sovellus muuttui kertalaakista about 50 kertaa nopeammaksi. Tuohon tietysti vaikuttaa olennaisesti se paljonko kamaa objekticontainerissa on. Mutta kuitenkin. Objektikontaineri kun oli koko softan core jonka tehtävänä oli siis kerätä ja lajitella tietoa tietyin perustein. No, oishan toi tietty hoitunut vaikka reikäkorteilla. ;)
Toinen frendi fiksasi yhtä saittia jossa joku oli laittanut jokaisella sivulla olevan pienen statistiikka diagrammin luotavaksi lennossa aina jokaiselle käyttäjälle. Pisti systeemin luomaan sen kuvan kerran minuutissa ja sen jälkeen koko site rupesi lentämään. Kun aivan järjettömän turha kuvien luominen poistui jokaisen sivunlatauksen yhteydessä.
Kaikkialla tietysti suositellaan että tärkeimmälle ja aktiivisimmalle datalle pitäisi soveltaa aplication level cachingia. Mutta eipä tuotakaan moni "mä vaan teen toimivan ohjelman ja saan rahat ja lähden litoon" tyyppi ajattele.
Tollasilla mokilla saa tuhottua suorituskyvyn todella helposti ja totaalisesti.
Olen suosinut ratkaisua jossa aktiivinen osio muokkaa staattisia sivuja muutosten tapahtuessa. Silloin palvelin voi palvella kaikki sivut staattisina. Vain kun tehdään jotain aktiivista tarvitsee sivuja päivittää. Suunnattoman kätevää, varsinkin sellaisissa siteissä jossa ehkä yksi 100 tai jopa 1000 sivunlatauksesta oikeasti tekee jotain muuta kuin katsoo sisältöä. Statistiikan tms takia kaikki sivut voidaan luoda uudelleen vaikka tunnin välein. Mutta 99% sivunlatauksista ei vaadi mitään muuta kuin datan tuuppaamista suoraan clientille ilman sen kummempia tarkistuksia.
sts, 17.9.2007 17:30:
Pakko kyllä yhtyä muihin, klubitus on yksi parhaiten toimivista webapplikaatioista jota tiedä, lisäksi vielä kun käyttömukavuuteenkin on panostettu, niin ei voi valittaa.
Jep, pitää yhtyä tähän. Mukavin, monipuolisin, joustavin ja näyttävin forum-softa mitä maa päällään kantaa. Imho tätä pitäis myydä purkitettuna <3
paskasta järjestelmästä puheenollen: BEA-Weblogic server ja oracle, pyörittämässä kahden koneen solaris klusteri, kyykyssä 100 ihmisen loadista :D (kokemuksia työkomennuksesta eräässä it-alan yrityksessä)
teknokraatti, 17.9.2007 20:35:
Tietysti alusta mysql + tomcat on jo muutenkin törkeän raskas. Mutta vielä tekemällä toteutuksen suorituskykyä ajattelematta saadaan systeemistä järjettömän hidas ja raskas.
MySQL ja Tomcat "törkeän raskaita"? MySQL käytössä joidenkin todella isojen saittien taustalla ja ei se Tomcat:kaan taida olla kovin paljon hitaampi kuin kilpakumppaninsa. Veikkaisinkin että teillä raskauteen syyt on ennemminkin muualla :p
Apo, 17.9.2007 21:47:
MySQL ja Tomcat "törkeän raskaita"? MySQL käytössä joidenkin todella isojen saittien taustalla ja ei se Tomcat:kaan taida olla kovin paljon hitaampi kuin kilpakumppaninsa. Veikkaisinkin että teillä raskauteen syyt on ennemminkin muualla :p
Apo:
anqalla on nähdäkseni hyvä paketti kasassa klubituksen suhteen...
visio + motivaatio + tietotaito => anqqa = kone
Unohtamatta kaaputtimen varsin suurta osaa palvelimen konffauspuolella :) Ilman sitä ei mun taidoilla niin jouhevasti pyörivää järjestelmää ihan hetkessä sais kasaan vaikka koodia optimoisikin..
Mark:
Nyt kun tästä on kerran topikkikin, niin mikä on pullonkaula/issue klubbarin välillä tahmatessa? Tietokanta, siirtotie, rauta, koodi? U know, "klubitus erroroi pfffft" tai aivan jumalattoman pitkä refresh aika tms? Esiintyy paikka paikoin.
99% tapauksista tietokannassa on 1 jumittava hidas kysely joka lukitsee tietokantataulun, ja kun muut yrittää lukea samaa taulua joutuu ne jonottamaan että ko. hidas kysely suoritetaan loppuun ja varsin nopeesti sallitut yhteydet loppuu kesken ja kanta sanoo halt. Tähänkin on kyhätty systeemi joka monitoroi koko ajan tietokantaa ja webbipalvelinta ja jos ne ei vastaa tarpeeks nopeesti niin niille sanotaan restart, eli systeemi käynnistää itse itsensä uudestaan jos se menee jumiin ja näinollen klubbari on jumissa korkeintaan muutaman minuutin.
teknokraatti:
Joo. Ongelma on just siinä meillä. Että on lähdetty funktionaalisesta koodaamisesta. On siis tehty asiat niin että ne toimii, mutta ei yhtään kiinnitetty huomiota siihen miten tehokkaasti ne toimii. Samoja lookuppeja saatetaan tehdä moneen kertaan ja muuta vastaavaa todella typerää. Loopin sisällä haetaan tietoja, jotka olisi voitu noutaa jo kertaalleen valmiiksi ennen looppia tms. Noista sitten kertautuu melkoinen roskakuorma. Profilointi on jo otettu suunnitelmaan. Koska systeemi imee mehut myllystä kuin myllystä ihan kevyesti.
Jep, moinen saman datan jatkuva turha haku saa myllyn ku myllyn jumiin. Klubbarissa on MySQL:ssä käytössä query cache, eli haetut kyselyt tallennetaan cacheen ja jos sama kysely tehdään uudestaan niin tulokset haetaan cachesta eikä käydä taas tauluja läpi. Sen lisäksi webbipuolella on käytössä memcache missä on tallessa paljon usein haettua dataa, eli läheskään kaikkea tavaraa ei tarvii kysellä edes kannasta asti.. molemmat nopeuttaa systeemiä varsin tuntuvasti jo melko pienillä muistimäärillä, eikä nykyklubbari ees hyödynnä memcachea läheskään niin paljon kun voisi.. uus tulee hyödyntämään moninkertaisesti eli tulee nopeutumaan entisestään :)
sts, 17.9.2007 21:12:
paskasta järjestelmästä puheenollen: BEA-Weblogic server ja oracle, pyörittämässä kahden koneen solaris klusteri, kyykyssä 100 ihmisen loadista :D (kokemuksia työkomennuksesta eräässä it-alan yrityksessä)
Apo
Millä tahansa ohjelmointikielellä on äärettömän helppoa tehdä tehottomia toteutuksia, joiden optimoidut versiot voivat suoriutua hommasta mikrosekunneissa vuosien sijaan.
Apo, 17.9.2007 21:47:
--- teknokraatti, 17.9.2007 20:35:
Tietysti alusta mysql + tomcat on jo muutenkin törkeän raskas. Mutta vielä tekemällä toteutuksen suorituskykyä ajattelematta saadaan systeemistä järjettömän hidas ja raskas.
---
MySQL ja Tomcat "törkeän raskaita"? MySQL käytössä joidenkin todella isojen saittien taustalla ja ei se Tomcat:kaan taida olla kovin paljon hitaampi kuin kilpakumppaninsa. Veikkaisinkin että teillä raskauteen syyt on ennemminkin muualla :p
Voisin melkei sanoa että nuo on kaupallisiin isoveljiinsä verrattuna yleisestiottaen huomattavasti kevyempiä :)
Ei olla vielä paneuduttu tuohon asiaan että mistä se surkea suorituskyky johtuu tarkalleen. Mutta raudasta se ei ainakana johdu. ;) Tosin vanha totuus on se, että on paljon halvempaa ostaa tehokkaampaa rautaa kuin korjata softassa olevia ongelmia. Ellei profiloinnissa sitten paljastu jotain ihan olennaisesti pielessä olevaa. Kuten oletan paljastuvan.
MySQL:n cache on jo päällä. Sitten on myös muutamia slow queries sarjaan kuuluvia kyselyitä jotka eivät käytä indeksiä. Nuo ainakin pitää korjata.
P.S. IP osoitteen näyttäminen on todella tökeröä. Varsinkin kun koko C class kuuluu firmalle.
Klubituksesta...
uus tulee hyödyntämään moninkertaisesti eli tulee nopeutumaan entisestään :)
Tällä hetkellä näyttää siltä palvelimeksi hommataan Quad Core Xeon 3 GHz, Raid 5 kolmella 500 gigasella SAS levyllä ja käyttikseksi Server 2003 ja 4 gigalla muistia, kun taidetaan pysyä 32 bittisessä alustassa.
Tuolla pitäisi jo webbisiten pyöriä toivottavasti kohtalaisesti. Tosin todennäköisesti joudutaan hankkimaan myös pari muuta konetta, kun tuo ei yksistään riitä.
= kone ilmeisesti :P