Digital Enterprise Unit. White Paper. Leveraging Best Practices and Recommendations for Optimal Performance Tuning of IBM Campaign

Transcription

1 Digital Eterprise Uit White Paper Leveragig Best Practices ad Recommedatios for Optimal Performace Tuig of IBM Campaig

2 About the Author Harshal Tejale Harshal Tejale is a Assistat Cosultat at Tata Cosultacy Services' (TCS') Digital Eterprise Software ad Services (DESS) group, with over 10 years of experiece i the IT idustry. He worked with Uica Corporatio (later acquired by IBM) for 5 years. His role i TCS is that of a Domai Cosultat resposible for providig solutios to EMM customers. His expertise lies i istallatio, cofiguratio, troubleshootig & support, upgrade/migratio of Uica tools. I his previous experiece, where he worked with a EMM customer, he performed the role of a Tech Lead for CMS itegratio with various commuicatio chaels ad was also resposible for Requiremets Gatherig & Aalysis, Impact Aalysis, SIT & UAT, leadig BIF ad Deploymet. He has also played a lead role i performig cross platform versio upgrade of Uica products for a leadig Telecom compay i the US. He has completed his Masters i Computer Sciece from Uiversity of Pue, Idia.

3 IBM Campaig, formerly kow as Uica campaig, is a popular cross-chael campaig maagemet software for outboud marketig. It helps marketers pla, desig, execute, ad evaluate highly persoalized marketig campaigs. This customer focused tool raks high o viability ad lifecycle maagemet fuctioalities. However, there are a few support issues that impede its effective implemetatio. The tool eeds to support o-time ad withibudget project completio ad itegratio more effectively. It is therefore imperative to moitor ad ehace performace, ad improve processes i IBM Campaig. A typical istallatio of IBM Campaig comes with default values for most of its cofiguratio parameters. The parameters that require fie tuig reside: Withi the IBM Campaig applicatio At the web applicatio server level At the database level This paper addresses the challeges of performace tuig of IBM Campaig. We recommed assessig applicatio performace, idetifyig the root cause of bottleecks, ad recofigurig applicatio software ad hardware parameters to achieve maximum performace. The paper aims to serve as a comprehesive guide for Uica admiistrators, ad the support team, while some iformatio might be useful for campaig desigers as well. The poiters provided i this documet ca be implemeted well before the IBM Campaig solutio is implemeted, durig upgrade, or eve whe the solutio is already i place.

4 Cotets 1. Itroductio: Uderstadig IBM Campaig 5 2. Fie Tuig Performace Parameters 6 3. Leveragig Best Practices to Optimize Performace Coclusio 16

5 Itroductio: Uderstadig IBM Campaig IBM Campaig is a eterprise marketig campaig maagemet solutio comprisig a web applicatio ad a aalytical server. The tool is supported o multiple operatig systems, web applicatio servers, ad databases. While it performs better whe deployed o distributed servers, its performace might be affected whe istalled o a stad-aloe server. I a large busiess to cosumer (B2C) eterprise settig, IBM Campaig typically delivers good performace i o-productio eviromets, where data volumes ad users do ot mimic productio scales ad trasactioal cocurrecy. However, i a typical productio eviromet, performace is impacted by the larger volumes of data ad cocurrecy. The challege is to make cotiuous ad icremetal efforts to determie the optimum settigs for esurig the best performace. Addressig Challeges that Affect Performace Campaig executio ca have a strog impact o strategic decisio makig, ad ieffective campaig executio ca delay plaig ad forecastig. It ca also hamper marketig efforts icludig plaig, budgetig, ad resource allocatio. For example, if a seasoal 'Christmas campaig' is ot executed well before Christmas, ad the offers reach people post-festivities, the the etire campaig becomes meaigless. Delayed campaigs lead to a waste of time, effort, ad moey. Critical aspects of a ed to ed campaig lifecycle, which ca be improved to boost performace iclude: a) Comprehedig campaig requiremets b) Desigig a effective flowchart to geerate target lists as per the busiess logic c) Trasferrig the target lists to the right commuicatio or fulfillmet chaels d) Broadcastig the offer message across chaels e) Trackig resposes from customers post campaig executio Sice, steps 'a' ad 'd' caot be addressed by IBM Campaig, the scope of this paper is limited to discussig oly the rest of the steps. I may istaces, ed users face certai critical issues durig a campaig such as slow executio of campaig flowcharts, ad slow respose from the campaig web applicatio. A typical stad-aloe istallatio of IBM Campaig with default settigs for its cofiguratio parameters ca serve for a small size customer base - approximately a little less tha half a millio. However, a icrease i the volume of data ad cocurret users ca overwhelm the system. This leads to slow respose due to which users are uable to complete campaigs assiged to them. 5

6 I order to mitigate the risk of such issues, it is imperative to better maage factors that affect the performace of IBM Campaig. The key factors to be cosidered iclude: Database Hardware Software ad it's parameters icludig applicatio server, ad IBM Campaig Data volume Network cofiguratio Customizatio Fie Tuig Performace Parameters To ehace IBM Campaig performace, it is essetial to resolve the challeges ad issues ecoutered for each of the parameters that ifluece performace. Oe of the best solutios is to chage the values of these parameters. Here is how you ca achieve this: Cofigure Databases Effectively IBM Campaig's performace largely depeds o both, system as well as user databases. It is therefore importat to appropriately cofigure these databases, so that they facilitate optimum performace. For istace, DB2 ca be cofigured effectively by leveragig the AUTOCONFIGURE commad. AUTOCONFIGURE shows iitial values for buffer pool size, database cofiguratio, ad database maager cofiguratio parameters. It also suggests the optimal database settigs based o available resources ad iteral statistics. Campaig performace ca also be improved by splittig table spaces across multiple data files, before the system or user database is created. The data i ay database is stored physically i data files, which correspod to tablespaces. A sigle tablespace ca comprise oe or more data files, which may reside i the same or distributed disks i the same eviromet. Splittig the table spaces across multiple data files reduces iput /output (I/O) processig ad improves overall performace. 6

7 Two Tablespaces Database System Tablespace USERS Tablespace DATA1.ORA DATA2.ORA DATA3.ORA CREATE TABLESPACE users DATAFILE DATA3.ORA Figure 1. Splittig the table spaces, which store data, helps ehace performace Ehace Hardware Capabilities Typically, performace is sigificatly ehaced if the hardware i the eviromet (applicatio server ad database servers) are high ed servers with high cofiguratios for example, RAM, core. A particular server cofiguratio might result i good performace iitially. However, over a period of time, whe there is a marked icrease i the umber of users, campaigs to be targeted, cocurret campaigs, ad overall customer base, the likelihood of performace bottleecks icreases. Regular capacity upgrades, every four or five years, esures that the system ca sustai the aticipated load. Network ad systems maagemet tools such as a HP OpeView (HPOV) ca be used every 8-10 moths to moitor the overall health of the servers, prior to a capacity upgrade. This helps to accurately assess the performace of memory, processors, ad disks at the curret load levels, ad extrapolate the coclusios to future eeds. A look at a few operatioal poiters that ca ehace hardware capabilities: i. Icrease the memory of a give server to reduce page fault, as iformatio from iteral memory ca be retrieved faster tha from the disk. ii. Determie the best data storage (iteral or SAN), such as RAID 1, RAID 5, or RAID 10 that suit the orgaizatio's eeds. The decisio must be based o a holistic assessmet of the cost, redudacy, ad performace of these storage solutios. Hardware parameters ca be better uderstood with a illustrative case that depicts the resource utilizatio tred for applicatio server ad database server. 7

