Project

General

Profile

Actions
Copy link

Bug #546

closed

warden-server-2.1: pomale zpracovani volani getStatus

Added by Tomáš Plesník over 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Low
Assignee:
Tomáš Plesník
Category:
-
Target version:
2.1
Start date:
09/07/2012
Due date:
% Done:

0%

Estimated time:

Description

Pri zjistovani stavu serveru pomoci volani funkcce getStatus mame problem s dlouhou odezvou, nez funkce neco vrati. Problem je v casti, kdy server z DB zjistuje kolik ktery klient zaslal na server udalosti a kdy tomu tak bylo naposled.

Actions
Copy link
 #1

Updated by Tomáš Plesník over 12 years ago

Jako reseni zde vidim, vytvoreni provozni tabulky clients.stats:

CREATE TABLE clients.stats
(
client_id int,
events_count int,
last_received_event timestamp
)

ktera bude updatovana po kazdem ulozeni udalosti od daneho klienta. Tak ziskame stale aktualni a predpripravene hodnoty, ktere pouze posleme na serveroveho klienta bez cekani.

Actions
Copy link
 #2

Updated by Pavel Kácha over 12 years ago

Vedlejší tabule opět není dobrý nápad - všechny běžné getNewEvents a saveNewEvent, kterých je většina, tím zatížíš o další update db, zatímco getStatus, které se používá zřídka a jen správcem, bude suprově frčet.

Myslím, že by spíš stálo za to zvážit, zda smyčka, pokládající dotazy pro každého klienta, je potřeba, zda by to nevyřešil například group by, a zda jsou na správných sloupcích pro správné dotazy ty správné indexy.

Actions
Copy link
 #3

Updated by Pavel Kácha over 12 years ago

  • Priority changed from Normal to Low

SELECT clients.client_id, clients.hostname, clients.service, count(*), max(received) FROM events LEFT JOIN clients ON (events.hostname=clients.hostname AND events.service=clients.service) GROUP BY hostname, service;

Budu-li chtít zahrnout i klienty, kteří nic neposlali, musel bych JOIN obrátit a byli bychom výkonově tam kde jsme byli. Druhá varianta je doplnit seznam získaný předchozím selectem (o zbývající klienty z tabulky clients - to budou ti, kteří nemají žádný záznam v events), ale MySQL nepodporuje INTERSECT a EXCEPT, takže by to bylo lze udělat jen pomocí MySQL obšuku. Pokud chceme zůstat rozumně databázově nezávislí, přímo z Perlu bych zavolal SELECT client_id, hostname, service, 0, NULL FROM clients; ručně z výsledku vyřadil řádky, které jsem získal prvním SELECTem, seřadil, vypsal.

Actions
Copy link
 #4

Updated by Pavel Kácha over 12 years ago

A - ano - ještě něco udělat s řádkem NULL, NULL, NULL, hausnumero, hausčas, který ve výsledku popisuje počet zpráv od klientů, kteří nejsou v tabulce clients. K tomu by teoreticky nemělo dojít, ale pravděpodobně někdo přejmenoval ručně buldog.vsb.cz na buldocek.vsb.cz, takže máme trošku podělanou referenční integritu.

Actions
Copy link
 #5

Updated by Tomáš Plesník about 12 years ago

  • Status changed from New to Resolved

Hotovo a nakomitovano viz revize 85924b79.

Nakonec jsem zvolil zlatou stredni cestu. getStatus.pl vytiskne pouze serazene statistiky "aktivnich" klientu podle ID klienta (pouze klientu, kteri do wardenu neco zaslali), jelikoz je vice mene nezajimave, ze nekdo nic neposlal. Tuto informaci je navic pomerne jednoduche zjistit tak, ze se tento klient nenachazi ve vypisu getStatus.pl. Dale pak, pokud se tisknou i klienti, jejichz pocet odeslanych udalosti se rovna 0, tak se nadmerne zasira vypis getStatus.pl tisknuty na obrazovku a clovek pak musi rolovat aby vubec nasel klienty, kteri neco poslali o coz mu v prve rade vlastne nejvic jde.

Ticket tedy uzaviram.

Actions
Copy link
 #6

Updated by Pavel Kácha about 12 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF