on 11-12-2009 6:59 PM
Boa tarde.
Estou dando uma olhada na configuração na SWF_INB_CONF e estou vendo que cada serviço esta configurado de uma forma:
Sei que cada configuração depende do Hardware do cliente, mas queria tirar algumas dúvidas:
1) Without Buffering não deixa o processamento mais rapido? Nao é melhor colocar para todos?
2) Quanto mais fila melhor? (considerando que a máquina suporte)?
3) A configuração abaixo esta razoavel? Poderia configuração abaixo causar mensagens de cancelamento ficarem algumas vezes paradas na fila processando(RUNNING)?
BATCH_BatchProcess
Delivery Mode: Without Buffering
Queue Assignment: Multiple Queues (Random)
Number of Queues: 5
BATSR_BatchStatusRequestProcess
Delivery Mode: Without Buffering
Queue Assignment: Multiple Queues (Random)
Number of Queues: 5
CANCR_CancellationRequestProcess
Delivery Mode: Buffering Possible
Queue Assignment: One Queue
Number of Queues: 1
NFESC_NFeStatusCheckProcess
Delivery Mode: Without Buffering
Queue Assignment: Multiple Queues (Random)
Number of Queues: 3
SIGNC_SignCancNFeProcess
Delivery Mode: Buffering Possible
Queue Assignment: One Queue
Number of Queues: 1
SIGNN_SignNFeProcess
Delivery Mode: Without Buffering
Queue Assignment: Multiple Queues (Random)
Number of Queues: 3
SIGNS_SignInutNFeProcess
Delivery Mode: Buffering Possible
Queue Assignment: One Queue
Number of Queues: 1
SKIPR_SkippingRequestProcess
Delivery Mode: Buffering Possible
Queue Assignment: One Queue
Number of Queues: 1
Agradeço desde já.
At.,
Bernardo Tavares Braga
Bom dia Bernardo,
1) Não tenho certeza, mas seria o contrário With Buffering seria mais rápido, porém vc só pode configurar mais de uma fila se usar o Without Buffering que no final das contas vai mais rápido por executar em paralelo. Quando a colocar em todas, melhor analisar os casos em que vc realmente precisa disso. Veja comentários por processo
2) Sim, porém é um ajuste fino entre quantidade de dialogs disponíveis e recursos RFC. Sugestão: Fazer stress test em DEV e acompanhar... faça simulações e veja o que fica melhor na sua necessidade de negócio/hardware.
3) Aí tem duas questões FILA não quer dizer que fica em running direto, se ficar em running direto para a mesma mensagem o problema é outro. Mantenha o GRC atualizado por SP's, estamos constantemente adicionando tratamentos que reduzem a zero os erros de fila parada. Em resumo quanto mais atualizado menos você precisa caçando coisas no PI...
Quanto às interfaces, tem que se ter em vista o processo normal de NF-e que é EMISSÃO. Cancelamento, inutilização e consulta de status são pontuais e dependendo do seu hardware não faz sentido algum paralelizá-los pois concorrerão com o processo principal que é EMISSÃO.
SIGNN_SignNFeProcess - Esta é a interface que necessita da maior quantidade de processos possíveis, deixe maior que os outros (tente 10)
BATCH_BatchProcess - Ok c/ multiplas filas
BATSR_BatchStatusRequestProcess - Ok c/ multiplas filas
NFESC_NFeStatusCheckProcess - Evite o paralismo aqui. Você estaria comprometendo a principal missão p/ status query de NF-es de fornecedor for grande
Ok para individual: SIGNC, SIGNS, CANCR, SKIPR
Este paralelismo é nas interfaces no PI, e existe uma REGRA DE OURO pro GRC NFE para atingir um super troughput no GRC. Criar o menor número de lotes possíveis. Como ? Assinando rápido (por isso prioridade para o SIGNN) e permitindo o lote com 50 NF-es, e aumentar o tempo de espera até um ponto onde consiga colocar o maior número possível de NF-es sem impactar o negócio. Veja esta thread que explica bem isto:
Instalações com 1 NF-e por lote. Também tem 2 interfaces por NF-e que representam 12 mensagems no PI, duas comunicações com Sefaz..... Gastando disco, rede, internet...
Pra terminar: TUNNING é equilíbrio NÃO EXISTE REGRA QUANTO AOS VALORES, tem que entender e testar, vai depender de negócio x capacidade de processamento. Bom senso e equilíbrio.
Atenciosamente, Fernando Da Ró
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Alguns comentarios:
1) without buffering eh mais rapido sim, teoricamente. Mas nem todo design de BPM pode ser without buffering (por exemplo, se o BPM tem correlacao nao pode). No caso do NFE, todos os BPMs sao simples pontes async/sync, entao pode ser tudo without buffering sim.
Se tiverem curiosidade e quiserem mais detalhes de como funciona o Inbound Processing do BPE e sugestoes de design de BPMs:
http://help.sap.com/saphelp_nw70/helpdata/en/45/1a9702109921a0e10000000a1553f6/frameset.htm
2) notem que essas filas nao sao filas de interface (que vc paraleliza atraves de parametros na SXMB_ADM; mais detalhes no PI Tuning Guide). Elas sao filas de execucao dos BPMs (que nada mais sao que qRFCs). Cada entrada na fila é um processo (workflow) esperando pra ser executado.
3) o ideal eh vc usar algo em torno de 80% dos dialog WPs que vc tem com filas de execucao dos processos de emissao (SIGNN, BATCH e BATSR). Os demais WPs servem para usuarios logados, para os demais processos (CANC, SKIP, NFESC) e tambem para os proprios processos do PI (o PI usa WP dialog pra processar filas de interface! entao nao adianta usar todos os WPs com fila de BPM que a performance vai ser é pior). Dentro do numero de WPs que vc usará para os 3 processos de emissao, a distribuicao otima é algo do tipo x:y:y (SIGNN:BATCH:BATSR), onde x/y = numero medio de NFes por lote. Note que esse numero medio é diferente da quantidade maxima de NFes configurada. Vc pode ter 10 NFes/lote na configuracao, mas na média vc pode ter 3 NFes/lote pq tem varios lotes com poucas notas. Entao no caso x/y = 3, x = 3y. O numero total de WPs das filas desses 3 processos seria entao x + y + y = 5y. Suponha por exemplo que vc tinha 32 WPs dialog no total, 80% dah algo em torno de 25. Desses, vc teria que deixar 15 para SIGNN, 5 para BATCH e 5 p/ BATSR. Na pratica, vc pode ir brincando com esses valores (e.g. baixa SIGNN para 13, aumenta os outros para 6, ou vice versa) e verificar o ponto otimo que maximiza o throughput de notas/minimiza o tempo de processamento medio.
Abs,
Henrique.
Excelente. Ajudou bastante. Vou dar uma lida nos materiais e fazer os ajustes necessários.
Muito obrigado.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.