8 Resource utilizatio of applicatio server % utilized /1/2013 1/2/2013 1/3/2013 1/4/2013 1/5/2013 1/6/2013 1/7/2013 1/8/2013 1/9/2013 1/10/2013 1/11/2013 1/12/2013 Date CPU Memory Figure 2. Resource Utilizatio Tred of Applicatio Server Resource utilizatio of database server % utilized /1/2013 1/2/2013 1/3/2013 1/4/2013 1/5/2013 1/6/2013 1/7/2013 1/8/2013 1/9/2013 1/10/2013 1/11/2013 1/12/2013 Date CPU Memory Figure 3. Resource Utilizatio Tred of Database Server 8

9 Figure 2 shows that the percetage of CPU ad memory utilizatio o the applicatio server is slightly high the average beig 56 percet ad 62 percet respectively. Figure 3 idicates that the utilizatio percetages o the database server are margially less tha the applicatio server the average beig 32 percet ad 16 percet respectively. I this sceario, additioal storage will be required to ru larger campaigs. For istace, a customer might wat to sustai a additioal load for the ext three to four years, as per the followig volumes: Ru 450 campaigs per moth as opposed to the curret 250 Ru 18 to 20 campaigs cocurretly as opposed to the curret 10 to 12 Cater to a additioal customer-base of over four millio To meet these demads, the customer will eed a ideal hardware sizig metrics as estimated i Table 1. Applicatio Server Database Server Reportig Server Cores/CPU Need 12 core i additio to the curret 16 core - 4 CPU Need 2 core i additio to the curret 4 core - 1 CPU 4 core 1 CPU Memory Need 16 GB i additio to the curret 16 GB Need 8 GB i additio to the curret 16 GB 4 GB Iteral Storage 150 GB 150 GB 150 GB SAN Storage Need 500 GB i additio to the curret 1 TB added 500 GB Need 750 GB i additio to the curret 1.25 TB NA Table 1. Additioal storage is essetial to meet the demads of larger campaigs Improve Software ad Its Key Parameters Due to cocers of uforesee issues with ew versios, may admiistrators avoid upgrades or patches if they do ot observe issues with the curret versio. Such a risk materializes i very few cases. Hece, it is recommeded that the applicatio ad its supportig software such as operatig systems, web applicatio server, ad Cogos are ru o the latest supported versio with ecessary patches ad hot-fixes. The latest versios result i better performaces as may patches ad hot-fixes help address performace bottleecks. Though they might ot be directly visible to the ed user, they add value to the overall software quality. Aother key aspect is the applicatio architecture. Typically, 64-bit applicatios are faster tha their 32-bit equivalets. Therefore, a 64-bit IBM Campaig istallatio o a 64-bit operatig system that iteracts with a 64-bit database is ideal. IBM Campaig v8.6 or higher already support oly 64-bit applicatios. But eve with a 32-bit applicatio of earlier Campaig versios such as 7.5.1, it is possible to upgrade to v8.5. This is doe by ruig the 64-bit istallers of v8.5, ad implemetig a i-place upgrade. Relevat guides ca help i uderstadig ad mitigatig compatibility issues. Campaig performace ca also be boosted by esurig optimum values of the differet software parameters, which iclude: 9

