• http://svn.drutt.com/dev/dac/cnni/source/user_identification/trunk/src/java/com/drutt/cnni/pmm/runtime/ee/integration/SetupUserContextViaCookieOnDevice.java uses UID which has a time component, allowing reliable pruning.

• Time looking up user in CNNi database;

• Check userAgentFilter in http://svn.drutt.com/dev/dac/musca_core/source/user_identification/trunk/src/java/com/drutt/muscacore/pmm/runtime/ee/integration/SetupUserContextViaCookieOnDevice.java should this be a set?

http://svn.drutt.com/dev/dac/cnni/source/reporting/trunk/src/java/com/drutt/cnni/pmm/runtime/ee/portal/GetCountryFromAddress.java

• Why is this splitting blocked countries on each request?

http://svn.drutt.com/dev/dac/cnni/source/reporting/trunk/src/java/com/drutt/cnni/reportengine/geoip/CountryLookupServiceFactory.java

• How does this handle database? Is probably not database, but a file.

http://svn.drutt.com/dev/dac/cnni/source/reporting/trunk/src/java/com/drutt/cnni/pmm/runtime/ee/portal/IdentifyVoxCustomers.java

* This recalculates ranges on each lookup.

Runs every 6 seconds, takes 1 second and uses 8% cpu

select count(*) from t$cxrm$asset a where a.a$type = :1 and (a.a$meta9 like :2 escape :"SYS_B_0" or a.a$meta9 like :3 escape :"SYS_B_1")and exists (select :"SYS_B_2" from t$cxrm$item i, t$cxrm$group g where g.ref_asset = a.id$key and i.ref_group=g.id$key and g.a$type in (:4) and ( not exists (select :"SYS_B_3" from t$cxrm$device where ref_group=g.id$key) or exists (select :"SYS_B_4" from t$cxrm$device d where ref_group=g.id$key and d.a$deviceid = :5) )) and ((a.a$complete=:"SYS_B_5" and a.a$deployed=:"SYS_B_6" and :6 >= a.a$starttime and lnnvl(a.a$validuntil < :7)))

Runs every 6 seconds and takes 1 second to complete. 8% cpu

select /*+ FIRST_ROWS */ id$key, r from (select a.id$key, row_number() over (order by a.id$key desc) r from t$cxrm$asset a where a.a$type=:1 and (a.a$meta9 like :2 escape :"SYS_B_0" or a.a$meta9 like :3 escape :"SYS_B_1")and exists (select :"SYS_B_2" from t$cxrm$item i, t$cxrm$group g where g.ref_asset = a.id$key and i.ref_group=g.id$key and g.a$type in (:4) and ( not exists (select :"SYS_B_3" from t$cxrm$device where ref_group=g.id$key) or exists (select :"SYS_B_4" from t$cxrm$device d where ref_group=g.id$key and d.a$deviceid = :5) )) and ((a.a$complete=:"SYS_B_5" and a.a$deployed=:"SYS_B_6" and :6 >= a.a$starttime and lnnvl(a.a$validuntil < :7)))) where r between :8 and :9

For CNNi we could remove the unique users functionallity since it is not being used. However, it seems to be used for the other portals, so this is not long term solution. Maybe we can reduce the unique items counted, today it is for all portals, pages, modules, services and providers (more?).

For some reason there are a lot of users in the database. About 71000000 for CNNi and approx 8000000 for the other two portals. The user ids (at least for CNNI) are on the form <machineid>-<timestamp>-<sequence>. The high number of CNNi users together with the format of their ids is both taking up a lot of storage space probably a unbalanced index tree (can this be visualized?). The database should probably be pruned, initially by truncating the table and the schedule a job which deletes users which have been inactive for a certain time, say a week or a month.

We have to investigate why the number of users is so high. Talking to the developers there should be a persistent cookie set which should make most users identifiable over time. This should be verified.

I also found from initial reviewing the log files that there seemed to be a lot of requests from Blackberry devices requesting favicon.ico. Perhaps they don't send cookies for this request. That could be causing the high number of created users. Can we trace such a request to see what headers is passed. Perhaps someone could do a tcpdump over a few minutes time?

If many devices access favicon.ico we should either add this or prevent such a request from logging an error as this request is anticipated.

For CNNi we could prevent unique files from being created by report engine. This would reduce the disk space needed and probably also improve performance. We should also investigate if gzipping the files would actually improve performance (although costing some CPU cycles). The code for gzipping is already in place. Unique is used by the other installations, so it would not be a solution for those cases. The items to count uniqueness for could also be reduced.

There seems to be a a problem running report engine for CNNi. Currently it seems to be hanging. (Please send me the stacktrace in the nohup-reportengine.log). If there are other errors in the event.log for report engine I also need to look at those.

There seems to be some issue with connection pooling. I will review the settings at home, but would also like to get access with a debugger to port 8000 to re24-1. I would want to catch a request generated by me to see the current status of the connection pool.

Some code should also be reviewed. I don't think it is causing a big problem, but there are code executed for each request that just needs to be initialized once. This adds processing time and garbage generation for each request.