1. 100K ACTIVE CLIENTS SOLUTION Version: 18 May 2015

2. Some Constraints (to simplify / de-risk) 100K ENABLED clients … … but not 100K clients all posting 24 x 7. –We will support 100K enabled clients on the assumption that, on average, a Android client does 30 sessions per day with a total duration of 13 hours. –The peak may exceed this, but the system may temporarily get behind. –We will NOT support 200K enabled, such that 100K are posting. Maximum of 25 QlikView users. –Any more than this then we are no longer single QVW server & SMB licencing, but into multiple servers and Enterprise licencing costs. This has not been allowed for in Elisa pricing. –Performance, and what those users are doing, may well introduce a lower usability limit.

3. Caveats There is no intention to remove any existing functionality or measurements –with the exception of fine-grained detail from LARs. But there is no intention to provide additional functionality or measurements either … –No significant changes to data model, no new correlations, … –… except enriched measurements from the clients will be tagged with geo-location to avoid costly correlation with Location Observer table. –Service Measurements for Elisa are not included. –We must avoid entangling “data feeds” with the 100K. Some functionality / measurements may be provided in a different way. –E.g. source of Max Throughput from periodic Connection Observations instead from LARs.

4. 100K System We aim to achieve 100K enabled clients by software improvements only. However a front-end proxy may be appropriate to provide added security and take the Loss Metric Processor CPU load. Database sharding will be a contingency if the single CIP server cannot handle the load. This will require the CIP server plus a minimum of 2 database shard servers. We will not know the performance for certain until the system is built and performance tested using PSL’s simulator.

5. Phased plan Phase 0: 15,000 Clients for IDAEnd April –Smart Phone Client functionality as now. –1.8 Database schema, but with DC Observer tables in RAM –No Session Insight GUI –Clean install of datacarddb; retain Reporting database for QlikView –New Export interface Phase 1: > 20,000 Clients for ElisaMid June –New system install within Elisa IT –New 100K ready Database Schema –Session Insight GUI update to support new database. –Retain Reporting database for QlikView Phase 2: 100,000 ClientsEnd August –New Smart Phone clients doing enrichment. –Server support for enrichment on the client. –QlikView scaling address as much as possible

6. Phase 0: 15,000 Enabled Clients IDA Upgrade Refresh of existing IDA Android and iOS clients (non-enriching) –Appsee integration Database – existing 1.8 schema, except … –Put selected DC Observer tables into RAM and delete data after enrichment. Reporting Database retained … –Loading of the Reporting Database via stored procedures –Retain validation in Reporting Database. –No change to QVW load via the Reporting Database. New Export Interface.

7. Phase 1: > 20,000 Enabled Clients First phase for Elisa … Android Oma Elisa –No change to client functionality. Database – full100K database schema –Must avoid another database schema upgrade later. –Use Tokudb engine for performance and reduced table size. –Limited database tuning. Change to GUI to access ENR tables Fix Loss Metric Processor (if required). New Export Interface. Reporting Database retained … –Loading of the Reporting Database via stored procedures –Retain validation in Reporting Database. –No change to QVW load via the Reporting Database.

8. Phase 1: > 20,000 Enabled Clients QlikView changes to optimise current product … –May need incremental load on long-load docs only –Avoid incremental loading development for all docs in Phase 1 –Implement the most cost-effective data model fixes –Implement the most cost-effective chart optimisation routes –Produce more accurate, evidence-based server sizing estimates (System Monitoring improvements).

9. Phase 2: 100,000 clients Enrichment on the Android and iOS clients turned on –Addition of location to all ENR tables (to avoid Location correlation). –Enriched Connection Updates (with location). –Server acquisition changes for receiving enriched records from clients –Directly load into the ENR tables in the database. –Existing server enrichment retained for legacy clients.. No update to Windows or OSX clients planned. –Since only a few thousand of them, they have little impact on overall performance. Removal of LARS (except legacy Windows and OSX clients). –Use Enriched Connection Update records instead. Remove reporting databases. –Load QlikView direct from the replicated ENR tables. Move validation currently done on the Reporting database. –Not quite sure where yet …

10. Phase 2: Ready for 100,000 clients QlikView – all apps optimised to support 50K+ clients –(Dependent on the revised sizing estimates from Phase 1) –Implement new UDA (Universal Data Architecture) –Base QVD Loads as standard (replacement of E & T loaders) –All data model improvements implemented –All application design improvements implemented –Define data model requirements –Feasibility of 100k support to be evidenced through even more accurate estimates and possibly a load simulation –Acknowledge that 100k support of the current system breadth and depth may not be possible on one Small Business Server –Accurate evidence-based server sizing will be crucial if we are to justify 100k on one server or on more than one server – “guestimates” are not suitable at this scale given the cost implications of any such decision

11. Phase 2a If performance test on Phase 2 shows we can’t get to 100K enabled clients then we will have to shard the database. We should not need more than 2 or 3 shards – which means an additional two or three servers in addition to the current CIP server. One replication server should cope – it’s not doing much.

12. Elisa In-house System Servers Database Server Replication Server QlikView Server Enablement / Speed Test Server Session Insight GUI QlikViewExport Interface Customer devices Feed Interface to 3 rd party system (outside current project scope) Shard 1 Server Shard 2 Server Traffic Manager (Load Balancer) CIP Server