• EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Topic: Globalūs kintamieji

Sveiki forumo dalyviai,

Norėčiau sulaukti šokios tokios konsultacijos.

Yra kuriamas vienas ganėtinai sudėtingas moduliukas ir reikėtų pagalbos.

Situacija tokia,kad reikia kažkokiu tai optimaliausiu ir mažiausiai resursų naudojančiu būdu sukurti globalius kintamuosius.

Ką reiškia globalūs, jis reiškia, kad naujas vartotojas užsukęs į tinklapį jau būtų įtraukiamas į globalų masyvą kuriame jau yra įtraukti šiuo metu tinklapyje esantys nariai.
Masyvo struktūra:

{
   [0] => 'vartotojo unikalus id',
   [1] => 'vartotojo laikas kai jis buvo įtrauktas į masyvą'
}
  • From: Vilnius
  • Registered: 2008-06-11
  • Posts: 1,254

Re: Globalūs kintamieji

Na manau geriausia yra laikyti sesijas DB, o tada kai reikia - paskaičiuoji kiek yra aktyvių.

MongoDB Certified Developer
MongoDB Certified DBA
Zend Certified Engineer

3 Reply by EriX (edited by EriX 2012-01-17 11:01:00)

  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

į duomenų bazę kreiptis negalima, šis modulis ir yra kuriamas tam, kad pavyktų apsaugoti duomenų bazę nuo "perkaitymo".

Nes būna atveju kai duomenų bazę nespėja apdoroti užklausų kurios ateina per vieną sekundę.

  • Registered: 2010-12-28
  • Posts: 110

Re: Globalūs kintamieji

EriX wrote:

Nes būna atveju kai duomenų bazę nespėja apdoroti užklausų kurios ateina per vieną sekundę.

Nespėja vadinas biški palagins ir apdoros.. plius nereikia kurti "sunkių" sistemų ant krepovų hostingų. Beje kurioje vietoje tuos "globalius kintamuosius" planuoji saugoti? .txt failuose?:)

No warning? No action? I hate this situation!
  • From: Vilnius
  • Registered: 2008-06-11
  • Posts: 1,254

Re: Globalūs kintamieji

Na dar variantas koks nors APC cache, arba kažkas analogiško. Bet jei netyčia išskirstysit application serverius - sistema grius. Nebent naudos bendrą pvz memcache serverį...

MongoDB Certified Developer
MongoDB Certified DBA
Zend Certified Engineer
  • Registered: 2009-03-06
  • Posts: 498

Re: Globalūs kintamieji

Duomenis galima saugoti ir kokiam memcachede ir db. I db irasineti galima tik sukuriant sessija, kad kiekviena requesta nedubasinti. Jei ne paslaptis, tai kiek requestu per sekunde turi i db? Siaip laguojanti db dazniausiai reiskia, kad blogai suprojektuota db arba serveriai labai jau pasene.

  • From: Vilnius
  • Registered: 2008-06-11
  • Posts: 1,254

Re: Globalūs kintamieji

Dar yra toks dalykas kaip query cache ir verta žinoti kada jis suveiks ir kada ne

.. ' WHERE time >= '.time()-kazkiek_sekundziu.' ; // cache neveiks
.. ' WHERE time >= '.round(time()-kazkiek_sekundziu,-1).' ; // cache veiks 10 sek

Aišku yra variantas, kad query cache neįjungtas išvis.

Iš esmės problemų gali būti daugybė. Sprendimų irgi :)

MongoDB Certified Developer
MongoDB Certified DBA
Zend Certified Engineer
  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

xeranas wrote:
EriX wrote:

Nes būna atveju kai duomenų bazę nespėja apdoroti užklausų kurios ateina per vieną sekundę.

Nespėja vadinas biški palagins ir apdoros.. plius nereikia kurti "sunkių" sistemų ant krepovų hostingų. Beje kurioje vietoje tuos "globalius kintamuosius" planuoji saugoti? .txt failuose?:)

nėra jokio hostingo, puslapis sukasi ant serverio masyvo(bleido) kuris ne dešimt ir ne dvidešimt tūkst.lt. kainuoja ir jų ne vienas. .txt failai yra viena iš galimybių tačiau šiuo metu ieškoma alternatyvos.
O,kad nespėja ir apdoros tai toks variantas netinka, viskas vyksta realiu laiku, pardavimai realiu laiku todėl reikia,kad užklausos įvykdymas nebūtų ilgesnis nei 150 ms.(Išskyrus detalias ataskaitas.)


Neodan wrote:

Duomenis galima saugoti ir kokiam memcachede ir db. I db irasineti galima tik sukuriant sessija, kad kiekviena requesta nedubasinti. Jei ne paslaptis, tai kiek requestu per sekunde turi i db? Siaip laguojanti db dazniausiai reiskia, kad blogai suprojektuota db arba serveriai labai jau pasene.

Užklausų per sekundę kiekis siekia nuo 15 iki 180. Priklausomai nuo dienos meto.

9 Reply by Neodan (edited by Neodan 2012-01-17 14:40:51)

  • Registered: 2009-03-06
  • Posts: 498

Re: Globalūs kintamieji

