Opened 9 years ago

Closed 7 years ago

#2775 closed enhancement (expired)

cacheexenablestats only per CAID or only per CAID:IDENT

Reported by: superg1972 Owned by: alno
Priority: minor Component: Webinterface
Severity: low Keywords: CACHE-EX
Cc: triplekarme@… Sensitive: no

Description

Reason for enhancement

So far the parameter cacheexenablestats creates a report for cacheex, but it report CAID:IDENT:SERVID. In case of a medium or high usage of cache ex it creates an huge list of channels.
It would be more useful to have a list only per CAID or per CAID:IDENT.

For example an user could select the parameter as it is now, if he wants to see all the channels given, or he could select the report only per CAID or per CAID:IDENT.

We could have
3 = enable statistics for cach exchange mode CAID
2 = enable statistics for cach exchange mode CAID:IDENT
1 = enable statistics for cach exchange mode CAID:IDENT:SERVID
0 = default

Possible impacts on other features

I don't know

Change History (8)

comment:1 by CapNCooK, 9 years ago

Cc: triplekarme@… added
Keywords: CACHE-EX added

Would be nice to have this feature.. I vouch for it!

comment:2 by Admin, 9 years ago

Try that and report if it does what you want: In module-cachex.c under

int32_t cacheex_add_stats(struct s_client *cl, uint16_t caid, uint16_t srvid, uint32_t prid, uint8_t direction)
{

if (!cfg.cacheex_enable_stats)

return -1;

add

if(cfg.cacheex_enable_stats==3){

srvid=0;
prid=0;

} else if(cfg.cacheex_enable_stats==2){

srvid=0;

}

comment:3 by CapNCooK, 9 years ago

Thx admin! I tested but the list gets so big in both new modes, it instantly crashes any browser except internet explorer..

A custom filter for CAID:IDENT:SRVID would be a nice solution. Also useful is another custom filter for CAID:IDENT to see which peers is sending it. (sorted on amount)

Thanks!

comment:4 by Admin, 9 years ago

If you make it specific to CAID (cacheex_enable_stats=3), there shouldn't be that many CAIDs out there that the website gets too big?

comment:5 by CapNCooK, 9 years ago

It is indeed less, with c_e_s = 3, compared to = 2.

Still, i have 5600 lines outputted currently with c_e_s=3.
(130 cache peers connected). Plus, the stats are not 'maintained', so it only grows and grows.

This function has no use other than for debugging cache.. gathering stats on normal runtime causes CPU to go through the roof and is useless because of that.

Therefore..

Temp. selection on CAID:IDENT for debug (should output the peers that transport it with count) would be very useful.

Same goes for selection on peer (user/reader) and output like it is now with c_e_s = 2.

thx

comment:6 by Admin, 9 years ago

I don't think there is a real solution for your problem without breaking it for "normal" users or creating many new config parameters (which we really don't want as there are already way too many) - you are just having too many cachex-peers to have reasonable stats. There could be some performance improvement made by hashing the list (it is already held separetly by client) but when you already set it to log the caid only (iterating those lists like we do now is rather costly and some direct implementation could be faster), the improvement should be rather small currently.

Putting in maintenance would even grow the memory consumption and probably create more performance problems - it would be sure nice to say that we are only interested in the last x hours, but that would mean to hold every request and not just the aggregate that we hold now (or at least hold an aggregate for every minute or so). Otherwise you could only completely reset the stats and begin really from zero...

comment:7 by CapNCooK, 9 years ago

OK.

I think we just differ from opinion. The amount of peers doesnt say anything about the contents of the cache-size. My client-oscam (receiver) has the same cache-contents as my bigger cache-server does.

Currently enabling stats on either of them (in current SVN build) sends CPU through the roof. Plus.. for a what-you-call "normal" -oscam, the stats are not useful when having just one or two lines. For mainly these reasons, _everyone_ (i know) has stats set to OFF.

So, in my opinion, current implementation of the CACHE-EX "write statistics" for use on normal operation doesnt really make sense.

--

Again, a _debug_ feature for logging cache-ex (that is.. turn it on, gather stats, turn it off) is very useful. This demand will grow with all people trying to connect CSP and MultiCS to oscam.. but only.. with some filtering can be applied.

Just my 2 cts, thx for thinking with me!
(we might want to take this to forum)

comment:8 by Deas, 7 years ago

Resolution: expired
Status: newclosed
Note: See TracTickets for help on using tickets.