Introdução

Estabilidade e desempenho têm uma função importante nos soluções de integração de arquitetura orientada a serviços (SOA). O WebSphere Process Server (daqui em diante chamado de Process Server) e o WebSphere Enterprise Service Bus (ESB) são dois produtos que ajudam a criar soluções bem-sucedidas de soluções de integração SOA. Uma vez que uma solução é agrupada, uma fase de ajuste é normalmente executada para garantir que a solução possa produzir o rendimento ou o tempo de resposta necessário para o negócio que é idealmente capturado nos acordos de nível de serviço. Esse esforço de ajuste normalmente aumenta o rendimento para uma situação balanceada que consiste em uma taxa constante de solicitações inseridas e desempenho constante de serviços backend chamados.

Na realidade, condições balanceadas não são sempre atendidas. Pode haver momentos em que a taxa de entrada é, excepcionalmente, alta, os serviços backend são mais lentos que o esperado e o desempenho do sistema é pior que o usual. Esse artigo descreve como lidar com essas situações de sobrecarga de sistema.

Assume-se, neste artigo, que você possui conhecimento intermediário ou avançado em administração do Process Server.

Observe: o conteúdo deste artigo também é aplicável para o IBM® Business Process Manager (BPM) Advanced.

Voltar para parte superior

Visão Geral

O Process Server é um produto de middleware que ajuda a criar soluções de integração SOA. Os componentes fundamentais do Process Server são Business Process Choreographer (BPC), Human Task Manager e ESB.

Conforme mostrado na Figura 1, os blocos de construção das soluções do Process Server são componentes SOA que interagem uns com os outros com a ajuda do Service Component Architecture (SCA). Componentes de serviços criados para o Process Server, como componentes do fluxo de mediação, processos de negócios ou máquinas de estado de negócios:

• São expostos e chamados como serviços com ligações SCA, WebService, JMS, MQ ou outras ligações.
• Podem chamar outros componentes ou serviços backend através de chamadas SCA.

Normalmente, uma coleção de componentes é agregada em um módulo SCA. Um módulo SCA é uma unidade de instalação, administração e operação.

Diversos módulos SCA normalmente trabalham juntos para criar uma solução que solucione um problema específico de negócios. O desenvolvimento de uma solução como essa é apenas uma parte do processo. Uma vez que essa solução foi criada, é necessário ajustá-la para garantir que ela cumpre com a qualidade de seus requisitos de serviço. Durante o esforço de ajuste, assegure-se de que seu sistema possa lidar com uma carga maior que a esperada durante a produção. Após o ajuste da solução e de ela ter sido encaminhada para produção, é necessário o monitoramento constante para garantir que não haja gargalos com o passar do tempo.

Voltar para parte superior

Ajustando uma solução Process Server

Para ajustar o desempenho de uma solução Process Server, o sistema, normalmente, é exposto a uma determinada carga. Então, ele é monitorado e os gargalos são identificados e removidos. Normalmente, após a remoção de um gargalo, o próximo gargalo aparece e é removido. Esse processo é repetido até que o desempenho do sistema seja satisfatório, o que significa que o sistema cumpre com o os requisitos de tempo de resposta ou rendimento que são normalmente capturados pelos contratos de acordos de nível de serviço.

As primeiras etapas do ciclo de ajuste são monitorar e ajustar o sistema operacional e o desempenho do banco de dados. Essas atividades não fazem parte do escopo deste artigo. Consulte a seção Recursos deste artigo para obter referências.

Após isso, você precisará ajustar o Process Server. Parâmetros importantes para monitorar e modificar o seguinte:

• Espaço de heap disponível
• Política de coleta de lixo
• Tamanhos de conjunto de conexões das origens de dados JDBC e conexões fábrica JMS
• Tamanhos de conjunto de encadeamentos
• Parâmetros de simultaneidade máxima de Message Driven Beans (MDBs)

Cada mudança em um desses parâmetros pode necessitar alterações em parâmetros adicionais. Por exemplo, se um tamanho de conjunto de encadeamentos WebSphere for aumentado, será necessário também aumentar os tamanhos de conjunto de conexões e, uma a uma, as sessões máximas ou parâmetros de aplicativos do banco de dados. Normalmente, o ajuste necessita de várias iterações até que uma configuração estável com desempenho satisfatório seja obtida.

O processe de ajuste é feito com uma carga máxima, que é significativamente maior que a carga média durante o tempo típico de produção. Ao fazer isto, o sistema pode lidar com aumentos de carga não esperados durante a produção. Entretanto, pode haver situações na produção em que a carga extra, a degradação de serviços backend ou a degradação de desempenho de banco de dados seja tão grande que podem ocorrer problemas no sistema.

Voltar para parte superior

Motivos da ocorrência de situações de sobrecarga

Há diversas possibilidades que fazem com que haja carga alta não esperada no sistema Process Server, incluindo, mas não se limitando ao seguinte:

• Solicitações recebidas de alto volume não esperadas
• Falhas em soluções em cluster
• Sistemas backend lentos
• Banco de dados lento
• Rede lenta

Solicitações recebidas de alto volume não esperadas

O Process Server executa soluções customizadas que contêm módulos SCA e módulos de mediação. Normalmente, esses módulos processam solicitações obtidas a partir de fontes externas. Há muitos modos de recebimento dessas solicitações pelo Process Server, como:

• Recebimento de solicitações de serviço da web através de HTTP/HTTPS ou SOAP através de transporte JMS
• Solicitações JMS assíncronas recebidas através de filas JMS
• Os adaptadores de entrada podem fazer pesquisa no sistema de arquivos, banco de dados ou podem ser acionados pelo Enterprise Information Systems

Todas essas fontes externas são sujeitas a oscilações. Pode haver momentos em que sejam recebidas mais solicitações de cliente que o esperado.

Além disso, pode haver motivos operacionais para picos nas solicitações recebidas. Por exemplo, se o Process Server for encerrado durante um intervalo de serviço programado, uma fila MQ de entrada poderá ser preenchida. Quando o Process Server for iniciado novamente, o sistema receberá muitas mensagens dessa fila de entrada com solicitações.

Falhas em soluções em cluster

Outra possibilidade é que em uma solução em cluster, um membro de cluster experimente uma falha de hardware. Em seguida, esse membro é encerrado e os membros restantes devem proporcionar a cada processo uma carga maior já que a carga total será agora distribuída em menos máquinas. Em um caso extremo, em que o cluster é constituído de duas máquinas, a máquina restante deve ser, então, preenchida com o dobro da carga usual.

Sistemas backend lentos

As soluções de Process Server chamam serviços oferecidos por sistemas backend. Esses sistemas backend podem ser extremamente lentos às vezes. Por exemplo, pode haver tarefas em lote sendo executadas em servidores backend durante a noite que consomem recursos não disponíveis do sistema para processamento de serviços backend.

Banco de dados lento

O Process Server usa vários bancos de dados que contêm regras de negócios, mensagens JMS gerenciadas por mecanismos de mensagens e dados de instância e modelo para processos de negócios. Esses bancos de dados podem se tornar excepcionalmente lentos em momentos específicos devido a vários motivos. Tabelas e índices podem ser preenchidos, ocasionando degradação de desempenho, outras atividades no sistema que armazenam o banco de dados podem impactar negativamente o desempenho ou uma falha de hardware pode ocorrer em um cache de disco. Há muitos motivos possíveis para que o desempenho do banco de dados seja temporariamente ou permanentemente degradado. Um banco de dados lento é um dos principais motivos para ocorrer problemas com desempenho no Process Server. Desempenho baixo pode significar que o Process Server não consegue lidar com a carga recebida.

Rede lenta

O Process Server usa bancos de dados para persistir mensagens, regras e processos. Normalmente, esses bancos de dados são acessados através da rede. Isso também se aplica a chamada de serviços backend. Além disso, arquivos de dados (como log de transações) geralmente residem em sistemas de arquivos conectados à rede. Se a rede fica lenta, então o desempenho geral do Process Server diminui e ele não conseguirá lidar com a carga recebida.

Voltar para parte superior

Prevenindo situações de sobrecarga

Estratégias que podem ser usadas para limitar a carga incluem, mas não se limitam a:

• Limitar de forma estática a quantidade de encadeamentos que aceita solicitações externas.
• Limitar de forma estática a quantidade de encadeamentos que aceita solicitações no Process Server.
• Se os backends estiverem lentos, faça uma fila de inovações de serviços backend.
• Monitore e configure o sistema quando a carga estiver sendo recebida.

É fundamental distinguir entre solicitações externas que são processadas de modo síncrono e solicitações processadas de modo assíncrono. Elas criam diferentes cargas no sistema e exigem manipulação diferente.