Na gal uzklausos daug sveriancios, kad servai nespeja su jomis susidoroti. Nes turim viena projekta kur senukas servas be vargo atlaiko ir ~150 qps :) Siaip vietoj txt failu naudojimo rekomenduociau pvz. koki memcached. Duomenis bus saugomi rame, taigi greitis bus didelis, prie informacijos gales prieiti visi scriptai.

  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

na dėkui už patarimą, kažką reikės sugalvoti.

  • Registered: 2009-03-06
  • Posts: 498

Re: Globalūs kintamieji

O siaip rekomenduociau panalyzuoti kas pas jus db taip lagina (gal blogai sukonfiguruoti, o gal yra labai neoptimaliu queriu kurie labai stabdo sistema).

  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

Neodan wrote:

O siaip rekomenduociau panalyzuoti kas pas jus db taip lagina (gal blogai sukonfiguruoti, o gal yra labai neoptimaliu queriu kurie labai stabdo sistema).

Optimizuotos buvo visus įmanomos funkcijos kurios buvo bent kiek sudėtingesnės.
Tai buvo darbas numeris vienas siekiant sumažinti sistemos lūžinėjimus, tačiau tai padėjo tik laikinai kol nepagausėjo klientų.
Dabar ieškome naujo būdo atlaikyti srautus su turima serverio įranga, kad įrangos infrastruktūra gerintume tik tuomet kai bus atlikti visi įmanomi žingsniai ir kitos išeities jau nebebus.

  • Registered: 2009-03-06
  • Posts: 498

Re: Globalūs kintamieji

Na nezinau ar padaret, bet jei didelis vartotoju srautas, tai reiktu pradeti kesuoti retai kintancia, bet daznai naudojama infa. Kesuoti galima labai sekmingai ir i memcached :) Kartais net ir infos kesavimas keliolikai minuciu duoda dideli pagreitejima.

  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

Neodan wrote:

Na nezinau ar padaret, bet jei didelis vartotoju srautas, tai reiktu pradeti kesuoti retai kintancia, bet daznai naudojama infa. Kesuoti galima labai sekmingai ir i memcached :) Kartais net ir infos kesavimas keliolikai minuciu duoda dideli pagreitejima.

šitas variantas irgi buvo svarstomas, yra kešuojame nemaža dalis info tačiau pagrindinės dalies kuri sukelia didžiausias problemas negalime kešuoti nes informacija keičiasi sekundžių tikslumu, o informacijos mastai yra labai dideli.

  • minde
  • Administrator
  • Offline
  • Registered: 2006-06-14
  • Posts: 4,003

Re: Globalūs kintamieji

Ne viską skaičiau, todėl gal ir pasikartosiu: yra MySQL'e toks lentelių tipas kaip MEMORY/HEAP. Sesijom dažniausiai labai gerai tinka tiek iš logikos pusės, tiek iš to, kad viskas saugoma RAM'e, bet veikia SQL'as.

(taip pat sesijų duomenis galima saugoti RAM'e ir be MySQL'o pagalbos, o pasinaudojant memory-disk'u arba memcache (galima overridinti sesijų saugojimo mechanizmą).

minde's Website

  • EriX
  • Member
  • Offline
  • Registered: 2008-10-16
  • Posts: 25

Re: Globalūs kintamieji

Užmiršau paminėti turbūt: db strukūtra PostgreSQL.

  • Registered: 2009-02-17
  • Posts: 333

Re: Globalūs kintamieji

node.js?

  • From: Vilnius
  • Registered: 2008-06-11
  • Posts: 1,254

Re: Globalūs kintamieji

Aš visgi išskirstyčiau duomenis po skirtingas dėžes, jei neklystu buvo paminėta, kad yra keletas serverių. Vienas serveris rūpinusi didele duombaze (paruoštų naktį duomenis greitam skaitymui ir pan), o mažesnė duombazė rūpintusi tarkime šios paros duomenimis kurie nuolat keičiasi. Sesijos galėtų būti toje antroje DB. Tuomet galima optimizuoti serverius pagal tai ką jie daro.
Kur aš linkstu? http://upload.wikimedia.org/wikipedia/c … erview.JPG

MongoDB Certified Developer
MongoDB Certified DBA
Zend Certified Engineer
  • minde
  • Administrator
  • Offline
  • Registered: 2006-06-14
  • Posts: 4,003

Re: Globalūs kintamieji

Reikia žiūrėt sistemiškai:
a) kiek yra tų, norimų išsaugoti duomenų;
b) kaip dažnai jie keičiasi (rašymai/skaitymai/atnaujinimai);
c) kokie yra laisviausi resursai sistemoje;

Pirmas ir lengviausias sprendimas: viską laikyti RAM'e, nes panašu, kad duomenų mažai, bet jų reikia "gyvų" kiekvieno puslapio krovimo metu. Todėl netsvarbu ar MySQL'as, ar PostgreSQL'as. Tikslas vienas - saugoti RAM'e, kaip jau minėjome yra tokie dalykai kaip memcache, jeigu jau DBVS neturi RAM/MEMORY saugojimo variklio. (MySQL'o atveju netgi paprasta lentelė būtų laikoma RAM'e, jeigu ji būtų labai dažnai naudojama - "hot").

minde's Website