Atualização1:
Adicionado teste de desempenho na integração em nuvem para medir apenas o desempenho de RFC na seção «Medir o desempenho do adaptador RFC de integração em nuvem após aplicar parâmetros de serialização».
Recentemente, escrevi sobre minhas experiências neste blog na criação de um script personalizado e bacana para chamadas RFC, onde o adaptador RFC padrão não funcionava devido ao conteúdo dos dados conter caracteres não imprimíveis. Ao desenvolver o script, pensei em como melhorar o desempenho das chamadas RFC.
Este blog descreve minha experiência medindo o desempenho com a configuração BTP padrão para destinos RFC, melhorando o desempenho com propriedades de configuração adicionais e, em seguida, executando testes adicionais para ver o efeito de parâmetros com RFCs de tamanhos diferentes em um panorama BTP junto com testes em uma rede local. Estou impressionado com as melhorias de desempenho.
Os testes foram realizados com a paisagem abaixo.
Aplicativo -> Integração SAP Cloud -> SAP Cloud Connector -> SAP S4
A carga útil não possui caracteres especiais e, portanto, usamos o adaptador receptor RFC Cloud Integration padrão.
O tamanho dos dados retornados pode ser controlado através do contador de loop no código ABAP abaixo na RFC.
FUNCTION z_rfc_get_flights.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(IM_INPUT) TYPE CHAR10
*" EXPORTING
*" VALUE(FLIGHTS) TYPE FLIGHTTAB
*"----------------------------------------------------------------------
* 1 time ==> 1.69 MB
* 10 times ==> 16.91 MB
* 100 times ==> 169.1 MB
DATA: lt_flights TYPE flighttab.
SELECT * FROM sflight INTO TABLE lt_flights.
DO 1 TIMES.
APPEND LINES OF lt_flights TO flights.
ENDDO.
ENDFUNCTION.Usei a variante SAP&BC_MONSTER para gerar dados de teste para a tabela SFLIGHT.
O fluxo de integração na nuvem é muito simples com um ouvinte HTTP chamando o backend SAP RFC por meio do conector de nuvem. O teste inicial é realizado com a configuração de destino RFC BTP padrão da documentação.
Com um tamanho de dados de 1,69 MB, a conexão usa a configuração padrão. Tempo médio de resposta = 8518 ms.
SAP JCo 3.1 introduz (nas Notas de Versão 3.1.2) suporte para serialização rápida. Da documentação do JCO:
O tempo de execução JCo RFC agora pode serializar dados do módulo de função no modo de serialização rápida, se o sistema parceiro também suportar esse formato de serialização. Tecnicamente, esta é uma serialização de dados baseada em colunas.
No entanto, verifique seu sistema backend SAP conforme nota 2372888. Se for um sistema anterior a 7.51, pode não suportar serialização rápida.
Configurando o destino BTP para usar serialização baseada em coluna, para usar serialização RFC rápida.
Mais propriedades para adicionar.
jco.client.serialization_format=colunaBaseada
Executei um teste semelhante novamente após atualizar o destino BTP.
Os resultados do teste parecem muito promissores. O tempo médio de resposta melhorou para 5.133 ms. Este tempo de resposta é 60% do tempo de processamento com a configuração padrão. Isto por si só representa uma enorme melhoria nos tempos de resposta.
A documentação SAP também menciona outro parâmetro: jco.client.network. Por padrão é LAN.
Da documentação: os valores válidos são LAN ou WAN (relevante apenas para serialização rápida). Na WAN
Neste caso, um algoritmo de compressão mais lento, mas melhor, é usado e os dados são analisados posteriormente.
opções de compactação. Para a LAN, um algoritmo de compressão muito rápido é usado e apenas a análise dos dados é realizada
em um nível muito básico. Então. a taxa de compressão não é tão boa nesse caso, mas neste caso o
o tempo de transferência não é considerado tão dominante quanto para WAN. Escolha este valor com base na sua rede
qualidade entre JCo e o sistema alvo para otimizar o desempenho. A configuração padrão é LAN.
E se definirmos jco.client.network COMO WAN junto com serialização formatar como baseado em colunas ?
Baseado em colunas com WAN: melhoramos o tempo de resposta para 4.364 ms. O tempo médio de resposta é aproximadamente metade do valor anterior.
Usando esses dois parâmetros reduzimos o tempo de resposta de 8.518 ms => 5.133 ms => 4.364 ms.
Repeti os três testes juntos executando um teste de desempenho, e os resultados são consistentes com aqueles obtidos quando esses testes foram executados separadamente. O tamanho dos dados é 1,69 MB e é retornado pela RFC.
Aumentando o tamanho dos dados para 16,91 MB, vemos um padrão semelhante. O tempo médio de resposta é reduzido por um fator de 3 ao usar columnSerialization com a rede do cliente definida como WAN (23.006 ms em comparação com os 71.225 ms originais).
Portanto, no caso do conector de nuvem, a ordem crescente de latência é:
1) Serialização baseada em coluna com WAN ( jco.client.serialization_format=columnBased, jco.client.network=WAN)
2) Serialização baseada em coluna com LAN ( jco.client.serialization_format=columnBased , jco.client.network=LAN )
3) a configuração RFC padrão ( jco.client.serialization_format=rowBased , jco.client.network=LAN )
A configuração acima mediu o tempo geral de execução do fluxo. Para isolar o impacto das configurações de serialização no adaptador RFC. Adicionei um script antes e depois de chamar a RFC para medir o tempo de execução da RFC em milissegundos.
setStartTime é chamado como parte da primeira chamada do script para obter o tempo antes da chamada RFC.
setExecutionTimeAsBody é chamado após a chamada RFC e o tempo de execução (a diferença entre os dois tempos é definida como o corpo).
import com.sap.gateway.ip.core.customdev.util.Message
Message setStartTime(Message message)
def startTime= System.currentTimeMillis()
message.setProperty("startTime", startTime);
return message
Message setExecutionTimeAsBody(Message message)
def startTime = message.getProperty("startTime") as Long
message.setBody(Long.toString(System.currentTimeMillis()-startTime))
return message
Em seguida, chamo um script de shell para chamar a API 50 vezes para obter os dados em três arquivos diferentes. As credenciais do usuário precisarão ser colocadas entre aspas simples para funcionar.
#!/bin/bash
# Tentar 50 vezes
contador=1
enquanto [ $contador -le 50 ]
faça
echo $contador
echo Chamando WAN COL
echo -n '|' >> WANCOL.txt
curl --user 'sb-xxxxxxxxxxxx-bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb:xxxxxxxxxxxxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=" >> WANCOL.txt
echo Chamando LAN COL
echo -n "|' >> LANCOL.txt
curl --user 'sb-xxxxxxxxxxxx-bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb:xxxxxxxxxxxxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=" >> LANCOL.txt
echo Chamando ROW
echo -n "|' >> ROW.txt
curl --user 'sb-xxxxxxxxxxxx-bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb:xxxxxxxxxxxxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=" >> ROW.txt
((contador++))
feito
echo Tudo prontoObtemos os dados nos três arquivos WANCOL.txt, LANCOL.txt e ROW.txt. Passamos por um programa JavaFx para traçar o gráfico de linhas.
Coluna LAN processamento:|2782|2434|2495|2449|2613|1437|1277|1168|1055|1197|1294|1093|1363|1151|1134|1120|1176|1437|1127|1363|1169|1058|1045|1138|1107|1028|1221|1146|1076|1098|1085|1091|1063|1099|1125|1130|1097|1102|1067|1064|1033|1089|1049|1329|1122|1179|1093|1083|1076|1098
Coluna WAN processamento:|2364|590|574|543|565|574|618|536|565|579|606|591|540|560|528|554|558|568|577|578|577|636|575|569|573|571|578|580|600|578|573|565|594|592|594|575|583|585|587|581|565|568|612|572|596|606|580|580|580|581
Linha processamento:|5794|5318|5361|4468|4376|5700|4128|4792|4788|4912|5771|3915|4320|4677|3872|4420|4512|4972|4043|4373|4441|4107|4336|4300|4612|4505|4447|4128|4897|4430|4153|4119|4714|4449|4838|4063|4479|4652|4924|4533|4907|4744|4511|4160|4142|4352|4291|4463|4420|4201
A diferença entre a serialização WAN de coluna e a serialização normal de linha é quase uma ordem de magnitude.
Testando-o com um tamanho de carga útil de 16,91 MB.
Coluna LAN processamento:|10306|9076|9345|9430|10190|9732|9757|9837|8665|9131|9818|9759|9119|9886|9345|9623|10498|10254|9741|10593|15091|9763|9247|9795|12267|9879|8802|9805|8660|8969|9826|8644|9190|9180|10582|9390|9649|9406|10235|9510|10155|9278|10207|8735|9791|9888|9018|9133|9172|9465
Coluna WAN processamento:|2574|2698|2886|2972|2786|2924|3009|2931|3485|3700|2826|2667|2890|2777|2886|2996|2934|2631|2554|2657|3017|2918|2942|2844|3354|3269|2925|3257|2868|2689|2930|2637|2836|2737|2927|5023|3064|3154|3150|2832|3063|2472|2606|2740|2498|3129|2909|2936|2888|3440
Linha processamento:|48904|42846|40653|42991|43291|46679|45889|45289|45451|43162|44863|43804|44907|45611|45730|47028|46404|46431|43580|46034|45041|45097|45727|44485|44718|45843|45094|44749|45690|45365|50041|43460|43887|44601|45268|44042|45261|45298|47294|56789|46874|46395|47303|46005|46461|50468|47037|45543|46023|47071
Isto também é surpreendente. Para cargas maiores, o benefício é uma latência reduzida em até 15 vezes para a chamada RFC.
Para colocar isso em perspectiva: podemos fazer 15 chamadas RFC com serialização colunar junto com a WAN ao mesmo tempo que fazemos uma chamada RFC com a configuração padrão (ignorando outros fatores).
Podemos executar o teste com um número maior de solicitações e deixar os testes rodarem por mais tempo para que a lei dos grandes números entre em vigor.
No entanto, para testes adicionais, mudei do Cloud Intergation para um cliente Java local pelos seguintes motivos:
1) Eu queria executar testes com diferentes tamanhos de carga útil para ver os valores dos parâmetros entrarem em vigor. A integração na nuvem consome muito tempo devido a latências adicionais (especialmente com a configuração padrão).
2) Eu queria estudar os efeitos dos parâmetros que usamos para otimização. Eu queria verificar se esses parâmetros têm o mesmo efeito em uma configuração de LAN local.
TESTES COM CLIENTES NA MESMA REDE DO SERVIDOR SAP.
Para esses testes criei um programa Java que chama a mesma RFC com três destinos RFC. O programa reside no mesmo host que o sistema SAP. Os três destinos RFC espelham os destinos BTP:
Um destino RFC “normal” sem valor jco.client.serialization_format. Este destino usará o formato de serialização rowBased padrão.
Um segundo destino com jco.client.serialization_format=columnBased e jco.client.network = LAN
Outro destino com jco.client.serialization_format=columnBased , jco.client.network=WAN
Propriedades de amostra:
#Destination Config for the target system
jco.client.ashost=host
jco.client.sysnr=00
jco.client.client=001
jco.client.user=user
jco.client.passwd=password
jco.client.lang=en
#Additional properties
jco.destination.repository_roundtrip_optimization=1
jco.client.serialization_format=columnBased
jco.client.network=lan
jco.destination.pool_capacity=10
jco.destination.expiration_time=600000
jco.destination.expiration_check_period=120000Executando testes para os três destinos com tamanho de dados de 1,69 MB. O processamento LAN baseado em colunas é 3 vezes mais rápido que o processamento normal. Todas as medições estão em milissegundos.
Coluna LAN processamento: 37|20|13|9|9|8|9|9|10|9|7|7|6|7|6|6|7|6|9|6|5|8|7|7|7|8|7|7|7|8|7|8|8|8|10|7|8|7|7|8|9|8|9|7|6|8|7|6|7|6
Coluna WAN processamento: 37|23|19|15|17|16|15|15|13|14|16|13|11|10|10|11|10|10|10|11|11|12|12|12|13|11|13|12|12|12|12|12|11|11|12|12|12|11|11|13|11|14|12|12|10|12|11|12|11|11
Linha processamento: 94|37|43|26|27|24|24|22|24|26|26|22|24|22|21|23|22|21|21|21|23|22|24|23|24|22|23|22|23|22|23|23|21|22|25|21|21|24|22|22|23|22|21|23|22|24|25|22|22|21
Executando testes para os três destinos com tamanho de dados de 16,91 MB. O processamento LAN baseado em colunas agora é 6x mais rápido que o processamento normal.
Coluna LAN processamento: 96|60|36|31|33|25|25|25|27|25|26|23|25|24|27|25|25|25|24|23|26|23|25|28|22|24|24|25|24|26|24|23|24|26|24|23|25|24|26|24|23|25|22|25|23|25|24|24|25|23
Coluna WAN processamento: 102|57|49|49|50|45|44|46|47|44|49|45|46|45|45|45|49|44|44|46|45|44|45|45|45|45|46|45|46|45|45|46|46|47|46|45|46|47|46|46|45|47|48|46|47|46|46|46|48|49
Linha processamento: 324|186|178|183|175|183|181|182|181|179|177|180|178|180|176|176|175|175|179|179|177|175|179|176|175|176|175|176|176|177|181|177|180|183|178|177|181|176|179|179|176|180|178|177|175|177|177|180|175|176
Uma das vantagens do processamento local é que posso medir rapidamente o desempenho. Aumento do tamanho dos dados para 169,1 MB. O processamento LAN baseado em colunas é cerca de 9 vezes mais rápido que o processamento normal!
FONTE