10 Applicatio server: For WebLogic, the INITIALCAPACITY parameter of JDBCCONNECTIONPOOL allows the user to set the umber of physical database coectios to be created. The default value for this is 1 but it is recommeded that it is set to its MAXCAPACITY parameter. This esures that all database coectios are well established durig server startup. To improve performace of the Java compoet of the applicatio, the optimum HEAPSIZE value is crucial. Heap size depeds o the size of the available mai memory, ad directly iflueces the garbage collector. Higher the heap size, lower are the chaces of triggerig the garbage collector. However, heap size is restricted by a threshold value. For istace, i theory, a 32-bit Java Virtual Machie (JVM) ca expad up to 4 GB, but oly 1.4 to 1.6 GB gets allocated effectively. May customers are satisfied with the applicatio s performace usig the default heap size rage of, miimum 512 MB to maximum 1024 MB. IBM Campaig: Improvig the performace of IBM Campaig through tuig cofiguratio parameters ivolves: Leveragig database loaders: Database loaders improve performace sigificatly. Without loaders, the isertio of a large umber of records icreases CPU utilizatio ad disk I/O. Cofigurig loaders o system data source esures faster isertio of millios of records ito history tables (through MailList, CallList, or Respose process boxes). Similarly, the user data source records are pushed ito the temporary (temp) tables, ad exported ito tables via Sapshot much faster. Creatig Temp tables ad usig I-DB optimizatio: Creatig temp tables for each data source helps sigificatly improve performace of flowchart executio as they store itermediate results. For further processig, the server retrieves rows directly from these temp tables. Further, temp tables reside i the user database, ad are ot dropped automatically after beig used. It is also helpful to draw upo the beefits of I-DB optimizatio, which relies o the creatio of temp tables. Whe dealig with large volumes of data, the burde of movig data back ad forth betwee the campaig ad database servers causes substatial bottleecks. Whe I-DB is tured o, a major share of processig is pushed to the database server as opposed to the campaig server processig it. This takes the burde off the campaig server, ad results i lower CPU cosumptio. However, eve if I-DB is tured o, it is ot always guarateed to take effect as it is decided iterally ad o-the-fly by the Campaig server. For istace, I-DB will ot be i effect if you have set limitatios o the Output Cell Size. Esurig storage of strategic segmets data i database: While usig strategic segmets ad refreshig them frequetly, the value of the donotcreateserverbifile parameter must be true for better performace. The data related to strategic segmets is stored i the database ad ot o the campaig server. Whe this property is set to false, the.bi file takes a loger time to complete ruig o the server, as it requires additioal processig. Reusig temp tables: TempTablePool eables the system to reuse the temporary tables geerated durig a flowchart ru, ad reduces the umber of temporary tables created i the database. Although this was specifically desiged for Teradata ad later DB2, it is also applicable for SQL Server ad Oracle. With Teradata, the create ad drop statemets for creatig ad droppig temporary tables ca be expesive, as it locks the system catalog every time such statemets are issued. System efficiecy ca be improved by reducig this lockig. However, this feature is ivalid if I-DB optimizatio is tured o, as the temp tables are ever released for other flowcharts to use. So, depedig o the requiremet a 10

11 choice eeds to be made betwee I-DB ad temp table pool. TempTablePool ca be eabled o versio of the 7.x lie, or o 8.2+ versio of the 8.x lie. Applyig global suppressio: Global suppressio ivolves associatio of a strategic segmet with a audiece level. A list of uique IDs (opt-outs) is automatically excluded from the cells i a flowchart. If global suppressio is applied o a particular level of audiece, all top level process boxes of a flowchart will automatically exclude the IDs i the suppressio segmet. By doig so, the extra task of selectig opt-out IDs (i [Select]) ad later excludig them (usig [Merge]) ca be skipped. Global suppressio ca be overridde for a particular flowchart. Determiig Optimum Virtual Memory: MaxVirtualMemory parameter specifies the maximum megabytes of a system s virtual memory eeded for executig a flowchart. Depedig o the server s capability, a optimum value ca be set so that flowchart rus efficietly. At times, it could take a while before a optimum value is derived depedig o the desired flowchart efficiecy. But the ideal recommeded value ca be calculated as: Recommeded value = {80% of available memory} / {Number of expected cocurret Campaig flowcharts} This ca be set globally for all flowcharts, or overridde for idividual flowcharts. The default value is 128 MB. Settig keepflowchartlogope value to True : The specific value that is set True or False, determies whether the campaig opes ad closes the flowchart log file each time a lie is writte to the log file. Performace of the flowchart executio is slightly improved whe set to True, as campaig opes the flowchart log file oly oce, ad closes oly whe the uderlyig uica_acsvr process has exited. However, i this sceario, the most recetly logged log lies will ot be immediately visible. If the log lies are of lesser sigificace, it eeds to be set to True. The default is False. Executig greater umber of simultaeous queries: The MaxQueryThreads property helps specify the maximum umber of simultaeous queries to be allowed to ru for a flowchart. I IBM Campaig, it is commo to ru multiple queries simultaeously. Oce the umber of simultaeous queries reaches the specified value, the campaig server does ot allow ay further query executio. Therefore, settig a higher value supports icreased performace, as a higher umber of simultaeous queries ca be executed. Esurig de-dupig of IDs by database: The values i the EableSelect Distict property ca be set to True or False. This allows the system to kow whether the IDs geerated usig iput processes are to be de-duped by the campaig server or the database. It is best to let the database do the de-dupig ad retur uique IDs. If the default value is True, the database performs de-dupig. The value ca be captured by viewig the SQL geerated i the log file, which will have the Distict keyword. Whe the value is set to False, the campaig server hadles the de-dupig effort, ad this impacts performace. Eablig maximum data block size: The size of the data block idicates the umber of records that the campaig server will pass to the database at a time for further processig. While the default value is 100, settig the BulkIsertBlockSize to a relatively high value ca help improve performace. Likewise, the BulkReaderBlockSize property sets the maximum size of data block i terms of the umber of records that the campaig server reads from the database at a time. The default value is 2500 ad settig this to a relatively high value ca improve performace. Settig QueryThreadSleep value to True: This property directly affects the CPU utilizatio of the uica_acsvr process. With default value set to True, the thread that the server process uses to check for query completio sleeps 11

