cancel
Showing results for 
Search instead for 
Did you mean: 

Performance Issue when using Allocation

Former Member
0 Kudos
83

Hi Everybody,

I have a performance problem I wrote an allocation function and when I try to run this function it almost take days to work.

Have you any idea about performance issue my only performance problem is not only allocation also during run other scripts I get same problem.

Thanks for your answers.

Kasim SENGUL

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member182709
Contributor
0 Kudos

See this one.

http://scn.sap.com/thread/3232714

Don't  use LOOP. Use BAS(node)

Former Member
0 Kudos

Hi Kasim,

Usually allocations in BPC run pretty efficiently. But a usual performance depends on the size of the Application, Dimensions used in allocations and hardware. Could you please share approximate parameters of your Application and Dimensions?

You can also take a look at my blog[ Improve performance of your BPC scripts|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/21214] [original link is broken] [original link is broken] [original link is broken];.

Regards,

Gersh

Former Member
0 Kudos

Hİ gresh,

I have 9 dimensions and they consist of almost 30.000 master data and run formula for 55000 transaction data here is my formula;

*SELECT(%VAR1_ZMARK%,"[ID]",ZMARK,"[ML]='ZM1'")

//*SELECT(%VAR2_ZMARK%,"[ID]",ZMARK,"[ML]='ZM2'")

//*SELECT(%VAR3_ZMARK%,"[ID]",ZMARK,"[ML]='ZM3'")

//*SELECT(%VAR4_ZMARK%,"[ID]",ZMARK,"[ML]='ZM4'")

*SELECT(%CATEGORY%,"[ID]",VERSIYON,"[CB]='1'")

*SELECT (%TIME_ST%,"[ST_TIME]",VERSIYON,"[CB]='1'")

*SELECT (%TIME_ST_ID%,"[TIMEID]",TIME,"[ID]=%TIME_ST%")

*SELECT (%TIME_FT%,"[F_TIME]",VERSIYON,"[CB]='1'")

*SELECT (%TIME_F_ID%,"[TIMEID]",TIME,"[ID]=%TIME_FT%")

*SELECT(%TIMEID%,"[ID]",TIME,"[TIMEID]>%TIME_ST_ID% AND [TIMEID]<%TIME_F_ID%")

*SELECT(%MSCST_UNT%,"[ID]",MASRAF_CST,"[SEM_POSIT]='N'")

//*SELECT(%POB%,"[ID]",PARA_BIRIMI,"[ID]='%PB%")

*XDIM_MEMBERSET TIME= %TIME_ID%

*XDIM_MEMBERSET VERSIYON=%CATEGORY%

*XDIM_MEMBERSET MASRAF_CST=NA_MC

*XDIM_MEMBERSET MASRAF_YERI=NA_MY,

*XDIM_MEMBERSET SIRKET_KODU=1200

*XDIM_MEMBERSET ZPRODH=NA_ZPRODH

*XDIM_MEMBERSET BOLGE=NA_BOLGE

*XDIM_MEMBERSET ULKE=TR

*XDIM_MEMBERSET PARA_BIRIMI AS %POB%=TRY,EUR,USD

*XDIM_MAXMEMBERS MALZEME=100

//*XDIM_MAXMEMBERS GDR_KALEMI=5

*FOR %ONE_MARK%=%VAR1_ZMARK%

*FOR %PB%=%POB%

*RUNALLOCATION

*FACTOR=USING/TOTAL

*DIM GDR_KALEMI WHAT=G1001; WHERE=<<<; USING=G1019; TOTAL=<<<;

*DIM ZMARK WHAT=%ONE_MARK%; WHERE=<<<; USING=NA_ZMARK; TOTAL=<<<;

*DIM MALZEME WHAT=NS; WHERE=[ZZMARK01]="%ONE_MARK%"; USING=<<<; TOTAL=<<<;

*DIM PARA_BIRIMI WHAT=%PB%; WHERE=<<<; USING=<<<; TOTAL=<<<;

//*NEXT

*ENDALLOCATION

*NEXT

*NEXT

*COMMIT

*FOR %ONE_MARK%=%VAR2_ZMARK%

*FOR %PB%=%POB%

*RUNALLOCATION

*FACTOR=USING/TOTAL

*FOR %PB%=%POB%

*DIM GDR_KALEMI WHAT=G1001; WHERE=<<<; USING=G1019; TOTAL=<<<;

*DIM ZMARK WHAT=%ONE_MARK%; WHERE=<<<; USING=NA_ZMARK; TOTAL=<<<;

*DIM MALZEME WHAT=NS; WHERE=[ZZMARK02]="%ONE_MARK%"; USING=<<<; TOTAL=<<<;

*DIM PARA_BIRIMI WHAT=%PB%; WHERE=<<<; USING=<<<; TOTAL=<<<;

*NEXT

*ENDALLOCATION

*NEXT

*NEXT

*COMMIT

*FOR %ONE_MARK%=%VAR3_ZMARK%

*FOR %PB%=%POB%

*RUNALLOCATION

*FACTOR=USING/TOTAL

*FOR %PB%=%POB%

*DIM GDR_KALEMI WHAT=G1001; WHERE=<<<; USING=G1019; TOTAL=<<<;

*DIM ZMARK WHAT=%ONE_MARK%; WHERE=<<<; USING=NA_ZMARK; TOTAL=<<<;

*DIM MALZEME WHAT=NS; WHERE=[ZZMARK03]="%ONE_MARK%"; USING=<<<; TOTAL=<<<;

*DIM PARA_BIRIMI WHAT=%PB%; WHERE=<<<; USING=<<<; TOTAL=<<<;

*NEXT

*ENDALLOCATION

*NEXT

*NEXT

*COMMIT

*FOR %ONE_MARK%=%VAR4_ZMARK%

*FOR %PB%=%POB%

*RUNALLOCATION

*FACTOR=USING/TOTAL

*FOR %PB%=%POB%

*DIM GDR_KALEMI WHAT=G1001; WHERE=<<<; USING=G1019; TOTAL=<<<;

*DIM ZMARK WHAT=%ONE_MARK%; WHERE=<<<; USING=NA_ZMARK; TOTAL=<<<;

*DIM MALZEME WHAT=NS; WHERE=[ZZMARK04]="%ONE_MARK%"; USING=<<<; TOTAL=<<<;

*DIM PARA_BIRIMI WHAT=%PB%; WHERE=<<<; USING=<<<; TOTAL=<<<;

*NEXT

*ENDALLOCATION

*NEXT

*NEXT

*COMMIT

Former Member
0 Kudos

Hi,

Is it 30,000 records in all 9 Dimensions or in each of them? If its total number, how even are they distributed and what is the biggest one?

It looks like you are generating a lot of allocations depending how many members you have in %VAR1_ZMARK% (%POB% has 3 members). Can you try running just one allocation (for one value of variable members) and check how long does it take in UJKT; it has statistics for each step. Than, based on that info we can decide which way is better to proceed.

I also saw that compressing the cube (Light Optimize) can significantly improve performance of allocations.

Regards,

Gersh

Former Member
0 Kudos

Hi Gersh,

Biggest dimension is malzeme dimension and have 25000 records others doesnt have so much members and as you said when i try for one allocation it doesnt take so much time. Also I think main problem is for statement.

Thanks

Kasim SENGUL

Former Member
0 Kudos

Hi,

The problem is I see is that there are lot of allocations happening because of the for loop. And this is basically reducing the performance.

One more point is that after each commit, you need to define the scope once again using the XDIM statements, otherwise your script will run for all the data in your tables. So, you need to have XDIM statements after each of the commit statements.

Hope this helps.

former_member200327
Active Contributor
0 Kudos

Hi Kasim,

Nilajan is right, COMMIT might affect number of records your ALLOCATION is processing, but because ALLOCATION uses data defined in DIM it will affect only those Dimensions which are not defined in ALLOCATION. Really don't see why you need those COMMITs, so I'd suggest removing them.

Could you please check how long ALLOCATION takes with one FOR/NEXT around it? If this still runs fast, please check nested pair, i.e. one of those 3 you have. Can you tell how many ALLOCATIONs one nested FOR/NEXT generates in your case.

If you are really concerned about performance of that script I suggest you try that RUNLOGIC BADI which will allow running those allocations in parallel. I think you script is a very good candidate for such acceleration.

Regards,

Gersh

former_member200327
Active Contributor
0 Kudos

Hi Kasim,

Nilajan is right, COMMIT might affect number of records your ALLOCATION is processing, but because ALLOCATION uses data defined in DIM it will affect only those Dimensions which are not defined in ALLOCATION. Really don't see why you need those COMMITs, so I'd suggest removing them.

Could you please check how long ALLOCATION takes with one FOR/NEXT around it? If this still runs fast, please check nested pair, i.e. one of those 3 you have. Can you tell how many ALLOCATIONs one nested FOR/NEXT generates in your case.

If you are really concerned about performance of that script I suggest you try that RUNLOGIC BADI which will allow running those allocations in parallel. I think you script is a very good candidate for such acceleration.

Regards,

Gersh