PLSRV_MAPPING_REQUEST taking long time

[Former Member]

Hi experts,

we have some messages on production environment that are executing during the night and which take way too much time to end.

The scenario is http to file, with a mapping including a RFC lookup;we receive about a hundred messages so the volume is not too high and the size of each xml message is about 20Ko so not too large

The issue is the following, the 'mapping' part takes too much time, here is an extract of the trace of one PI message :

 <Trace level="1" type="B" name="PLSRV_MAPPING_REQUEST">
  <Trace level="1" type="Timestamp">2010-05-17T00:16:46Z CET Start of pipeline service processing PLSRVID= PLSRV_MAPPING_REQUEST</Trace> 
</Trace>
  <Trace level="1" type="Timestamp">2010-05-17T05:30:27Z CET End of pipeline service processing PLSRVID= PLSRV_MAPPING_REQUEST</Trace> 
  </Trace>

When I execute mapping test on development environment with the same message, it takes about 15 seconds, whereas it takes much more time on production.

My guess is that there is something really consuming on production environment, but I can't figure out what. I tried checking SM50, but there is nothing abnormal in both environment.

So my question would be, how can I trace in detail what causes the message to take so much time ? How can I identify what is so consuming in term of resources on production environment ?

Any help would be greatly appreciated

Kind regards,

Jamal

[Shabarish_Nair · Accepted solution]

how many RFC lookups happen?

Can you try to club the lookup call into a single call rather than multiple ones?

/people/shabarish.vijayakumar/blog/2010/01/28/graphical-rfc-lookup-and-how-you-can-design-lookups-for-multiple-values-to-be-retrieved-in-a-single-call

[Former Member]

Hi,

actually there are some interessant inputs in 'SAP NetWeaver Process Integration - Performance Check.pdf'

Long processing times for
u201CPLSRV_MAPPING_REQUESTu201D
The mapping request for a message involves more than one runtime. The starting point is the
Integration Engine that will send the request via RFC destination
AI_RUNTIME_JCOSERVER to the gateway. There it will be picked up by a registered server
program. The registered server program belongs to the J2EE Engine. The request will be
forwarded to the J2EE Engine by a JCo call and then be carried out by the JAVA runtime.
When the mapping has been carried out, the result is sent back to the ABAP pipeline via JCo.
Thus, there are several places to check when trying to trace down why the mapping step took
so long.
o Not enough resources (registered server programs) available. That could either be
the case if too many mapping requests are issued at the same time or if the J2EE
Engine is down and did not register any server programs.

Plus we applied note sapnote_0001361495.pdf that resolved the issue on SPI_* job running for a longtime.

Thnaks all for your help

[Former Member]

I do not know if it's related, but i have a job executing which takes suprisingly long

It has a cryptic name and the step is the ABAP program SPI_PS_ASSEMBLE_DSP

It is scheduled every 5 minutes, sometimes lasts 2500 seconds!! and in average 100 seconds.

Do you happen to know what is this for ?

May this be the cause of the issue ?

Thanks a lot again,

Jamal

Edit : I have checked the same job on development environment, it takes only 1 to 15 seconds...

Regards

Edited by: ba_da_boom on May 17, 2010 4:52 PM

[Former Member]

Hi,

we only have one single call RFC that retrieves data in one call which is then dispatched in mapping

Thanks,

Jamal

[Shabarish_Nair]

check how long does the call take.

It might be the problem with the time taken by that call which is delays the mapping execution

[Former Member]

Thanks,

how can I check in detail how long did the call take ?

THanks again,

Jamal

[Shabarish_Nair]

check the adapter logs for the RFC adapter. it will show you the timings

[Former Member]

check the adapter logs for the RFC adapter. it will show you the timings

Sorry to bother you again, where can I find the adapter logs for the RFC adapter ?

Thanks a lot,

Jamal

[Shabarish_Nair]

i meant the communication channel monitoring log of the RFC adapter

RWB -> Component monitoring -> Comm. channel monitoring

[Former Member]

It might also be useful to check for jobs (archiving or database jobs) that are scheduled to run at night...Check TCode SM37....

Regards, Trevor