12 betwee checks. Whe set to False, the thread does ot sleep ad cotiuously checks for completio. Sice this results i high CPU utilizatio, it is ot recommeded. Allowig database to sort IDs: The EableSelectOrderBy property lets the system kow whether the list of IDs geerated is to be sorted by the campaig or database server. With the default value of True, the database performs the sortig. The relevat log lie will have order by i the log file. The best practice is to stick to the default value, which esures that the operatio is performed by the database ad ot the campaig server. For text audiece levels, set it to False. Cosolidatig queries: If a segmet process box creates may segmets, separate queries will be set to the database for executio. Istead of separate queries, it is ideal to cosolidate them ito a sigle SQL CASE statemet. This ca be realized by settig the AllowSegmetUsigSQLCase property to True. However, for this, the segmets must be mutually exclusive, come from a sigle table, ad Uica macro laguage has to be used to set the criteria of each segmet. Leveragig TempTablePostExecutioSQL: Ay valid SQL that eeds to be executed by IBM Campaig immediately after the temp table has bee created ca be specified usig this property. The best optio is to idex a ewly created temporary table. Through the executio of the flowchart, the system creates temporary tables that store itermediate results, ad these are accessed by dowstream process boxes for further processig. By idexig the temp tables, the dowstream process boxes ca access relevat records faster. The SQL query CREATE INDEX IND_<TABLENAME> ON <TABLENAME> (<KEYCOLUMNS>) ca be used to do this. Other supported tokes ca also be used. Sedig bulk queries to database: Sedig bulk queries to the database i oe go is better tha sedig them oe by oe. At ay poit durig the flowchart executio, if the umber of IDs is less tha the value i the MaxRowFetchRecords parameter, the campaig passes the IDs to the database oe at a time, i separate SQL queries. This ca be very time cosumig ad iefficiet. If the umber of selected IDs is greater, the campaig uses temporary tables, or pulls out all the ecessary values from the table. It is therefore ideal to keep this value low. Maage Data Volumes The executio of campaig flowchart is directly depedet o the amout of data. The higher the volume of data, the slower the executio rate. High data volume could be due to poor maiteace or ieffective desig. With too much or too little database ormalizatio, fidig the ecessary data for queries ivolves additioal processig, which reduces the speed of executio. Based o the busiess logic applied i the flowchart, relevat queries are fired o the user database for the selectio of targeted IDs. These queries take a loger time to retrieve the IDs if the volume of the data scaed is very high. I such cases, cosider creatig views that will ot oly have the subsets but also the required data for the targeted query. The flowchart will the take iput from these views istead of the huge tables. Aother useful compoet is a weekly or mothly report that ca be accessed ad aalyzed by workig closely with the Database Admiistrator (DBA). Workig with the DBA facilitates the followig: 12

13 Idetifyig queries that take a loger time to execute, ad determiig ways to optimize a query through customizatio Shiftig work load to that time of a day or week whe the database is idle, ad archivig old ad uwated data Optimize Network Cofiguratio The ature of the etwork largely affects performace. Most customers do ot istall the IBM Campaig, database ad reportig tool o the same server. Eve if that is the case, there are other executio ad fulfillmet chaels that campaig maagemet itegrates with to complete the cycle. The primary cocer with etwork specificatio is its supported badwidth. The key to overcomig etwork performace issues is - do't sped too much o performace you do't eed but do t sped so little that you create a etwork that ca't meet your requiremets. Aother positive step is to work with the SA team to access regular etwork reports. They ca also esure proper authorizatio o all the server paths, so that other applicatios do ot sed uwated or large files to your applicatio, which wastes badwidth. It is importat that oly the selected ad right target lists are trasferred at the right time. If target lists are created well before the broadcastig date, the ame of the target list file ca have the broadcastig date i it. This would istruct the FTP script to trasfer the specific file oly a day before the broadcast date. Furthermore, large target list files ca be split ito multiple files before trasferrig them through commuicatio chaels such as SMS. For istace, before trasferrig, the FTP script will split the huge file ito multiple files with 50,000 records i a file. So, C00001_Flowchart1_SMS_ txt with 100,000 records ca be split i two files as C00001_Flowchart1_SMS_ _0000.txt ad C00001_Flowchart1_SMS_ _0001.txt of 50,000 records each. Aother effective way is to push other etwork related huge tasks to weekeds or after workig hours. This helps reduce etwork traffic, ad esure uiterrupted busiess durig the week. Avoid Over Customizatio Customizatio is ievitable, but it is ecessary to esure fairly simple graularity to avoid chokig the system. The overhead cost of customizatio is high ot oly durig developmet but also while scalig up. With heavy customizatios, the upgrade of baselie software ca get complicated, as these customizatios eed to be tested thoroughly. There is also the risk of overlookig the chages implemeted by the baselie software vedor. For istace, customizatio ca be doe to validate every field while creatig a object. It ca also help validate the ame of the target list, or check that oe of the fields i a target list has ay special characters. However, i these cases, istead of customizatio, regular peer reviews before the fial rollout of target lists, ad comprehesive checklists ca help idetify issues satisfactorily. Customizatio must be adopted oly whe the eed caot be addressed by peer review or use of checklists. I case of customizatio by a third party, there is a risk that vedors who customize the system might geerate less optimized code. It is therefore ecessary to test the customized code with ear real time data to idetify ad fix defects early i the cycle. 13

14 Leveragig Best Practices to Optimize Performace A few best practices that help esure the optimized performace ad effectiveess of IBM Campaig iclude: Esure busiess users use the LAN cable Ofte, ed busiess users who log i to IBM Campaig to create offers, campaigs, ad flowcharts use wireless coectivity to log o to the applicatio. Esurig that they use the LAN cable elimiates ay possibility of ruig ito performace issues due to poor wireless coectivity. Suppress IDs early I a flowchart, it is importat to start with the broadest possible ad most limitig criteria i the top level SELECT queries. It is also recommeded to use raw SQL istead of usig derived fields i flowcharts. This process helps select fewer IDs early o, reduces the umber of IDs to be retured to the applicatio server, ad results i faster rus. Ed users lack of kowledge or are reluctace to chage Campaig desigers might be traied ad coditioed to use the tool i a certai way. However, they eed to explore, brai storm ad review the tool i the Developmet eviromet o a periodic basis, to uderstad the grey areas or ew features ad ehacemets. This improves the desigers overall kowledge about the tool, ad drives them to desig better ad more optimized flowcharts. Avoid checkig mutually exclusive segmets I a [Segmet], do ot check the mutually exclusive box uless absolutely ecessary. This adds additioal processig overhead to the segmet at the time of its creatio. Additioal processig overhead ca thus be cotrolled. Use uica_acsvradm tool for moitorig I rare cases, whe a flowchart beig desiged i the edit mode is viewed i the view mode or is ruig, some uderlyig uica_acsvr processes go orpha, for reasos ukow. Uica Admiistrators ca use the uica_acsvradm tool to termiate such uica_acsvr processes that cosume memory. This ca also be used to pause or susped a low priority flowchart for a higher priority oes to take precedece. If uwated uica_acsvr processes are killed, a lot of memory ca be released that ca be utilized by other processes. Prioritize flowchart rus Whe several flowcharts ru cocurretly, it ofte leads to delay i the ru completio. A priority list helps i allowig oly top priority flowcharts to ru, ad holdig back the rest, which ca be ru o weekeds or durig o-busiess hours. 14

15 Less umber of cocurret flowcharts evetually leads to better executio of flowchart ru. Logout from the applicatio May users directly close the browser after savig chages from the flowchart edit mode. However, the uderlyig uica_acsvr process cotiues to lurk i the backgroud. Whe i the edit mode of the flowchart, users eed to save chages, ad logout from the IBM Campaig applicatio. The uderlyig uica_acsvr process is thus killed withi secods. This reduces the risk of orpha or uwated uica_acsvr processes ruig i the backgroud. Implemet housekeepig I mid to large idustries, the umber of targeted customers is so high that with each flowchart ru, there are a large umber of records that are writte ito the history tables. Over a period of time, the volume of data i the system database goes from high to tremedously high, which affects performace. The database eeds to be cleaed through housekeepig of databases ad file systems usig relevat techiques. Oe way is to have history tables o a separate database partitio to retai the required data ad drop the remaiig partitios. For example, keepig 6+1 moths data while archivig the rest. Over a period of time, may orpha temporary tables ad files start to reside i the database ad file system respectively. These should be deleted at regular itervals, by ruig the uica_accleaup utility. The umber of web applicatio log files that are geerated due to settigs i the log4j.properties file (platform.log ad/or campaigweb.log) also eed to be moitored closely. Depedig o the settig, there may be several such log files. The old logs ca be deleted with automated scripts. This might ot directly improve performace but will save disk space. Maageable sizes of data i the database ad file system result i faster retrieval of data. Set low log levels If the eviromet is stable with lesser issues, set the log levels to miimal (INFO), as oly miimal iformatio would be writte ito the log file. With log level set high (DEBUG or TRACE), the umber of I/O operatios o the disk ca be expesive, ad lead to lower performace. If you ru ito ay issues that require goig through the logs, tur up the loggig level, ad reproduce the steps that caused the issue. With INFO, the umber of I/O operatios o the disk ca be reduced to icrease performace. It also helps i utilizig disk space wisely. Specify cell size limit for test rus Settig the cell size limit for test rus provides a list of subsets of expected IDs that ca be verified to esure they meet expected result. It also esures that the records are ot writte ito the history tables durig test rus. Flowcharts will be ru oly agaist subsets of data, which leads to faster executio tha the productio ru. Reboot the servers Rebootig the servers o weekeds, oce i three or six moths, or accordig to the coveiece of the busiess results i several beefits. 15

16 With a quick reboot, zombie or defuct processes that eat ito the memory are killed. This makes way for additioal memory, ad better performace. Leverage suite-wide scheduler Schedule flowcharts usig the suite-wide scheduler. Whe scheduled usig [Schedule] process box, the flowchart is i ruig state eve whe it is ot actually ruig. This meas, the uderlyig uica_acsvr process is also ruig ad cosumig some memory. Multiple such flowcharts eat up a lot of memory uecessarily. Whe usig the suite-wide scheduler, o memory is allocated util the start of flowchart scheduled time, i.e. whe it actually starts to ru. Suite-wide scheduler helps i elimiatig the possibility of flowcharts cosumig ay memory i advace. Compute values for IBM Campaig Avoid usig derived fields for lettig the Campaig server compute values o the fly. Always have such values computed so that the campaig server ca directly take iput from them. For istace, a telecommuicatios compay might wat to select prepaid customers who, i the last six moths have had a average top-up of more tha $300. This ivolves gatherig iformatio from multiple tables to get the desired set of IDs. Istead of IBM Campaig doig this at rutime for all customers, stored procedures ca be leveraged to compute this for Campaig. Evetually, a database view may be set up that will cotai CustomerID, Name, PhoeNumber, , ad LastSixMothAverageTopUp as colums. Your flowchart will the oly select customers where LastSixMothAverageTopUp > 300 The flowchart performs well i this case as it has very little overhead. Coclusio Performace improvemet is a ogoig process, which does ot always lead to istat results. Sigificat time ad effort is required before ay tagible beefits are geerated. We do recommed that before implemetig these ideas ad recommedatios i the actual productio eviromet, they are tried i a quality assurace (QA) eviromet that closely matches the productio eviromet. Through cotiuous exploratio, it is possible to fie tue performace levels ad achieve the desired results. IBM Campaig users also eed to documet the results of chages, ad geerate accurate ad holistic reports to evaluate their efforts at each stage, ad improve their decisio makig. 16

17 About TCS' Digital Eterprise Uit TCS adapts the capabilities of the digital five forces Mobility ad Pervasive Computig, Big Data ad Aalytics, Social Media, Cloud, ad Artificial Itelligece & Robotics to the uique eeds ad opportuities of each idustry. We leverage a combiatio of these techologies to help cliets digitally reimagie their busiess models, products ad services, customer segmets, chaels, busiess processes, ad workplaces to gai sustaied competitive advatage. Our experieced global team icludes strategy experts, busiess aalysts, digital marketers, user experiece desigers, data scietists, ad egieers traied ad certified i the latest techologies. By combiig our techology vedor parterships, our pre-built customizable products ad reusable assets, ad our deep idustry expertise, we offer eterprises everythig they eed for a complete digital trasformatio from strategy ad use cases, to system implemetatio ad maiteace ad everythig i betwee. Cotact For more iformatio about TCS Digital Eterprise Uit, cotact digital.eterprise@tcs.com Digital Reimagiatio is leveragig a combiatio of the Digital Five Forces - Mobility & Pervasive Computig, Big Data & Aalytics, Social Media, Cloud Computig, Artificial Itelligece & Robotics to reimagie six areas of a eterprise: Busiess Models, Products ad Services, Customer Segmets, Chaels, Busiess Processes, ad Workplaces. Subscribe to TCS White Papers TCS.com RSS: Feedburer: About Tata Cosultacy Services (TCS) Tata Cosultacy Services is a IT services, cosultig ad busiess solutios orgaizatio that delivers real results to global busiess, esurig a level of certaity o other firm ca match. TCS offers a cosultig-led, itegrated portfolio of IT ad IT-eabled ifrastructure, egieerig ad TM assurace services. This is delivered through its uique Global Network Delivery Model, recogized as the bechmark of excellece i software developmet. A part of the Tata Group, Idia s largest idustrial coglomerate, TCS has a global footprit ad is listed o the Natioal Stock Exchage ad Bombay Stock Exchage i Idia. For more iformatio, visit us at IT Services Busiess Solutios Cosultig All cotet / iformatio preset here is the exclusive property of Tata Cosultacy Services Limited (TCS). The cotet / iformatio cotaied here is correct at the time of publishig. No material from here may be copied, modified, reproduced, republished, uploaded, trasmitted, posted or distributed i ay form without prior writte permissio from TCS. Uauthorized use of the cotet / iformatio appearig here may violate copyright, trademark ad other applicable laws, ad could result i crimial or civil pealties. Copyright 2014 Tata Cosultacy Services Limited TCS Desig Services I M I 09 I 14