{"id":2561,"date":"2021-07-01T09:43:35","date_gmt":"2021-07-01T12:43:35","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2561"},"modified":"2024-01-11T17:59:08","modified_gmt":"2024-01-11T20:59:08","slug":"fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/","title":{"rendered":"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03"},"content":{"rendered":"Performance sempre ser\u00e1 um atributo de qualidade importante, em qualquer arquitetura.<\/strong> Sistemas sem performance satisfat\u00f3ria t\u00eam usability, avialability\u00a0<\/em>e scalability <\/i>comprometidos.\u00a0Em \u00faltima inst\u00e2ncia, sistemas que n\u00e3o atendem expectativas m\u00ednimas de boa performance falham em cumprir os objetivos do neg\u00f3cio.\n
\n

Pela relev\u00e2ncia, as expectativas m\u00ednimas de boa performance devem ser determinadas o mais cedo poss\u00edvel. Depois disso, devem ser consideradas na avalia\u00e7\u00e3o das proposi\u00e7\u00f5es de design <\/em>arquiteturais\u00a0candidatas.<\/p>\nInicialmente, as expectativas de performance podem ser expressas pelos tempos percebidos pelos usu\u00e1rios na utiliza\u00e7\u00e3o de\u00a0features\u00a0<\/em>chave.<\/strong> Entretanto, na medida em que decis\u00f5es de design\u00a0<\/em>s\u00e3o realizadas, devem ser especializadas para cada componente.\n

\n\u00c9 importante, entretanto, n\u00e3o ignorar que iniciativas para melhorar a performance geralmente adicionam complexidade e podem prejudicar o evolvability.\u00a0<\/em><\/strong>Performance \u00e9 fundamental, mas, se perseguida cegamente pode atingir n\u00edveis desnecess\u00e1rios que s\u00f3 corroem a manutenabilidade, incrementando os custos.\n

\"\"<\/p>\n

 <\/p>\n

\r\n

Usabilidade define performance<\/p>\r\n<\/p>\n

Performance \u00e9 determinante para melhorar a usabilidade. Entretanto, distante do \u00f3bvio, algumas vezes o segredo n\u00e3o \u00e9 “aumentar a velocidade”, mas diminuir.<\/strong><\/p>\n

William Santos<\/a>, integrante da primeira turma de mentoria em arquitetura de software compartilha um cen\u00e1rio curioso, relacionado a sistemas de Home Broker<\/em>. Segundo ele destaca, frequentemente as cota\u00e7\u00f5es de renda vari\u00e1vel s\u00e3o atualizadas em intervalos menores aos que o olho humano \u00e9 capaz de captar. Nestes casos, performance n\u00e3o necessariamente \u00e9 positiva. Para tornar as atualiza\u00e7\u00f5es percept\u00edveis, em um dos sistemas em que esteve envolvido, foi estabelecido um intervalo m\u00ednimo para propag\u00e1-las, de modo a descartar o envio da cota\u00e7\u00f5es que seriam impercept\u00edveis. Desta forma, apenas atualiza\u00e7\u00f5es percept\u00edveis passaram a ser transmitidas, o que aumentou o conforto do cliente, levando-o a ter mais clareza sobre as mudan\u00e7as e podendo tomar decis\u00f5es mais bem pensadas \u2013 ao mesmo tempo em que reduziu o consumo de recursos para a transmiss\u00e3o de cota\u00e7\u00f5es.<\/p>\n

<\/div>\n

Definindo performance<\/h2>\n

De maneira superficial, performance, como atributo de qualidade, trata do tempo que um sistema necessita para completar uma determinada categoria de atividades.\u00a0<\/strong>De forma mais precisa, entretanto, a performance tamb\u00e9m tem rela\u00e7\u00e3o direta com a capacidade para suportar workloads<\/em> – com tamanhos diversos em intervalos com m\u00ednimos e m\u00e1ximos bem-definidos – e restri\u00e7\u00f5es de recursos computacionais.<\/p>\nUm sistema tem performance “good enough<\/em>” quando atende as expectativas relativas aos tempos para executar processamentos, sob uma determinada carga, sem saturar os recursos computacionais dispon\u00edveis. Tudo isso, otimizando a fun\u00e7\u00e3o de avalia\u00e7\u00e3o da arquitetura, geralmente o custo.<\/strong>\n

\r\n

Quando o 'neg\u00f3cio' n\u00e3o sugere performance<\/p>\r\n<\/p>\n

O ideal \u00e9 sempre alinhar expectativas de performance antes de fazer qualquer decis\u00e3o de design<\/em>. Entretanto, com frequ\u00eancia, as expectativas do neg\u00f3cio s\u00e3o inexistentes ou vagas.<\/p>\n

Tem pouca utilidade, por exemplo, determinar que o response time\u00a0<\/em>de um determinado\u00a0endpoint\u00a0<\/em>deve ser abaixo de 300 ms\u00a0<\/em>se n\u00e3o se conseguir estimar um\u00a0workload\u00a0<\/em>associado.<\/p>\n

Quando sistemas s\u00e3o elaborados sem essa “expectativa” clarificada, \u00e9 \u00fatil realizar testes de estresse afim de determinar a realidade atual e validar se esta \u00e9 suficiente. Eventualmente, essa abordagem, entretanto, pode revelar “tempo perdido” com uma solu\u00e7\u00f5es que “ficam devendo”, ou desperd\u00edcio com solu\u00e7\u00f5es que “sobram demais”.<\/p>\n

<\/div>\n

Rela\u00e7\u00e3o com o custo<\/h2>\nA boa arquitetura de software atende os objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es e atingindo par\u00e2metros expressos nos atributos de qualidade. Para isso, trata do design\u00a0<\/em>dos componentes, suas responsabilidades e relacionamentos, tudo isso, de acordo com uma fun\u00e7\u00e3o objetivo, geralmente o custo.<\/strong>\n
\n

Melhorar a performance sempre impacta o custo, por isso, \u00e9 importante determinar que abordagem utilizar. As vezes, melhorar a infraestrutura custa menos do que melhorar o c\u00f3digo. Outras vezes, melhorar o c\u00f3digo compensa a economia em infraestrutura. \u00c9 importante ter sensibilidade.<\/p>\n

Aspectos determinantes para a performance<\/h2>\n

H\u00e1 quatro aspectos determinantes para a performance de um sistema de software e que, por isso, s\u00e3o preocupa\u00e7\u00f5es arquiteturais: tamanho do workload, <\/em>restri\u00e7\u00f5es para recursos computacionais, estrat\u00e9gias de enfileiramento e qualidade interna de implementa\u00e7\u00e3o dos componentes.<\/p>\n

\"\"<\/p>\n

Tamanho do workload<\/em><\/h4>\n

\u00c9 fundamental, para o design<\/em> de sistemas com boa performance, conhecer qual ser\u00e1 o tamanho do workload<\/em>\u00a0que dever\u00e1 ser suportado. <\/strong>Geralmente, \u00e9 \u00fatil (e at\u00e9 mais f\u00e1cil) realizar tr\u00eas tipos de previs\u00f5es: pessimista, otimista e realista.<\/p>\nPor exemplo, para sistemas Web interativos \u00e9 interessante saber a quantidade usu\u00e1rios simult\u00e2neos, o padr\u00e3o de comportamento desses usu\u00e1rios, o volume de dados ser\u00e1 manipulado (tanto em comandos quanto em consultas), etc.\n

\n

\u00c9 a partir da previs\u00e3o do workload\u00a0<\/em>que \u00e9 poss\u00edvel determinar se o dimensionamento da infraestrutura \u00e9 suficiente.<\/p>\n

Restri\u00e7\u00f5es para recursos computacionais<\/h4>\n

O conhecimento das capacidades de processamento e caracter\u00edsticas de performance das tecnologias autorizadas \u00e9 determinante, no\u00a0design<\/em> arquitetural, para decis\u00f5es relacionadas a organiza\u00e7\u00e3o e estrutura dos componentes.<\/p>\n

As capacidades de resposta das tecnologias permitem antecipar qual ser\u00e1 a realidade da performance, inclusive, estrat\u00e9gias para mitigar riscos de satura\u00e7\u00e3o.<\/p>\n

\r\n

Hardware faz diferen\u00e7a!<\/p>\r\n<\/p>\n

Certa vez, o time de desenvolvimento de um cliente comprometeu semanas de trabalho “otimizando” uma feature <\/em>complexa que fazia uso intensivo de leituras e escritas em dispositivo persistente. Alguns testes apontavam ganhos de performance de 2000%! Entretanto, os ganhos n\u00e3o foram percebidos no ambiente produtivo.<\/p>\n

No ambiente de desenvolvimento e testes o dispositivo persistente era um HDD. Em ambiente produtivo, era um SSD…<\/p>\n

<\/div>\n

Estrat\u00e9gias de enfileiramento<\/h4>\n

Invariavelmente, em qualquer sistema, recursos computacionais poder\u00e3o n\u00e3o estar dispon\u00edveis sempre que uma demada ocorrer – seja por n\u00e3o estarem em estado de prontid\u00e3o ou por conten\u00e7\u00e3o em outra atividade. Sempre que isso acontece, h\u00e1 espera (wait time<\/em>).<\/p>\n

\r\n

.NET Socket Starvation<\/em><\/p>\r\n<\/p>\n

.NET tem uma falha conhecida de design na classe HttpClient<\/em>. Por algumas raz\u00f5es<\/a>, HttpClient<\/em> n\u00e3o libera os sockets<\/em> que utiliza quando o m\u00e9todo Dispose <\/em>\u00e9 invocado, o que pode fazer com que a aplica\u00e7\u00e3o sofra com Socket Starvation<\/em> ao criarmos muitas inst\u00e2ncias. Eventualmente, isso causa “enfileiramento” de processamentos que precisam de novos sockets\u00a0<\/em>causando redu\u00e7\u00e3o de\u00a0throughput<\/em> e, eventualmente, afetando outros recursos, como mem\u00f3ria e CPU.<\/p>\n

\n

<\/div>\n<\/div>\n

Qualidade interna de implementa\u00e7\u00e3o dos componentes<\/h4>\n

De pouco adianta haverem bons recursos computacionais se o c\u00f3digo n\u00e3o fazer o uso correto destes recursos.<\/strong> Processadores com m\u00faltiplos core\u00a0<\/em>e sistemas single-thread.\u00a0<\/em>Mem\u00f3ria de sobra e processadores potentes, mas interrup\u00e7\u00f5es frequentes de execu\u00e7\u00e3o para coletas de lixo evit\u00e1veis. Etc.<\/p>\n

Pareto e a performance<\/h2>\nEmpiricamente, \u00e9 f\u00e1cil observar que 20% das funcionalidades de um sistema s\u00e3o utilizadas 80% do tempo – trata-se da aplica\u00e7\u00e3o da propor\u00e7\u00e3o\/princ\u00edpio de Pareto. Geralmente, as exig\u00eancias de performance ser\u00e3o maiores para essas funcionalidades.\n
\n

Tamb\u00e9m \u00e9 comum observar que 80% dos recursos computacionais de um sistema s\u00e3o consumidos por 20% do c\u00f3digo.<\/strong> H\u00e1 uma vis\u00e3o rom\u00e2ntica de que a melhoria da performance ocorre “escovando bits<\/em>“, entretanto, na pr\u00e1tica, geralmente os ganhos mais percebidos acontecem por adapta\u00e7\u00f5es do design<\/em> arquitetural, por exemplo, pela adi\u00e7\u00e3o de\u00a0caching,\u00a0<\/em>buscando minimizar o uso de recursos com alto custo computacional, como a rede.<\/p>\nEventualmente, esgotadas as alternativas arquiteturais para otimiza\u00e7\u00e3o, \u00e9 comum observar que, dentro da zona cr\u00edtica de c\u00f3digo (20% que consome 80% de recursos), \u00e9 poss\u00edvel identificar novamente trechos cr\u00edticos – uma esp\u00e9cie de Pareto2<\/sup> (6% do c\u00f3digo, respons\u00e1vel por 64% dos recursos). Geralmente, a otimiza\u00e7\u00e3o desses trechos \u00e9 realizada pela escolha apropriada de bons algoritmos e estruturas de dados.\n

\n

Em sistemas com arquitetura otimizada para a performance, que adotam algoritmos certos e estruturas de dados apropriadas, eventualmente, observa-se uma esp\u00e9cie de\u00a0Pareto3<\/sup> (0,8% do c\u00f3digo, respons\u00e1vel por 51% dos recursos). Nesses casos, e apenas nesses casos, h\u00e1 espa\u00e7o para implanta\u00e7\u00e3o de micro otimiza\u00e7\u00f5es.<\/p>\n

Rela\u00e7\u00e3o com a escalabilidade<\/h2>\n

Performance e escalabilidade s\u00e3o atributos relacionados, por\u00e9m distintos. A escalabilidade diz respeito a capacidade de um sistema de manter sua performance, em cen\u00e1rios de aumento de\u00a0workload<\/em>, mediante a adi\u00e7\u00e3o de recursos computacionais em propor\u00e7\u00e3o favor\u00e1vel.<\/p>\nUm sistema que t\u00eam sua performance deteriorada frente ao aumento do workload<\/em>, sem recupera\u00e7\u00e3o frente a adi\u00e7\u00e3o de recursos computacionais, n\u00e3o \u00e9, de forma alguma, escal\u00e1vel.\u00a0\n

\n

Para tornar mais clara a diferen\u00e7a, considere um sistema de e-commerce. <\/em>Nele, a performance ter\u00e1 rela\u00e7\u00e3o, por exemplo, com o tempo necess\u00e1rio para que um n\u00famero esperado de clientes efetivem o checkout.<\/em>\u00a0Enquanto isso, a escalabilidade tem rela\u00e7\u00e3o com a capacidade de ajustar o sistema para que quantidades maiores de clientes possam ser atendidos, mediante adi\u00e7\u00e3o razo\u00e1vel de recursos (em propor\u00e7\u00e3o igual ou menor ao crescimento do\u00a0workload<\/em>).<\/p>\n

A degrada\u00e7\u00e3o da performance, frente ao aumento do workload,<\/em>\u00a0mesmo com a adi\u00e7\u00e3o\u00a0favor\u00e1vel de recursos, \u00e9 indicador de aten\u00e7\u00e3o para problemas escalabilidade.\u00a0<\/strong><\/p>\n

M\u00e9tricas comuns relacionadas a performance<\/h2>\nA performance de um sistema deve ser avaliada tanto por m\u00e9tricas de tempo, observ\u00e1veis externamente, quanto pelo consumo de recursos.\u00a0<\/strong>\u00c9 correto afirmar que a performance de um sistema melhora tanto quando os tempos observ\u00e1veis de processamento s\u00e3o reduzidos, quanto quando h\u00e1 diminui\u00e7\u00e3o de demanda por recursos computacionais para cumprir as expectativas de tempo de processamento.\n
\n

Tendo em vista o cuidado com a utiliza\u00e7\u00e3o de recursos, qualquer m\u00e9trica de consumo poder\u00e1 ser associada a performance. J\u00e1 as m\u00e9tricas de tempo geralmente s\u00e3o\u00a0response time<\/em>, turnaround time<\/em>\u00a0ou\u00a0throughput<\/i>.<\/p>\n

Eventualmente, o uso combinado de m\u00e9tricas de tempo e de consumo d\u00e3o origem a bons indicadores.<\/p>\nTodas as m\u00e9tricas relacionadas a performance s\u00e3o candidatas a composi\u00e7\u00e3o de fitness functions.<\/em>\n

\n
\r\n

Response time<\/em> ou Turnaround time<\/em>, nunca ambos<\/p>\r\n<\/p>\n

Considere uma API cujo uma das atribui\u00e7\u00f5es \u00e9 receber arquivos, potencialmente grandes, com grande quantidade de dados para processamento. Como avaliar sua performance? Pelo\u00a0response time<\/em>, considerando tempo de resposta para o usu\u00e1rio ap\u00f3s a requisi\u00e7\u00e3o, ou pelo\u00a0turnaround time<\/em>, considerando o tempo total para processamento do arquivo recebido?<\/p>\n

Processar arquivos grandes em uma interface interativa compromete o\u00a0response time,\u00a0<\/em>n\u00e3o s\u00f3 daquela requisi\u00e7\u00e3o, mas de todas as demais para aquele servi\u00e7o. Afinal, “segura” recursos importantes e gera enfileiramento.<\/p>\n

A abordagem mais recomendada \u00e9 enfileirar o arquivo grande em um servi\u00e7o de backend,\u00a0<\/em>que ser\u00e1 avaliado pelo\u00a0turnaround time\u00a0<\/em>e responder o mais r\u00e1pido poss\u00edvel, ou seja, com o melhor\u00a0response time.<\/em><\/p>\n

Se h\u00e1 d\u00favidas sobre qual indicador usar, geralmente, a sa\u00edda \u00e9 decompor solu\u00e7\u00e3o em dois componentes, cada um com sua m\u00e9trica apropriada.<\/p>\n

<\/div>\n

Response time<\/em><\/h4>\n

Em sistemas com intera\u00e7\u00e3o com usu\u00e1rios, o\u00a0response time\u00a0<\/em>indica o tempo consumido entre uma tarefa (ou a\u00e7\u00e3o) ser disparada e uma resposta satisfat\u00f3ria ser gerada. Valores comuns para\u00a0response time\u00a0<\/em>s\u00e3o, geralmente, expressos de fra\u00e7\u00f5es de segundo.<\/strong><\/p>\nQuando aplic\u00e1vel, o response time<\/em> costuma ser a m\u00e9trica de performance mais observada. Afinal, \u00e9 aquela que tem rela\u00e7\u00e3o mais pr\u00f3xima com a satisfa\u00e7\u00e3o dos usu\u00e1rios.\n

\nSistemas com bom projeto de performance devem manter response time\u00a0<\/em>regular, com pouca ou nenhuma degrada\u00e7\u00e3o frente ao aumento do workload<\/em>, desde que n\u00e3o ocorra satura\u00e7\u00e3o dos recursos computacionais indicados como restri\u00e7\u00e3o.\n
\n

Turnaround time<\/em><\/h4>\n

Quando h\u00e1 necessidade de avaliar a performance do processamento de lotes de dados, como em din\u00e2micas de consolida\u00e7\u00e3o, a m\u00e9trica de a ser observada \u00e9 o\u00a0turnaround time<\/em>, ou seja,\u00a0o tempo transcorrido entre o in\u00edcio do processamento do lote e a conclus\u00e3o. Valores para\u00a0turnaround time\u00a0<\/em>podem ser expressos em segundos, minutos, horas e at\u00e9 dias.<\/strong><\/p>\n

N\u00e3o \u00e9 incomum que o neg\u00f3cio relacione o\u00a0turnaround time\u00a0<\/em>com “janelas de processamento”. Ou seja, per\u00edodos regulares, bem-definidos, que precisam ser respeitados.<\/p>\n

Throughput<\/em><\/h4>\n

O throughput\u00a0<\/em>tem rela\u00e7\u00e3o com a quantidade de opera\u00e7\u00f5es de um determinado tipo que um sistema consegue executar em um intervalo de tempo definido.<\/strong><\/p>\n

Para fins de compara\u00e7\u00e3o, quando os lotes de processamento t\u00eam tamanho significativamente vari\u00e1vel, ou em opera\u00e7\u00f5es ass\u00edncronas respondendo uma fila, \u00e9 interessante medir o throughput<\/em>.<\/p>\n

O throughput\u00a0<\/em>tamb\u00e9m \u00e9 ser utilizado como indicativo de quantas requisi\u00e7\u00f5es um sistema consegue atender simultaneamente.<\/p>\n

Rela\u00e7\u00e3o com recursos computacionais<\/h2>\n

H\u00e1 uma rela\u00e7\u00e3o forte entre a performance de um sistema e a capacidade dele de utilizar recursos adequadamente.\u00a0<\/strong><\/p>\nMelhorar a performance de um sistema geralmente implica em: 1) fazer melhor uso dos recursos computacionais ou 2) aumentar a quantidade de recursos computacionais dispon\u00edveis. Obviamente, o aumento de recursos computacionais, embora frequentemente efetivo, implica no incremento direto do custo.\n