Em solicitações síncronas, o encadeamento do responsável pela chamada é bloqueado até que o controle retorne da chamada. Normalmente, a implementação do responsável pela chamada é executada no encadeamento do responsável pela chamada.

Em solicitações assíncronas, o responsável pela chamada emite uma solicitação e, então, continua trabalhando. A resposta à solicitação será recebida posteriormente e poderá ser processada pelo mesmo ou por outro encadeamento no responsável pela chamada. Para corresponder uma resposta com uma solicitação específica, um mecanismo de correlação precisa ser empregado. Normalmente, uma interação assíncrona é implementada pelo cliente que envia uma mensagem JMS para uma fila JMS em que ela é selecionada por um Message Driven Bean (MDB) que chama o serviço de destino. Após o processamento da solicitação pelo serviço de destino, ela envia a resposta de volta para a fila de resposta do cliente que é selecionada por um MDB no cliente, chamando o código do cliente que manipula a resposta. Um efeito colateral disto é que uma chamada assíncrona pode produzir um ou mais encadeamentos novos que implementarão o serviço chamado. Esses encadeamentos criam uma carga adicional no sistema.

Limitar a quantidade de encadeamentos que aceitam solicitações externas

É possível limitar a quantidade de encadeamentos que aceitam solicitações de fontes externas. Solicitações síncronas típicas são chamadas EJB, solicitações Web Service e chamadas de serviço com uma ligação SCA síncrona. Essas solicitações síncronas são manipuladas por encadeamentos do conjunto de encadeamentos WebContainer ou ORB.thread.pool. Limitar a quantidade de encadeamentos nesses conjuntos de encadeamentos proporciona um limite superior à quantidade de solicitações síncronas que são processas simultaneamente no sistema.

Se souber que um aplicativo específico usa uma quantia alta não usual de recursos, você poderá usar um conjunto de encadeamentos dedicado para solicitações de entrada para esse aplicativo. Deste modo, é possível controlar quantos encadeamentos estão disponíveis para aquele aplicativo. Para obter detalhes, consulte a seção Using a dedicated thread pool for web services .

Serviços assíncronos são, normalmente, baseados em uma implementação com base em JMS. Nesta implementação, as solicitações de serviço são recebidas em uma fila JMS (como a fila de entrada do módulo) como as mensagens JMS. Essas mensagens JMS são entregues pela infraestrutura WebSphere para o método onMessage() de um MDB e módulo MDB, que chama o código que implementa o serviço. A operação de MDBs é gerenciada por uma especificação de ativação que controla quantos encadeamentos são usados pelo MDB para aceitar solicitações.

A especificação de ativação de MDBs pode ser encontrada no painel de especificação Resources > JMS > Activation . Dependendo do provedor de sistemas de mensagens usado pela especificação de ativação, a quantidade de encadeamentos utilizada pelo MDB é configurada de modo diferente:

• Se a especificação de ativação usar "Default messaging provider", então, a quantidade de encadeamentos usada pelo MDB será controlada pela propriedade da especificação de ativação "Maximum concurrent MDB invocations per endpoint".
• Se a especificação de ativação usar "Platform Messaging Component SPI Resource Adapter" (essas são as especificações de ativação para os MDBs de módulo SCA), então, a quantidade de encadeamentos usada pelo MDB será configurada pelo parâmetro "maxConcurrency" de configuração das propriedades customizadas da especificação de ativação.

Os encadeamentos usados para executar o método onMessage() do MDB são retirados de conjuntos de encadeamentos específicos. O conjunto de encadeamentos usado depende do adaptador de recursos usado pelo MDB ou especificação de ativações. A tabela 1 resume os adaptadores de recurso mais importantes ou conjuntos de encadeamento no Process Server.

Limitar a quantidade de encadeamentos nesses conjuntos de encadeamentos proporciona meios para controlar a quantidade geral de encadeamentos que pode aceitar solicitações assíncronas. Essas solicitações assíncronas podem ser originadas de clientes internos ou externos.

Se todos os serviços fornecidos por um aplicativo tiverem uma ligação assíncrona e você desejar controlar a quantidade de encadeamentos em um nível de módulo, então limite a propriedade customizada "maxConcurrency" da especificação de ativação do Module-MDB ou dos MDBs exportados.

Limitar a quantidade de encadeamentos trabalhando no Process Server

