{"id":21151,"date":"2026-08-29T18:19:12","date_gmt":"2026-08-29T16:19:12","guid":{"rendered":"https:\/\/webhosting.de\/nginx-buffering-performance-speicher-proxy\/"},"modified":"2026-08-29T18:19:12","modified_gmt":"2026-08-29T16:19:12","slug":"nginx-desempenho-do-buffer-memoria-proxy","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/nginx-buffering-performance-speicher-proxy\/","title":{"rendered":"Buffering do proxy NGINX: otimizar o desempenho e a mem\u00f3ria"},"content":{"rendered":"<p><strong>Buffering do NGINX<\/strong> determina a rapidez com que o teu proxy recebe respostas do upstream, as armazena em buffer e as envia aos clientes, de forma a poupar mem\u00f3ria. Vou mostrar-te como reduzo a lat\u00eancia, libero as liga\u00e7\u00f5es ao backend antecipadamente e o <strong>Mem\u00f3ria<\/strong> manter isso sob controlo.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Os seguintes aspetos fundamentais ajudam-me a equilibrar de forma adequada o desempenho e os requisitos de mem\u00f3ria.<\/p>\n<ul>\n  <li><strong>Desacoplamento<\/strong> A comunica\u00e7\u00e3o entre o cliente e o backend reduz o tempo de liga\u00e7\u00e3o e aumenta a taxa de transfer\u00eancia.<\/li>\n  <li><strong>Tamanhos dos buffers<\/strong> Selecione \u00abexatamente\u00bb para poupar mem\u00f3ria RAM e evitar opera\u00e7\u00f5es de E\/S no disco.<\/li>\n  <li><strong>buffers ocupados<\/strong> limitar a mem\u00f3ria ativa durante a transmiss\u00e3o.<\/li>\n  <li><strong>Exce\u00e7\u00f5es ao streaming<\/strong> utilizar de forma pr\u00e1tica, sem buffering.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> e os testes de carga garantem a fiabilidade de cada altera\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<h2>Como funciona o armazenamento em buffer do proxy no NGINX<\/h2>\n<p>Eu utilizo o ativo <strong>Armazenamento em buffer<\/strong>, para que o NGINX recolha rapidamente as respostas do upstream e, em seguida, as envie autonomamente aos clientes. Esta dissocia\u00e7\u00e3o reduz a <strong>Lat\u00eancia<\/strong> no back-end, porque a aplica\u00e7\u00e3o fica pronta mais rapidamente e encerra a sua liga\u00e7\u00e3o mais cedo. Enquanto os clientes carregam a uma velocidade vari\u00e1vel, a camada de proxy regula o envio a partir da mem\u00f3ria RAM. Se os dados n\u00e3o couberem na totalidade na RAM, o NGINX pode recorrer temporariamente a ficheiros, conseguindo assim transmitir a resposta de forma fi\u00e1vel. \u00c9 precisamente este comportamento que estabiliza sistemas sob forte carga com muitos <strong>Liga\u00e7\u00f5es<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-proxy-buffering-4082.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando o buffering ativo \u00e9 a melhor op\u00e7\u00e3o<\/h2>\n<p>No caso de aplica\u00e7\u00f5es web cl\u00e1ssicas, APIs com respostas de tamanho m\u00e9dio ou pilhas do WordPress, proporciona <strong>Armazenamento em buffer<\/strong> regularmente os melhores resultados. Liberto o backend mais cedo, enquanto o NGINX se encarrega da transfer\u00eancia restante para redes de clientes frequentemente heterog\u00e9neas. Desta forma, aumenta-se a efic\u00e1cia <strong>Rendimento<\/strong>, especialmente quando h\u00e1 muitas solicita\u00e7\u00f5es a decorrer em simult\u00e2neo. Quem agrupa v\u00e1rios servi\u00e7os atr\u00e1s de um proxy inverso beneficia adicionalmente da distribui\u00e7\u00e3o controlada da carga. Para quest\u00f5es de arquitetura relacionadas com proxies, ajuda-me ter uma vis\u00e3o clara <a href=\"https:\/\/webhosting.de\/pt\/configuracoes-de-proxy-reverso-arquitetura-de-webhosting-proxyhosting\/\">Arquitetura do proxy invertido<\/a>, que separa claramente as fun\u00e7\u00f5es e os limites.<\/p>\n\n<h2>Armazenamento vs. E\/S: o or\u00e7amento adequado<\/h2>\n<p>Equilibro a RAM e os acessos ao disco r\u00edgido, porque os buffers demasiado pequenos causam <strong>E\/S de disco<\/strong> provocar e os buffers demasiado grandes aumentam excessivamente a mem\u00f3ria por liga\u00e7\u00e3o. S\u00e3o determinantes os tamanhos t\u00edpicos das respostas, as solicita\u00e7\u00f5es paralelas e a real <strong>Velocidade do cliente<\/strong>. Idealmente, as respostas pequenas permanecem totalmente na RAM, o que permite ao NGINX transmiti-las sem tempo de espera para destinat\u00e1rios mais lentos. Os corpos de resposta muito grandes podem ser gravados no disco, mas, nesse caso, certifico-me de que utilizo unidades r\u00e1pidas e defino limites para evitar um I\/O excessivo. Este equil\u00edbrio mant\u00e9m a <strong>Tempos de resposta<\/strong> baixa e protege o sistema contra a press\u00e3o no acumulador.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_proxy_meeting_8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vis\u00e3o geral das diretivas e valores de refer\u00eancia<\/h2>\n<p>Defino especificamente os par\u00e2metros principais para controlar a mem\u00f3ria e o comportamento de transmiss\u00e3o. O primeiro buffer para os cabe\u00e7alhos de resposta \u00e9 anexado a <strong>proxy_buffer_size<\/strong>; evita erros de cabe\u00e7alho excessivamente grandes e evita transfer\u00eancias desnecess\u00e1rias para a mem\u00f3ria externa. Distribuo os dados da resposta propriamente ditos atrav\u00e9s de <strong>proxy_buffers<\/strong> como pares de n\u00famero por tamanho, para que os \u00abbodies\u00bb permane\u00e7am totalmente na RAM, na medida do poss\u00edvel. Com <strong>proxy_busy_buffers_size<\/strong> Limito a quantidade de buffers j\u00e1 marcados para envio, a fim de controlar o consumo de mem\u00f3ria ativa. Para determinar os tamanhos t\u00edpicos, baseio-me nas p\u00e1ginas de mem\u00f3ria (4\u201332 KB) e nos perfis de resposta conhecidos das minhas aplica\u00e7\u00f5es.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th><strong>diretiva<\/strong><\/th>\n      <th><strong>Efeito<\/strong><\/th>\n      <th><strong>Valores t\u00edpicos<\/strong><\/th>\n      <th><strong>Notas<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>proxy_buffering<\/td>\n      <td><strong>Ligar\/Desligar<\/strong> da armazenagem tempor\u00e1ria<\/td>\n      <td>ativado (predefini\u00e7\u00e3o)<\/td>\n      <td>Manter ativado para aplica\u00e7\u00f5es web padr\u00e3o; verificar no caso de transmiss\u00f5es em direto<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffer_size<\/td>\n      <td><strong>Buffer de cabe\u00e7alho<\/strong><\/td>\n      <td>8k\u201316k<\/td>\n      <td>Se for demasiado pequeno, d\u00e1 origem a um erro \u201eupstream sent too big header\u201c<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffers<\/td>\n      <td><strong>Amortecedor de carro\u00e7aria<\/strong><\/td>\n      <td>8 de 16k, 16 de 16k<\/td>\n      <td>Associar a par\u00e2metros de resposta e paralelismo<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_busy_buffers_size<\/td>\n      <td><strong>Limite do buffer de envio<\/strong><\/td>\n      <td>32k\u2013128k<\/td>\n      <td>Rendimento suficiente, sem ocupar mem\u00f3ria RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_max_temp_file_size<\/td>\n      <td><strong>Limite de disco<\/strong><\/td>\n      <td>0\u20131 g<\/td>\n      <td>0 desativa os ficheiros tempor\u00e1rios<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_temp_path<\/td>\n      <td><strong>Caminho<\/strong> para ficheiros tempor\u00e1rios<\/td>\n      <td>Caminho do SSD<\/td>\n      <td>Gravar num suporte de dados de alta velocidade<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Perfis orientados para a pr\u00e1tica e exemplos de c\u00e1lculos<\/h2>\n<p>Calculo, de forma aproximada, a necessidade de mem\u00f3ria por liga\u00e7\u00e3o ativa como a soma de <strong>proxy_buffer_size<\/strong> mais (N \u00d7 tamanho do buffer) de proxy_buffers. Com 8 buffers de 16 k mais um cabe\u00e7alho de 16 k, chegamos a cerca de 144 KB por pedido, desde que tudo permane\u00e7a na RAM. Com 5 000 pedidos simult\u00e2neos, calculo, portanto, cerca de 720 MB de ocupa\u00e7\u00e3o exclusiva do buffer, acrescida da sobrecarga do <strong>Processos<\/strong>. \u00c0 medida que o tr\u00e1fego aumenta, a procura tamb\u00e9m aumenta \u2013 por isso, defino as margens de seguran\u00e7a de forma a que as respostas t\u00edpicas se encaixem, sem transformar casos excecionais com corpos de tamanho excessivo em casos normais. Sempre que necess\u00e1rio, limito as exce\u00e7\u00f5es com <strong>Limites de espa\u00e7o em disco<\/strong>, para compensar os picos de consumo de energia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-proxy-optimization-4285.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando desativo o buffering de forma deliberada<\/h2>\n<p>As APIs em tempo real, os eventos enviados pelo servidor ou o v\u00eddeo em direto requerem uma liga\u00e7\u00e3o direta <strong>Rendimento<\/strong> sem armazenamento em buffer adicional. Nesses casos, desativo o proxy_buffering e opto por uma abordagem eficiente <strong>Streaming<\/strong>. O proxy transmite ent\u00e3o os dados imediatamente, o que evita picos de lat\u00eancia nos dados em tempo real, mas mant\u00e9m a liga\u00e7\u00e3o ao backend aberta durante mais tempo. Para estes padr\u00f5es, vale a pena dar uma vista de olhos a <a href=\"https:\/\/webhosting.de\/pt\/http-resposta-streaming-alojamento-desempenho-chunks\/\">Fluxo de resposta<\/a>, incluindo um ajuste adequado dos par\u00e2metros de keepalive e timeout. \u00c9 importante ter sempre em conta o maior consumo de recursos por liga\u00e7\u00e3o e definir limites em conformidade.<\/p>\n\n<h2>Definir os \u00abBusy Buffers\u00bb de forma seletiva<\/h2>\n<p>Com <strong>proxy_busy_buffers_size<\/strong> controlo a quantidade de mem\u00f3ria \u201epronta para envio\u201c que permanece bloqueada em simult\u00e2neo. Se o limite for demasiado baixo, a entrega fica paralisada; se for demasiado alto, os picos de RAM aumentam. Por isso, escolho um valor que corresponda a 1 a 2 vezes o tamanho do buffer, para que o NGINX envie os pacotes rapidamente, sem sobrecarregar demasiado <strong>Mem\u00f3ria<\/strong> para vincular. No caso de clientes lentos, aceito um pouco mais de espa\u00e7o ocupado (busy-space) para reduzir o risco de mudan\u00e7as de contexto frequentes. As redes r\u00e1pidas beneficiam de valores mais reduzidos, que <strong>Requisitos de mem\u00f3ria<\/strong> manter a previsibilidade.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_proxy_buffering_opt_7823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ficheiros tempor\u00e1rios: caminho, tamanho, limites<\/h2>\n<p>Ativo temporariamente <strong>Arquivos<\/strong> apenas quando os \u00abbodies\u00bb s\u00e3o grandes ou quando a mem\u00f3ria RAM \u00e9 escassa. Se os ficheiros tempor\u00e1rios estiverem num SSD, os tempos de resposta mant\u00eam-se aceit\u00e1veis; num disco mais lento, as opera\u00e7\u00f5es de E\/S acabam rapidamente por abrandar todo o <strong>Cadeia de respostas<\/strong>. Com o `proxy_max_temp_file_size`, protejo-me contra uma utiliza\u00e7\u00e3o excessiva de espa\u00e7o; em caso de d\u00favida, defino um limite r\u00edgido. Se houver muitas respostas grandes em paralelo, prevejo espa\u00e7o suficiente e monitorizo a utiliza\u00e7\u00e3o real. Quando h\u00e1 RAM dispon\u00edvel, prefiro buffers maiores e mantenho as partes cr\u00edticas no <strong>Mem\u00f3ria<\/strong>.<\/p>\n\n<h2>Ajuste iterativo, m\u00e9tricas e testes<\/h2>\n<p>Come\u00e7o por ser conservador <strong>Valores<\/strong>, avalie, ajuste e repita o ciclo. As m\u00e9tricas importantes s\u00e3o a lat\u00eancia, a taxa de erros, os picos de RAM, os tempos de espera de E\/S e a utiliza\u00e7\u00e3o da <strong>Trabalhador<\/strong>. Os testes de carga revelam efeitos que passam despercebidos no dia-a-dia, como picos no cabe\u00e7alho causados por cookies ou mega-respostas espor\u00e1dicas. Al\u00e9m disso, ajusto os par\u00e2metros de liga\u00e7\u00e3o e dos workers de forma integrada, por exemplo, <a href=\"https:\/\/webhosting.de\/pt\/nginx-ligacoes-dos-workers-escalabilidade-milhares-de-pedidos-aumento-do-trafego\/\">Worker\u2011Connections<\/a> e Keepalive. Verifico cada altera\u00e7\u00e3o de forma controlada, para poder avaliar o impacto da <strong>Tamp\u00e3o<\/strong> possa atribuir claramente.<\/p>\n\n<h2>Buffering de pedidos e uploads<\/h2>\n<p>Os buffers de resposta s\u00e3o apenas metade da verdade. No lado da entrada, controla-se <strong>proxy_request_buffering<\/strong>, se o NGINX armazena temporariamente os corpos das solicita\u00e7\u00f5es dos clientes (por exemplo, uploads) at\u00e9 estarem completos ou se os transmite imediatamente para o servidor upstream. No caso de APIs que recebem ficheiros de grande dimens\u00e3o, costumo desativar o buffer de pedidos: o servidor upstream recebe o fluxo mais cedo, os tempos de espera diminuem e o NGINX n\u00e3o precisa de armazenar temporariamente corpos de grande dimens\u00e3o no disco. A desvantagem: a liga\u00e7\u00e3o ao servidor upstream permanece aberta por mais tempo e depende mais da velocidade do cliente. No caso de formul\u00e1rios cl\u00e1ssicos ou de pedidos JSON mais pequenos, o buffer de pedidos permanece ativado, para suavizar picos de tr\u00e1fego de forma eficaz e controlar melhor os recursos do servidor. Combino isto com <strong>tamanho_max_do_corpo_do_cliente<\/strong> e uma adequada <strong>client_body_buffer_size<\/strong>, para que os valores at\u00edpicos sejam rejeitados atempadamente ou devidamente amortecidos.<\/p>\n\n<h2>Controlar o Pro-Response: X-Accel-Buffering, Chunked e comprimentos<\/h2>\n<p>Para um ajuste mais preciso, desativo o buffer por resposta atrav\u00e9s de <strong>X-Accel-Buffering<\/strong> Do upstream: o cabe\u00e7alho \u201eX-Accel-Buffering: no\u201c indica ao NGINX para transmitir a resposta diretamente, mesmo que o proxy_buffering esteja ativado globalmente. Utilizo isto para SSE, long polling ou fluxos de diagn\u00f3stico, sem comprometer o ajuste geral. Al\u00e9m disso, certifico-me de que <strong>Comprimento do conte\u00fado<\/strong>, sempre que poss\u00edvel: se o NGINX conhecer o comprimento, planeia os buffers e os ficheiros tempor\u00e1rios de forma mais previs\u00edvel do que se, exclusivamente, <strong>em peda\u00e7os<\/strong> \u00e9 transmitido. Quando o comprimento \u00e9 desconhecido (por exemplo, transmiss\u00f5es em direto), fa\u00e7o uma estimativa conservadora das necessidades e defino limites de E\/S. No caso de p\u00e1ginas de erro ou respostas JSON pequenas, mantenho o buffer desativado, para que a liga\u00e7\u00e3o a montante fique livre rapidamente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_proxy_optimization_7381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compress\u00e3o e protocolos: HTTP\/2\/3 em destaque<\/h2>\n<p>A compress\u00e3o e o armazenamento em buffer devem ser considerados em conjunto. \u00c9 <strong>gzip<\/strong> ou com o Brotli ativo, a compress\u00e3o beneficia da aglomera\u00e7\u00e3o de blocos de dados cont\u00edguos na RAM. Buffers demasiado pequenos podem limitar o d\u00e9bito, porque o compressor tem de mudar de contexto com maior frequ\u00eancia. Por isso, escolho tamanhos de buffer que agrupem bem os segmentos de resposta t\u00edpicos, sem deixar que a RAM fique sobrecarregada por cada liga\u00e7\u00e3o. Em <strong>HTTP\/2<\/strong> e <strong>HTTP\/3<\/strong> Com multiplexa\u00e7\u00e3o e controlo de fluxo, a velocidade de envio varia consoante o fluxo; o buffer estabiliza o lado do backend, enquanto o NGINX sincroniza os fluxos de forma precisa. Importante: em percursos muito sens\u00edveis \u00e0 lat\u00eancia, um \u201etick\u201c a menos de \u00abBusy Space\u00bb pode ajudar a atenuar os efeitos \u00abHead-of-Line\u00bb; em liga\u00e7\u00f5es \u00abrobustas\u00bb com janelas amplas, libero um pouco mais de \u00abBusy Space\u00bb para manter o desempenho m\u00e1ximo de envio.<\/p>\n\n<h2>Cache do proxy e pedidos de intervalo: intera\u00e7\u00e3o com os buffers<\/h2>\n<p>Quem <strong>proxy_cache<\/strong> , o or\u00e7amento para buffers e ficheiros tempor\u00e1rios deve ser coordenado. O NGINX pode armazenar respostas em cache e entreg\u00e1-las aos clientes simultaneamente; buffers de RAM suficientes reduzem o tempo de dura\u00e7\u00e3o da liga\u00e7\u00e3o ao backend, enquanto o acerto no cache desconexiona totalmente as solicita\u00e7\u00f5es posteriores. Limito os ficheiros tempor\u00e1rios de forma mais rigorosa quando a cache est\u00e1 \u00abaquecida\u00bb e permito a sua cria\u00e7\u00e3o enquanto a taxa de acertos est\u00e1 a aumentar. No caso de <strong>Pedidos de gama<\/strong> (Transfer\u00eancias parciais) decido se as sirvo diretamente a partir da cache ou se deixo que sejam primeiro armazenadas na totalidade na mem\u00f3ria tamp\u00e3o. Intervalos frequentes de ficheiros de grande dimens\u00e3o beneficiam de tamanhos de mem\u00f3ria tamp\u00e3o cuidadosamente equilibrados e de respostas segmentadas (opcionalmente), para que nem a E\/S do disco nem a RAM fiquem sobrecarregadas.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-optimierung-server-4573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Clientes lentos: controlar a taxa de transfer\u00eancia sem esgotar a mem\u00f3ria RAM<\/h2>\n<p>Grande parte dos efeitos de buffer s\u00f3 se torna vis\u00edvel com clientes muito lentos. Eu defino <strong>tempo_limite_de_envio<\/strong> e opcionalmente <strong>limit_rate<\/strong>\/<strong>limit_rate_after<\/strong>, para proteger os destinat\u00e1rios hesitantes sem sobrecarregar os workers. Se houver uma forte limita\u00e7\u00e3o de largura de banda, os buffers \u00abBusy\u00bb t\u00eam de aumentar, caso contr\u00e1rio h\u00e1 risco de bloqueios; ao mesmo tempo, controlo o n\u00famero de liga\u00e7\u00f5es paralelas por IP para mitigar padr\u00f5es anormais. Para downloads com uma base de utilizadores mista (telem\u00f3vel, Wi-Fi, fibra \u00f3tica), valores moderados de \u00abBusy\u00bb e buffers \u00abBody\u00bb um pouco mais generosos ajudam, de modo que o NGINX continue a enviar dados de forma linear enquanto o upstream j\u00e1 est\u00e1 ocupado com o pedido seguinte.<\/p>\n\n<h2>Opera\u00e7\u00f5es em contentores e orquestra\u00e7\u00e3o<\/h2>\n<p>Pretendo planear isso em contentores <strong>proxy_temp_path<\/strong> De forma consciente: ou um volume de host r\u00e1pido (SSD) ou um tmpfs, se houver RAM suficiente. Os limites dos contentores (mem\u00f3ria\/CPU\/armazenamento ef\u00e9mero) afetam diretamente as mem\u00f3rias tamp\u00e3o e os ficheiros tempor\u00e1rios; mantenho margem suficiente para picos de carga e regulo o n\u00famero de trabalhadores paralelos e de liga\u00e7\u00f5es em conformidade. \u00c9 importante ter em conta <strong>ulimit -n<\/strong> (descritores de ficheiros) e as quotas do Orchestrator: se a mem\u00f3ria ef\u00e9mera for demasiado pequena, os ficheiros tempor\u00e1rios geram erros; se a RAM for insuficiente, os workers deixam de funcionar devido \u00e0 press\u00e3o OOM. Dimensiono os buffers de forma a que os picos de carga t\u00edpicos se mantenham est\u00e1veis dentro dos limites do contentor e monitorizo continuamente o espa\u00e7o efetivamente ocupado pelos diret\u00f3rios tempor\u00e1rios.<\/p>\n\n<h2>Valores iniciais e modelo para aplica\u00e7\u00f5es web comuns<\/h2>\n<p>Como ponto de partida fi\u00e1vel, utilizo um perfil sucinto, que posteriormente aperfei\u00e7oo com valores de medi\u00e7\u00e3o. Exemplo:<\/p>\n<pre><code>location \/ {\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_buffering on;\n\n    # Buffer de cabe\u00e7alhos e corpo\n    proxy_buffer_size 16k;\n    proxy_buffers 16 16k;\n    proxy_busy_buffers_size 64k;\n\n    # Ficheiros tempor\u00e1rios apenas como recurso de emerg\u00eancia\n    proxy_max_temp_file_size 256m;\n    proxy_temp_path \/var\/cache\/nginx\/proxy_temp 1 2;\n\n    # Tempos de espera e envio\n    proxy_read_timeout 60s;\n    send_timeout 30s;\n\n # Opcional: streaming de upload consoante a API\n    # proxy_request_buffering off;\n}\n<\/code><\/pre>\n<p>Desta forma, as respostas de tamanho m\u00e9dio permanecem na totalidade na RAM, o upstream fica livre rapidamente e os ficheiros tempor\u00e1rios s\u00f3 s\u00e3o utilizados em casos de picos de tr\u00e1fego. Na segunda fase, ajusto o n\u00famero de buffers ao paralelismo efetivo, aumentei ligeiramente o tamanho do \u00abbusy\u00bb em caso de respostas curtas e frequentes, se necess\u00e1rio, e limitei mais rigorosamente os ficheiros tempor\u00e1rios assim que a taxa de acertos na cache come\u00e7ou a dar resultados.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e registo: tornar o impacto vis\u00edvel<\/h2>\n<p>Mido de forma consistente: <strong>$request_time<\/strong> e <strong>$upstream_response_time<\/strong> no registo de acesso, verificar se a liga\u00e7\u00e3o a montante \u00e9 desligada prematuramente. <strong>$bytes_enviados<\/strong> e <strong>$body_bytes_sent<\/strong> ajudam a ajustar os perfis de buffer ao tr\u00e1fego real. Se a diferen\u00e7a entre o tempo de upstream e a dura\u00e7\u00e3o total diminuir, os buffers funcionam corretamente. Estabele\u00e7o uma correla\u00e7\u00e3o entre isto e os picos de RAM, a espera de E\/S e a ocupa\u00e7\u00e3o do <strong>proxy_temp_path<\/strong>. Nos testes de stress, var\u00edo as velocidades dos clientes, os tamanhos das respostas e a carga dos cabe\u00e7alhos (por exemplo, cookies), para identificar casos extremos. S\u00f3 quando as m\u00e9tricas de registo e os valores do sistema se mant\u00eam est\u00e1veis dentro do meu intervalo-alvo \u00e9 que congelo o perfil e documento os limites, bem como os percursos de escalonamento (buffers maiores, outra pol\u00edtica de tempo de espera, r\u00e9plicas adicionais).<\/p>\n\n<h2>Erros frequentes e respetivas solu\u00e7\u00f5es<\/h2>\n<p>A mensagem \u201e<strong>O cabe\u00e7alho enviado a montante \u00e9 demasiado grande<\/strong>\u201cResolvo o problema aumentando o valor de `proxy_buffer_size` e, se necess\u00e1rio, aumentando o tamanho dos `proxy_buffers`. Se ocorrerem tempos de espera em dispositivos finais lentos, aumentei moderadamente os tempos de espera de envio e deixo um pouco de margem nos buffers ocupados. Se o diret\u00f3rio tempor\u00e1rio ficar cheio, reduzo o tamanho m\u00e1ximo ou aumente os buffers de RAM, dependendo da rela\u00e7\u00e3o custo-benef\u00edcio. Se a entrega apresentar atrasos, verifico se h\u00e1 estrangulamentos de E\/S, satura\u00e7\u00e3o da CPU e a distribui\u00e7\u00e3o dos <strong>Tamp\u00e3o<\/strong>. Quando se trata de situa\u00e7\u00f5es de escassez, abordo-as sempre em primeiro lugar com base em valores medidos, e n\u00e3o com aumentos generalizados do dobro.<\/p>\n\n<h2>Conclus\u00e3o: Os meus pontos-chave para o armazenamento em buffer do proxy NGINX<\/h2>\n<p>Come\u00e7o por definir os t\u00edpicos <strong>Tamanhos das respostas<\/strong>, picos de carga e perfis de cliente, antes mesmo de ajustar os buffers. Depois, defino um buffer de cabe\u00e7alho suficientemente grande para evitar erros desnecess\u00e1rios. Dimensiono os buffers de corpo de forma a que as respostas habituais permane\u00e7am na RAM e apenas as exce\u00e7\u00f5es sejam <strong>Disco<\/strong> caem. Configuro os \u00abBusy Buffers\u00bb de forma a que as transfer\u00eancias decorram de maneira fluida, sem desperdi\u00e7ar mem\u00f3ria. Por fim, verifico tudo atrav\u00e9s de testes de carga e monitoriza\u00e7\u00e3o, at\u00e9 que a lat\u00eancia, o d\u00e9bito e os requisitos de mem\u00f3ria se situem num n\u00edvel fi\u00e1vel <strong>Janelas<\/strong> mentira.<\/p>","protected":false},"excerpt":{"rendered":"<p>O buffer do proxy NGINX explicado: como otimizar o desempenho, o consumo de mem\u00f3ria e a configura\u00e7\u00e3o do proxy reverso na pr\u00e1tica.<\/p>","protected":false},"author":1,"featured_media":21144,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21151","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"139","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"NGINX Buffering","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21144","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21151","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21151"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21151\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21144"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}