\n

A melhor utiliza\u00e7\u00e3o dos recursos computacionais pode acontecer tanto pela utiliza\u00e7\u00e3o de t\u00e9cnicas de otimiza\u00e7\u00e3o de c\u00f3digo quanto pela “substitui\u00e7\u00e3o” do uso de recursos computacionais mais caros (por exemplo, acesso a disco ou a um servidor remoto) por outros mais baratos (mem\u00f3ria RAM).<\/p>\n

Rela\u00e7\u00e3o com filas<\/h2>\nA utiliza\u00e7\u00e3o adequada de recursos computacionais, essencial para a boa performance, depende do entendimento b\u00e1sico da teoria das filas.<\/strong>\n
\n

A maioria dos recursos computacionais – tais como processadores, discos e mecanismos para transfer\u00eancia de dados – \u00a0implementam algum suporte para enfileiramento.<\/strong> Em sistemas Web, por exemplo, requisi\u00e7\u00f5es s\u00e3o enfileiradas sempre que o ritmo de chegada de novas requisi\u00e7\u00f5es (arrival rate –\u00a0<\/em>ex: 5 req\/s) for maior do que o ritmo com que os servidores conseguem atender essas requisi\u00e7\u00f5es (service rate – <\/em>ex: 3 req\/s). O\u00a0traffic\u00a0<\/em>intensity\u00a0<\/i>\u00e9 determinado pela propor\u00e7\u00e3o percentual entre\u00a0arrival rate\u00a0<\/em>e\u00a0service rate<\/em>.<\/p>\n

\"\"<\/p>\n

\r\n

Conten\u00e7\u00e3o e Disponibilidade de Recursos<\/p>\r\n<\/p>\n

Eventualmente, o enfileiramento n\u00e3o \u00e9 “suportado” por um recurso em si, mas acontece em decorr\u00eancia do pr\u00f3prio fluxo de execu\u00e7\u00e3o do c\u00f3digo e concorr\u00eancia.<\/p>\n

Quando um recurso computacional est\u00e1 sob conten\u00e7\u00e3o, ou seja, “bloqueado” atendendo uma demanda, nega novas requisi\u00e7\u00f5es e cabe aos demandantes estabelecer pol\u00edticas de retentativas, estabelecendo uma esp\u00e9cie de enfileiramento.<\/p>\n

Eventualmente, um recurso est\u00e1 indispon\u00edvel, mesmo que inoperante. Nesses casos, tamb\u00e9m caber\u00e1 aos “demandantes” implementar pol\u00edticas de retentativa.<\/p>\n

<\/div>\n

Quando o traffic intensity<\/em> permanece acima de 100% por algum tempo, h\u00e1 um aumento na queue length\u00a0<\/i>(quantidade de demandas esperando por serem atendidas e sendo atendidas em um determinado momento)\u00a0e no\u00a0wait time <\/em>(tempo total na fila).<\/strong> A consequ\u00eancia direta observ\u00e1vel \u00e9 a degrada\u00e7\u00e3o da performance. Al\u00e9m disso, caso demandas expirem (por\u00a0time-out<\/em>) ou o limite de capacidade da fila seja atingido, constata-se satura\u00e7\u00e3o do recurso.<\/p>\n