Além de limitar a quantidade de encadeamentos que aceita solicitações recebidas, também é possível limitar a quantidade de encadeamentos no Process Server para processar o trabalho que foi iniciado pelas solicitações assíncronas. Esses são, principalmente, os encadeamentos que executam navegação em processos de negócios em execução. Normalmente, um processo de negócios longo sendo executado é iniciado por uma solicitação que chega de uma fonte externa, através de uma chamada WebService, uma ligação JMS assíncrona ou uma chamada para a API EJB do BPC. Após a conclusão da transação de início do processo, as transações restantes para esse longo processo em execução são executadas em sequência e, potencialmente, ao mesmo tempo, em diferentes conjuntos de encadeamento da transação de início:

• Se o BPC for configurado para usar navegação baseada em JMS, então os encadeamentos de navegação são executados no bean direcionado à mensagem "ProcessContainerMDB". Esse MDB é controlado pela especificação de ativação "BPEInternalActivationSpec". Entretanto, limitar a propriedade "Maximum concurrent MDB invocations per endpoint" dessa especificação de ativação JMS limita a quantidade de encadeamentos que executam a lógica de navegação.
• Se o BPC for configurado para usar navegação baseada em WorkManager, então ProcessContainerMDB é usado para navegação somente em casos excepcionais. Entretanto, a propriedade "Maximum concurrent MDB invocations per endpoint" do BPEInternalActivationSpec é configurada de modo muito menor que no caso da navegação baseada em JMS. Neste caso, a maioria do trabalho de navegação acontece no conjunto de encadeamentos do BPENavigationWorkManager. No entanto, deve-se atentar para o tamanho desse conjunto de encadeamentos.

O objetivo é configurar o sistema de modo que ele seja capaz de aceitar carga suficiente para atender seus requisitos de desempenho durante momentos oportunos, além de limitar a carga de modo suficiente a fim de prevenir a sobrecarga do sistema em momentos inoportunos. Esses dois objetivos são, de algum modo, contraditórios e, portanto, não será possível atendê-los sempre. Normalmente, o sistema é, então, configurado de modo que possa aceitar carga suficiente durante momentos oportunos, mas que tenha mais encadeamentos que possam ser tolerados durante momentos inoportunos.

Para evitar a sobrecarga, será necessário monitorar o sistema e agir se a carga aumentar muito.

Voltar para parte superior

Detectando uma sobrecarga de sistema

Se um sistema estiver sobrecarregado, ele poderá apresentar vários sintomas, incluindo, mas não se limitando ao seguinte:

• O SystemOut.log está com muitas exceções.
• O sistema reage apenas de modo muito lento para solicitações administrativas.
• A utilização de CPU pode ser superior a 100%.
• As transações começam a atingir o tempo limite.
• Os encadeamentos começam a ser interrompidos. Neste caso, a utilização de CPU pode diminuir, mas as filas podem começar a aumentar.

Como isso é difícil e consome tempo para recuperação de uma situação de sobrecarga, é necessário monitor constantemente seu sistema e determinar medidas que indiquem se uma situação de sobrecarga está se aproximando antes que ela realmente ocorra. É muito mais fácil manter um sistema sem problemas antes que o problema ocorra do que fazer o recuperar de uma situação de problema real.

O indicador que mostra uma situação de sobrecarga se aproxima dependendo do cenário de aplicativo. Ele pode ser, sem se limitar ao seguinte:

• Alto número de processos brevemente persistentes em estado de execução (processos brevemente persistentes são processos de negócios em execução longa que são executados somente por um pequeno período, como alguns minutos).
• Alto número de mensagens em determinadas filas JMS.
• Alto número de encadeamentos ativos em determinados conjuntos de encadeamentos.
• Alto número de registros na tabela SAVED_ENGINE_MESSAGE_B_T de BPEDB.

Voltar para parte superior

O que fazer se o sistema se aproximar da sobrecarga

Como modificações de parâmetros na configuração do WebSphere, como tamanhos de conjunto de encadeamentos, propriedades de especificações de ativação ou filas de barramento de integração de serviço tem efeito após a reinicialização do servidor, é desafiador escolher ações adequadas após a aproximação da sobrecarga do sistema. Modificar os parâmetros e interromper e reiniciar o servidor normalmente não é uma opção. Felizmente, há algumas medidas que podem ser tomadas:

1. A melhor solução é prevenir essa situação e desenvolver aplicativos a fim de incluir módulos de mediação que possam aceitar apenas um número definido de solicitações por intervalo de tempo. Idealmente, é possível modificar esses números de modo dinâmico no tempo de execução. Para obter detalhes sobre como fazer isso, consulte Just in time throttler and dispatcher for WebSphere ESB. Uma abordagem alternativa é descrita nesse artigo, WebSphere Process Server throughput management, Part 2.
2. Outra possibilidade é usar o recurso Store and Forward. Ao desenvolver um aplicativo, é possível configurar o qualificador Store and Forward em componentes que são chamados de modo assíncrono. Caso detecte uma situação de sobrecarga, será possível usar o widget Store and Forward no Business Space para configurar o estado dos componentes fundamentais para "Store". Esses componentes não serão mais chamados. Em vez disso, as mensagens de solicitação para esses serviços são armazenadas em uma fila específica.

   Depois da resolução da situação restringida, é possível configurar o estado desses componentes de volta para "Forward" e, posteriormente, as solicitações armazenadas (e todas as novas solicitações) serão encaminhadas para processamento. Para obter detalhes, consulte as seções Store and forward no Centro de Informações.

3. As duas opções anteriores necessitam de conceitos específicos nos aplicativos que foram definidos durante a modelagem do aplicativo. Caso essa oportunidade tenha sido perdida, ainda será possível parar temporariamente terminais de sistema de mensagens individuais. Isso pode ser feito através de scripts administrativos. Para obter detalhes, consulte How to stop a messaging endpoint.

   Parar um terminal de sistema de mensagens evita que os beans direcionados à mensagem associada aceitem mensagens recebidas. Isso reduz a carga do sistema pelas mensagens de solicitação JMS que são inseridas no sistema para chamar serviços com ligação assíncrona. Também é possível parar temporariamente o terminal para ProcessContainerMDB. Isso reduz a carga do sistema criada pelos encadeamentos de navegação de processo. Se a maioria das transações de navegação falhar, essa pode ser a ação desejada até que o problema da infraestrutura subjacente for resolvido ou melhorado.

   Se terminais de sistema de mensagens forem parados, as filas associadas a esses MDBs serão preenchidas ao longo do tempo. Entretanto, é fundamental configurar as capacidades da fila de modo grande o suficiente e continuar os terminais parados o mais breve possível uma vez que a situação restringida for resolvida ou melhorada.

4. A próxima ação possível é parar os aplicativos corporativos. O efeito é similar ao do marcador anterior, mas neste caso, todos os serviços pertencentes ao aplicativo não aceitarão mais solicitações recebidas. Isso inclui não apenas serviços com ligação assíncrona, mas também serviços com ligação síncrona.

   Se desejar parar os aplicativos, considere o seguinte:

   • Aplicativos que contêm processos longos de BPEL em execução não podem ser parados a menos que instâncias em execução desses processos existam. Entretanto, é possível que você queira criar módulos separados para processos longos de BPEL em execução e para microfluxos. É possível parar esses aplicativos que contêm microfluxos se houver uma situação de sobrecarga. No entanto, normalmente, não é possível parar aplicativos com processos longos em execução.
   • Se serviços com ligação assíncrona pararem de aceitar solicitações, o único efeito visualizado por um cliente é que o recebimento de uma resposta demora mais. Por outro lado, se serviços com ligação síncrona pararem de aceitar solicitações, então, seus clientes poderão receber exceções ou tempos limite. Entretanto, será necessário parar os aplicativos se os clientes puderem lidar com exceções ou tempos limite.

Voltar para parte superior

Usando um conjunto de encadeamentos dedicado para serviços da web

Se desejar ajustar a quantidade de encadeamentos usada para serviços da web específicos, então configure esses serviços da web para usar um conjunto de encadeamentos dedicado.

Os serviços da web são executados no contêiner de web. O WebSphere usa cadeias de transporte com canais de transporte associados para controlar o tráfego de contêiner de web e conjuntos de encadeamentos.

Para designar um conjunto de encadeamentos dedicado para um serviço da web específico, é necessário:

• Criar um novo conjunto de encadeamentos.
• Criar uma nova cadeia de transporte com uma porta dedicada e designar o novo conjunto de encadeamentos a ela.
• Adicionar a porta dedicada a hosts virtuais.
• Usar a nova porta para chamadas de serviço da web.

Criar um novo conjunto de encadeamentos

É possível criar um novo conjunto de encadeamentos através do painel do console admin ao selecionar Application servers > server1 > Thread pools. A página do conjunto de encadeamentos é mostrada na Figura 2. Com o botão New neste painel, é possível criar um novo conjunto de encadeamentos, por exemplo "MyThreadPool".

