Santrauka: Šiame straipsnyje paaiškinama, kad „Odoo“ serverio procesų (workers) skaičiaus parinkimas turėtų būti grindžiamas piko metu vykstančių lygiagrečių veiksmų skaičiumi ir realiais vartotojų atliekamais darbais, o ne vien tik bendru vartotojų skaičiumi. Didžiausios apkrovos laikotarpiais tokios intensyvios operacijos kaip sandėlio patvirtinimai, ataskaitų generavimas, apskaitos paketinis apdorojimas ir integracijos gali ilgam užimti serverio procesus. Sandėlio operacijų gausiose sistemose lygiagrečios operacijos dažnai susiduria ties stock.quant (centrinė Odoo sandėlio likučių lentelė, kurioje realiu laiku saugomi prekių kiekiai pagal vietas), todėl atsiranda duomenų bazės užraktai ir pakartotiniai bandymai, sukeliantys, atrodytų, „atsitiktinius“ sistemos sulėtėjimus. Straipsnyje taip pat pateikiamas praktinis metodas, kaip parinkti tinkamą serverio procesų skaičių, ir parodoma, kaip susidūrimų mažinimas (trumpesnės transakcijos, mažiau bendrų „karštųjų taškų“ ir geresnis prekių paskirstymas pagal sandėlio vietas) padeda pasiekti stabilų sistemos našumą.
|
Kodėl viskas priklauso nuo lygiagretaus darbo intensyvumo ir to, ką realiai daro vartotojai, o ne vien nuo jų skaičiaus
Šiame straipsnyje paaiškinama, kaip parinkti „Odoo“ serverio procesų (workers) skaičių, remiantis piko metu vykstančių lygiagrečių veiksmų intensyvumu ir realiais vartotojų atliekamais darbais, o ne vien bendru vartotojų skaičiumi. Taip pat parodysime, kaip intensyvios piko valandų operacijos, ypač sandėlio veiksmai, susiduriantys ties stock.quant (centrine Odoo sandėlio likučių lentele), sukelia duomenų bazės užraktus ir pakartotinius bandymus, dėl kurių Odoo sistema gali atrodyti „atsitiktinai lėta“.
Verslo atvejis
Vienas iš mūsų klientų – maisto papildų gamintojas, turintis elektroninę parduotuvę ir didmeninės prekybos kanalą – kasdien susidurdavo su tuo pačiu scenarijumi: kiekvieną rytą sandėlio darbuotojai pradėdavo vykdyti per naktį gautus internetinius užsakymus, buhalteriai registruodavo apskaitos įrašus, o pardavimų skyrius tuo pačiu metu tvirtindavo didmeninius užsakymus. Būtent tuo metu „Odoo“ sistema tapdavo itin lėta.
Kodėl taip nutinka? Ar tai reiškia, kad „Odoo“ netinka didelės operacinės apkrovos verslams? Ir kuo čia susiję „Odoo“ serverio procesai (workers)?
Panagrinėkime tai išsamiau.
Kas yra „Odoo“ serverio procesai?
„Workers“ – tai papildomi serverio procesai, leidžiantys „Odoo“ vienu metu aptarnauti kelis vartotojus ir jų užklausas.
Klausimas „Kiek serverio procesų (workers) reikia Odoo sistemai?“ skamba tarsi paprastas serverio pajėgumo parinkimo uždavinys. Dažniausiai jis pradedamas skaičiais: turime 40 vartotojų, 120 vartotojų, planuojame augti iki 200 vartotojų.
Tačiau toks požiūris retai leidžia gauti teisingą atsakymą.
Serverio procesams nesvarbu, kiek egzistuoja vartotojų paskyrų. Jiems svarbu kiek veiksmų vyksta vienu metu – ir kiek resursų tie veiksmai reikalauja.
Serverio procesai parodo, kiek intensyviai „Odoo“ yra apkrauta bet kuriuo konkrečiu momentu
„Worker“ – tai „Odoo“ gebėjimas apdoroti užklausas. Kai vartotojai spusteli, skenuoja, patvirtina, registruoja, spausdina arba ieško, šie veiksmai sunaudoja serverio procesų (workers) laiką. Jei pakankamai daug veiksmų įvyksta tuo pačiu metu, procesai užimti, o naujos užklausos pradeda laukti.
Būtent tada žmonės kartais apibūdina „Odoo“ kaip „lėtą“, nors sistema techniškai veikia.
Vietoje klausimo „Kiek turime vartotojų?“ geriau klausti: „Kiek lygiagrečių veiksmų vyksta piko metu?“ |
Svarbiausias serverio procesų parinkimo veiksnys: lygiagretumas
Lygiagretumas reiškia, kiek užklausų vienu metu pasiekia „Odoo“, ypač per jūsų pačias užimčiausias valandas.
Įprastas realus pavyzdys:
- 15 sandėlio darbuotojų skenuoja ir patvirtina operacijas
- 10 pardavėjų tvirtina užsakymus
- integracija foniniu režimu įkelia užsakymus
Viskas vyksta vienu metu, kiekvieną dieną nuo 10:00 iki 12:00 val.
Būtent šis momentas nustato reikalingą serverio procesų (workers) skaičių, o ne licencijoje nurodytų vartotojų skaičius.
Kodėl lygiagretumas gali sukelti „netikėtai lėtą“ Odoo našumą
Jei jūsų verslas intensyviai naudoja sandėlį, yra viena vieta, kur lygiagretumas tampa ypač matomas: stock.quant.
stock.quant yra centrinė lentelė, rodanti „kas kiek ir kur yra“. Ji nuolat naudojama šių operacijų metu:
- rezervacijos ir atšauktos rezervacijos
- brūkšninių kodų (barcode) darbo procesai
- rinkimo (picking) patvirtinimas
- prekių priėmimai, išsiuntimai, vidiniai perkėlimai
Svarbiausia: šios operacijos dažnai veikia tuos pačius produktus ir lokacijas, ypač su greitai judančiomis prekėmis.
Kai keli vartotojai (ar automatizuoti procesai) bando vienu metu atnaujinti tą patį sandėlio likutį, „Odoo“ ir PostgreSQL turi užtikrinti duomenų nuoseklumą. Ši apsauga dažniausiai pasireiškia:
- viena transakcija laukia kitos (užraktai – locking)
- operacija susiduria su konfliktu ir bandoma iš naujo (retries)
Ir tie pakartotiniai bandymai nėra smulkmena – jie keičia visą vartotojo patirtį.
Užklausa, kuri paprastai vykdoma greitai, gali staiga užtrukti daug ilgiau, ne dėl paties veiksmo, o dėl to, kad ji susidūrė su kitomis tuo pačiu metu vykstančiomis operacijomis, liečiančiomis tuos pačius stock.quant.
Dėl to komandos dažnai patiria tokius scenarijus:
- „Rinkimo patvirtinimas paprastai vyksta greitai… bet kartais užtrunka 10–20 sekundžių.“
- „Odoo veikia sklandžiai, kol neateina sandėlio piko laikas – tada viskas stringa.“
Viskas vyksta paprastai: didesnis lygiagretumas → daugiau konfliktų → daugiau pakartotinių bandymų → serverio procesai (workers) ilgiau užimti → didesnė delsos (latency) trukmė.
Todėl sandėlio sistemose serverio procesų skaičiaus parinkimas neturi būti grindžiamas „kiek yra sandėlio vartotojų“, o „kiek sandėlio operacijų susiduria vienu metu“.
Praktinė išvada apie „Odoo“ serverio procesų parinkimą
Kalbant apie „Odoo“ serverio procesus, verta susitelkti į tris klausimus:
- Ką
vartotojai iš tikrųjų daro Odoo?
Atminkite, kad lengvas įrašų peržiūrėjimas elgiasi visiškai kitaip nei brūkšninių kodų skenavimas, patvirtinimai ir ataskaitų generavimas. - Kada
yra didžiausias apkrovos laikas (dienos ar mėnesio piko
valandos)?
Serverio procesai turi ištverti piko momentus, o ne tik vidutines apkrovas. - Kur
operacijos susiduria bendruose įrašuose?
Sandėlio operacijos dažnai susiduria ties stock.quant (greitai judančios prekės, populiarios lokacijos). Šie susidūrimai sukelia pakartotinius bandymus (retries), kurie padidina delsą (latency) ir ilgina serverio procesų užimtumą.
Tai yra pagrindinė idėja.
Kaip parinkti „Odoo“ serverio procesų skaičių
Pagal oficialią „Odoo“ dokumentaciją, galima skirti 1 serverio procesą (worker) kiekvieniems 6 lygiagrečiai veikiančių vartotojų arba naudoti formulę: (#CPU x 2) + 1, kurią paaiškinome straipsnyje apie „Odoo“ aparatūros reikalavimus. Tačiau, jei kalbame apie intensyviai dirbančius verslus su daug galimų lygiagrečių operacijų, tai tik pradinė gairė. Iš čia formulė koreguojama pagal jūsų įmonės faktinę situaciją arba realius duomenis.
Mūsų požiūris – palaipsniui didinti serverio procesų (workers) skaičių ir tuo pačiu mažinti kliūtis, kurios didina sistemos apkrovą.
|
Kiekviename žingsnyje atliekame:
- automatinį „Odoo“ našumo testavimą (t. y. pakartojamą apkrovą)
- testus su tikrais sandėlio darbuotojais, atliekant įprastus darbus (pvz., skenavimą/patvirtinimą, užsakymų tvirtinimą ir pan.)
Ir matuojame dvi pagrindines reikšmes:
- „Odoo“ atsakymo laiką (ypač lėtą „uodegą“ – tai užklausos, dėl kurių vartotojai dažniausiai skundžiasi)
- lygiagrečių operacijų klaidas SQL žurnaluose (serialization failures / concurrent update – tai rodo pakartotinius bandymus ir susidūrimus)
Serverio procesų (workers) skaičiaus didinimą stabdome, kai rezultatai tampa stabilūs: pvz., atsakymo laikai išlieka priimtini piko metu, o lygiagrečių operacijų klaidos sumažėja iki tokio lygio, kad nebekyla pastebimų sistemos strigimų.
Kaip sumažinti susidūrimus (kad serverio procesai neužstrigtų pakartotiniuose bandymuose)
Jeigu jūsų sistemos našumo problema kyla dėl stock.quant konfliktų, papildomi serverio procesai (workers) padeda tik iki tam tikros ribos. Daugiausiai efekto duoda šie sprendimai:
- Greitai judančias prekes paskirstykite per daugiau lokacijų arba vietų (bins), kad tie patys SKU nuolat nekeistų tų pačių stock.quant įrašų.
- Venkite ilgų transakcijų pritaikymuose ir integracijose. Tai reiškia: nepalikite atidarytų duomenų bazės transakcijų, kol kviečiate išorinius API, generuojate didelius failus ar atliekate sudėtingus ciklus.
- Perkelkite sunkias operacijas iš vartotojo interaktyvių veiksmų į fono arba asinchroninius procesus, kur tai įmanoma. Tokiu būdu vartotojo veiksmai bus trumpi, o duomenų užraktai bus atlaisvinami greičiau.
Praktinė išvada: serverio procesų (workers) skaičių reikėtų nustatyti pagal realų sistemos lygiagretumą, o susidūrimų mažinimą laikyti priemone, kuri padeda paversti netolygų atsakymo laiką į stabilų sistemos veikimą.
Išvada
Skaičiuodami „Odoo“ serverio procesus (workers), nesivadovaujame vien vartotojų skaičiumi. Vietoje to pradedame nuo darbo krūvio ir lygiagretumo. Jei turite užimta sandėlį, lygiagrečių veiksmų „karštieji taškai“, tokie kaip stock.quant, gali sukelti užraktų laukimą ir pakartotinius bandymus, dėl ko „įprastos“ operacijos piko metu tampa lėtos.
Todėl vienodas vartotojų skaičius skirtingose įmonėse gali reikėti labai skirtingo serverio procesų kiekio, o bandymas parinkti procesus vien tik pagal vartotojų skaičių yra viena iš dažniausių priežasčių, kodėl „Odoo“ gamybinėje aplinkoje gali atrodyti lėtas.
„Odoo“ serverio procesai nėra vienintelis našumą lemiantis veiksnys – norite išspręsti savo „Odoo“ problemas?
Teksto autorius:
Veronika Kotovich
VentorTech Vyresnioji Odoo programuotoja