\"\"<\/p>\n

Idealmente, recursos muito demandados devem, ao longo do tempo, otimizar o service time<\/em>\u00a0<\/strong>(tempo necess\u00e1rio para um recurso atender uma demanda e estar pronto para atender uma pr\u00f3xima) como medida para impactar menos o\u00a0response time <\/em>e, tamb\u00e9m, evitar a satura\u00e7\u00e3o.<\/p>\n

A forma natural de “aliviar” o\u00a0traffic intensity\u00a0<\/em>\u00e9 paralelizando o atendimento das demandas em diversas inst\u00e2ncias do tipo de recurso computacional sendo demandado. Dessa forma, fazendo com que o service rate\u00a0<\/em>supere o\u00a0arrival rate<\/i>.<\/p>\n

Em um sistema saud\u00e1vel, onde demandas n\u00e3o s\u00e3o perdidas e o\u00a0traffic intensity\u00a0<\/em>seja menor que 100%, o\u00a0throughput\u00a0<\/em>ser\u00e1 igual ao\u00a0arrival rate<\/em>.<\/p>\n

Filas causam quedas em “efeito domin\u00f3”<\/h4>\n

A imagem abaixo relata comportamento de um sistema durante um incidente de performance e demonstra uma caracter\u00edstica comum.<\/p>\n

\"\"<\/p>\n

A forma\u00e7\u00e3o de filas, frente a determinados recursos que est\u00e3o indispon\u00edveis, seja por conten\u00e7\u00e3o ou prontid\u00e3o, acaba estressando outras partes de um sistema, notoriamente CPU, gerando quedas em domin\u00f3.<\/p>\n

Utilization Law<\/em><\/h4>\n

A\u00a0utilization law\u00a0<\/em>aponta que a taxa de utiliza\u00e7\u00e3o de um recurso computacional (eventualmente paralelizado) pode ser determinada pelo produto de seu\u00a0throughput\u00a0<\/em>e a m\u00e9dia do\u00a0service time<\/em>.<\/strong> Por exemplo, um recurso que trata 3 requisi\u00e7\u00f5es por segundo, com um service time<\/em> de 100ms tem utiliza\u00e7\u00e3o de 0.3 (ou, 30%).<\/p>\n

Idealmente, a taxa de utiliza\u00e7\u00e3o de um recurso computacional n\u00e3o deve ultrapassar 80%.<\/strong><\/p>\n

T\u00e1ticas modernas para garantir a performance<\/h2>\n

Sistemas com boa performance s\u00e3o aqueles que conseguem, utilizando os recursos computacionais especificados nas restri\u00e7\u00f5es, garantir que o tempo m\u00e9dio de atendimento de demandas, combinando processamentos (service times<\/em>) e esperas (wait times<\/em>), esteja conforme aos objetivos do neg\u00f3cio. Para isso, devem manter a taxa de utiliza\u00e7\u00e3o desses recursos computacionais abaixo de 80% considerando a carga m\u00e1xima prevista.<\/p>\n

A garantia da performance se d\u00e1, ent\u00e3o, pelo controle rigoroso do arrival rate\u00a0<\/em>limitando-o ao especificado no projeto da arquitetura e ao equil\u00edbrio entre o\u00a0service time <\/em>e o\u00a0wait time\u00a0<\/em>para garantir que o\u00a0response time <\/em>de cada recurso\u00a0seja o estipulado. Seja pela otimiza\u00e7\u00e3o do recurso em si, ou pelo\u00a0tuning\u00a0<\/i>do ambiente (determinando n\u00famero de inst\u00e2ncias)<\/p>\n

Embora as medidas para melhoria de performance dependam de especificidades de cada sistema, h\u00e1 um conjunto comum de t\u00e1ticas frequentemente adotadas, sobretudo sob o ponto de vista arquitetural.<\/p>\n

Prioriza\u00e7\u00e3o de\u00a0requests<\/em><\/h4>\n

Todas as\u00a0requests\u00a0<\/em>s\u00e3o importantes. Mas, algumas s\u00e3o mais importantes que as outras.\u00a0<\/strong>Eventualmente, um sistema precisar\u00e1 garantir recursos suficientes para atender uma categoria requisi\u00e7\u00f5es em detrimento de outras.<\/p>\n

Uma medida comum \u00e9 apartar a infraestrutura, dedicando recursos ao atendimento exclusivo de determinadas funcionalidades, separando enfileiramentos. N\u00e3o raro, \u00e9 \u00fatil segmentar tamb\u00e9m o sistema de software em componentes, facilitando processos de deploy<\/em> e manuten\u00e7\u00e3o.<\/p>\n

Outra boa medida para suportar a performance \u00e9 desacoplar requisi\u00e7\u00f5es mais complexas em etapas mais simples, usando, ent\u00e3o,\u00a0abordagens ass\u00edncronas, melhorando a performance percebida com respostas r\u00e1pidas, enquanto parte do processamento fica postergado.<\/p>\n

\r\n

Desacoplando o aceite e a confirma\u00e7\u00e3o de pedidos<\/p>\r\n<\/p>\n

Sistemas de e-commerce\u00a0<\/em>t\u00eam adotado, frequentemente, a separa\u00e7\u00e3o do aceite de um pedido e a confirma\u00e7\u00e3o mediante pagamento.<\/p>\n

O aceite do pedido acontece rapidamente, com \u00f3timo\u00a0response time.\u00a0<\/em>Entretanto, este limita-se a “enfileirar” solicita\u00e7\u00e3o para confirma\u00e7\u00e3o, que \u00e9 um processo com maior custo computacional.<\/p>\n

Aceitar pedidos rapidamente \u00e9 prioridade frente a confirmar pedidos!<\/p>\n

<\/div>\n

Redu\u00e7\u00e3o do overhead\u00a0<\/em>com chamadas remotas<\/h4>\n

Rede e GC s\u00e3o duas fontes comuns de problemas de performance. O agrupamento de servi\u00e7os pode reduzir boa parte da press\u00e3o sobre a rede e um bocado de interven\u00e7\u00f5es dos mecanismos de GC, demandando menos filas e melhorando o service time<\/em>.<\/p>\nComponentes cross-cutting\u00a0<\/em>tamb\u00e9m podem se converter, rapidamente, em gargalos de processamento e devem ser adotados com parcim\u00f4nia. Nada mais infeliz do que ver a performance de um sistema comprometida por mecanismos ing\u00eanuos de logging<\/em>\u00a0e seguran\u00e7a.\n

Ado\u00e7\u00e3o de Rate limiters<\/em><\/h4>\n

A performance de um sistema tem clara rela\u00e7\u00e3o com as restri\u00e7\u00f5es relacionadas aos recursos ao ambiente operacional. O esperado \u00e9 que a performance se mantenha previs\u00edvel enquanto houverem recursos dispon\u00edveis, geralmente, entretanto, ela \u00e9 comprometida quando os limites de recursos s\u00e3o ultrapassados. Por isso, uma das formas de proteger da performance \u00e9 a utiliza\u00e7\u00e3o de\u00a0rate\u00a0limiters.<\/i><\/p>\n

Rate limiters <\/em>podem ser implementados em client-side<\/em>, server-side <\/em>ou em um middleware<\/em>. Implementa\u00e7\u00f5es em client-side <\/em>tem como m\u00e9rito principal a redu\u00e7\u00e3o da press\u00e3o sobre a rede. J\u00e1 implementa\u00e7\u00f5es em server-side <\/em>ou middleware<\/em> s\u00e3o mais \u201cconfi\u00e1veis\u201d, por estarem em ambientes gerenciados, e robustas, visto que permitem regras mais complexas.<\/p>\n

De forma pr\u00e1tica, a estrat\u00e9gia consistem em limitar o\u00a0throughput\u00a0<\/em>como forma de proteger o\u00a0response time<\/em>.<\/strong><\/p>\n

Qualifica\u00e7\u00e3o no consumo de recursos<\/h4>\n

Eventualmente, pode ser importante revisar a implementa\u00e7\u00e3o dos componentes para garantir que recursos estejam sendo utilizados de maneira eficiente. N\u00e3o raro, por exemplo, mem\u00f3ria e CPU s\u00e3o comprometidos desnecessariamente em fun\u00e7\u00e3o de implementa\u00e7\u00f5es ing\u00eanuas, causando aumento do service time<\/em>. Outros bons exemplos s\u00e3o conex\u00f5es com banco de dados e uso impr\u00f3prio do sistema de arquivos que, com frequ\u00eancia, implicam em enfileiramentos.<\/p>\n

Ado\u00e7\u00e3o de programa\u00e7\u00e3o paralela e concorrente<\/h4>\n

Componentes devem aumentar o\u00a0throughput\u00a0<\/em>usando\u00a0scale out\u00a0<\/em>, seja externamente, pela cria\u00e7\u00e3o de mais inst\u00e2ncias, devidamente balanceadas, seja internamente, pela ado\u00e7\u00e3o de\u00a0threads.\u00a0<\/em>Essas medidas reduzem filas de requisi\u00e7\u00f5es.<\/p>\n

Em sistemas modelados para alto n\u00edvel de paralelismo, \u00e9 essencial evitar conten\u00e7\u00e3o de recursos<\/span>. Isso \u00e9 poss\u00edvel tentando criar o m\u00ednimo poss\u00edvel de recursos que possam ser utilizados apenas por um \u00fanico “cliente” por vez.<\/p>\n

Implementa\u00e7\u00e3o de Caching<\/em><\/h4>\n

Caching pode gerar aumento percept\u00edvel de performance!<\/strong> Seja para evitar consultas complexas para o banco de dados ou para armazenar o resultado de computa\u00e7\u00e3o de alto custo,\u00a0caching\u00a0<\/em>\u00e9 uma forma simples de substituir recursos de custo elevado por outros mais baratos, evitando enfileiramentos.<\/p>\n

Aumentar a quantidade de recursos<\/h4>\n

Em muitas condi\u00e7\u00f5es, pode-se amenizar e at\u00e9 resolver problemas de performance utilizando melhor infraestrutura. Entretanto, \u00e9 importante estar atento que “colocar mais lata” (scale up<\/em>) \u00e9 uma solu\u00e7\u00e3o paliativa e raramente sustent\u00e1vel no longo prazo.<\/p>\n

Sumarizando<\/h2>\n

A performance \u00e9 caracter\u00edstica fundamental em qualquer arquitetura. Ela impacta muitos outros atributos de qualidade, sobretudo o custo de um sistema. Para ser bem projetada, depende do alinhamento de expectativas quanto a tempos de processamento e volumes de workload.<\/em><\/p>\n

Melhorias de performance geralmente est\u00e3o associadas com uso mais adequado de recursos computacionais. Quanto melhor o uso, mais performance.\u00a0Um bom indicativo do uso efetivo dos recursos computacionais est\u00e1 na forma\u00e7\u00e3o de filas “saud\u00e1veis” que garantam\u00a0throughput<\/em> equivalente ao\u00a0arrival rate.<\/em><\/p>\n

\/\/ TODO<\/h2>\n

Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, recomendo a voc\u00ea as seguintes reflex\u00f5es:<\/p>\n

    \n
  • Quais s\u00e3o os recursos computacionais que tem causado maiores problemas de performance no sistema em que voc\u00ea est\u00e1 trabalhando agora?<\/li>\n
  • Quais s\u00e3o as taxas de utiliza\u00e7\u00e3o desses recursos?<\/li>\n<\/ul>\n","protected":false},"featured_media":2502,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[58],"apendices":[],"capitulos":[39],"class_list":["post-2561","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-2","capitulos-capitulo-2-3"],"acf":[],"yoast_head":"\nFundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Pela relev\u00e2ncia, as expectativas m\u00ednimas de boa performance devem ser determinadas o mais cedo poss\u00edvel. Depois disso, devem ser consideradas na avalia\u00e7\u00e3o das proposi\u00e7\u00f5es de design arquiteturais\u00a0candidatas.   Definindo performance De maneira superficial, performance, como atributo de qualidade, trata do tempo que um sistema necessita para completar uma determinada categoria de atividades.\u00a0De forma mais precisa, […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-11T20:59:08+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"800\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"19 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/\",\"name\":\"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg\",\"datePublished\":\"2021-07-01T12:43:35+00:00\",\"dateModified\":\"2024-01-11T20:59:08+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg\",\"width\":1200,\"height\":800},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/","og_locale":"pt_BR","og_type":"article","og_title":"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software","og_description":"Pela relev\u00e2ncia, as expectativas m\u00ednimas de boa performance devem ser determinadas o mais cedo poss\u00edvel. Depois disso, devem ser consideradas na avalia\u00e7\u00e3o das proposi\u00e7\u00f5es de design arquiteturais\u00a0candidatas.   Definindo performance De maneira superficial, performance, como atributo de qualidade, trata do tempo que um sistema necessita para completar uma determinada categoria de atividades.\u00a0De forma mais precisa, […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T20:59:08+00:00","og_image":[{"width":1200,"height":800,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"19 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/","name":"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg","datePublished":"2021-07-01T12:43:35+00:00","dateModified":"2024-01-11T20:59:08+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/braden-collum-9HI8UJMSdZA-unsplash.jpg","width":1200,"height":800},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-com-boa-performance-capitulo-12-v-1-03\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Fundamentos para arquitetura de sistemas com boa performance \/ Cap\u00edtulo 12 v 1.03"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/2561","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=2561"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/2502"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=2561"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=2561"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=2561"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=2561"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=2561"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}