Criar uma nova cadeia de transporte

Depois disso, é possível criar uma nova cadeia de transporte. Acesse Application servers > server1 > Web container transport chains e clique no botão New (Figura 3). Deste modo, você insere um diálogo em que é possível especificar o nome da cadeia de transporte e a porta que ela recebe. A porta específica é usada para trabalhar de modo explícito com essa cadeia de transporte.

Após a definição da nova cadeia de transporte, o link para ela deve ser seguido, conforme mostra a Figura 4.

Se o link "TCP inbound channel" for seguido na nova cadeia de transporte, será possível modificar o conjunto de encadeamentos usado. Especifique o conjunto de encadeamentos criado.

Adicionar uma porta nova aos hosts virtuais

A última etapa é adicionar a nova porta TCP/IP como um novo alias, conforme mostra a Figura 5. Selecione Environment > virtual hosts > default host.

Agora, se os serviços da web forem chamados em seu módulo específico através da nova porta (no exemplo, é 9087), o WebSphere usará apenas encadeamentos do "MyThreadPool" para executar o serviço.

Voltar para parte superior

Conclusão

Se a taxa de solicitações processadas por um sistema em um determinado intervalo for menor que a taxa de solicitações inseridas no sistema durante o mesmo intervalo, então algumas solicitações devem ser enfileiradas. Isto apenas funciona para um certo período, caso contrário as filas serão preenchidas e, eventualmente, estourarão. Entretanto, é fundamental que:

• Os tamanhos das filas sejam grandes o suficiente para permitir que as filas armazenem em buffer trabalho suficiente.
• O sistema possa processar, de modo significativo, mais que a carga média típica inserida no sistema. Isso reduz a quantidade de situações de sobrecarga e acelera a recuperação se ocorrer uma situação de sobrecarga.

Dependendo do cenário, como a topologia e os sistemas backend, serviços e módulos envolvidos, poderá ser necessário configurar um dos seguintes:

• Solicitar inserção no sistema: as filas serão criadas na parte frontal do sistema.
• Solicitar processamento no sistema: as filas serão preenchidas no sistema.
• Solicitar chamada de serviços backend: as filas de entrada de backend serão preenchidas.

Durante o ajuste do sistema, certifique-se de que haja contingência suficiente no sistema para que ele possa lidar suavemente com os aumentos de carga. Em caso de muitos problemas como degradação de desempenho backend, monitore seu sistema continuamente. Ao visualizar uma situação de sobrecarga se aproximando, configure a carga no sistema.

Recursos

Aprender

• Operando um ambiente Websphere Process Server, Partes 1 a 5:
  
  
• Case study: Tuning WebSphere Application Server V7 and V8 for performance
  
  
• Best Practices: Tuning and Monitoring Database System Performance
  
  
• WebSphere Process Server Performance Tuning Worksheet
  
  
• WebSphere Process Server 6.1 – Tuning Automatic Processes
  
  
• IBM Redbook: WebSphere Business Process Management 6.2.0 Performance Tuning
  
  
• Just in time throttler and dispatcher for WebSphere ESB
  
  
• The WebSphere Process Server store and forward feature
  
  
• How to stop a messaging endpoint
  
  
• Configuring MDB or SCA throttling for the default messaging provider
  
  
• WebSphere Process Server throughput management, Part 2
  
  
• Página de recursos do developerWorks do WebSphere Process Server e WebSphere Integration Developer
  
  

Discutir

• Fórum de discussão do WebSphere Process Server
  
  

Sobre o autor

Bernd Breier é Software Engineer no IBM Research and Development Lab em Boeblingen, Alemanha. Ele tem 15 anos de experiência como desenvolvedor nas áreas de fluxo de trabalho, integração de negócios e Business Process Management. Desde 2010, é membro da equipe Business Process Management SWAT, aconselhando clientes sobre as melhores práticas e fornecendo suporte fundamental em várias situações importantes de cliente em todo o mundo. Ele se formou em engenharia física e passou a fazer parte da IBM em 1984.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Visão Geral
• Ajustando uma solução Process Server
• Motivos da ocorrência de situações de sobrecarga
• Prevenindo situações de sobrecarga
• Detectando uma sobrecarga de sistema
• O que fazer se o sistema se aproximar da sobrecarga
• Usando um conjunto de encadeamentos dedicado para serviços da web
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais