Claramente, o AJAX melhora a interface do usuário, mas isso também diminui a carga do servidor? Você pensaria que sim, porque a página inteira não precisará ser exibida a cada vez, mas talvez haja outras variáveis que não estou considerando.
Depende do que você está fazendo e como está fazendo.
Se você estiver substituindo carregamentos de página inteira por solicitações AJAX (ou seja, apenas fazendo chamadas AJAX quando um usuário clicar no que seria um carregamento de página completo), o AJAX diminuirá a carga do servidor porque você (presumivelmente) está executando menos processamento e retornando menos dados.
Por outro lado, se você estiver adicionando o tipo de atualização automática AJAX que controla o servidor a cada poucos segundos, isso pode aumentar a carga dependendo do usuário (pode não aumentar a carga do servidor se o usuário continuar pressionando F5 para atualizar manualmente de qualquer maneira, mas a maioria das pessoas geralmente não faz isso por horas)
Outra otimização do AJAX é carregar apenas mais dados à medida que você rola. Nesse caso, se o usuário não rolar até o fim, isso será um desperdício de processamento.
Obviamente, a implementação pode distorcer os resultados de qualquer maneira, estes são resultados típicos, assumindo implementações razoavelmente boas.
Obviamente, serve para diminuir a carga do servidor. Veja esta apresentação em jsconf'09 - sobre como o Facebook usou o ajax para fazer isso.
O Ajax é assíncrono. comunicação com o servidor - e você pode usá-lo de inúmeras maneiras. As pessoas o usam para carregar JSON simples na Web em tempo real e tudo mais.
Lembre-se - o verdadeiro desafio é o equilíbrio entre cliente e servidor. Esforce-se para fazer com que cada parte faça seu trabalho de forma que o sistema seja otimizado e você obtenha benefícios óbvios de capacidade de resposta percebida e velocidade real.
fonte
Existem outros fatores que você não está considerando - na maioria dos casos, o AJAX aumentará a carga do servidor. Em um cenário típico não-ajax, um usuário carrega uma página grande a cada poucos segundos ou minutos. Sim, essa página única é um pouco mais trabalhosa para o servidor, mas tem bastante tempo entre solicitações para recuperar e atender a outras solicitações. Em um cenário AJAXified, esse carregamento de página única agora é dezenas de pequenas ocorrências, constantemente martelando o servidor e aguardando respostas.
É um pouco como a morte de 1000 cortes - nenhum dos pedidos é tão grande por si só, mas o peso total é um assassino. Especialmente quando você começa a considerar que essas pequenas solicitações são tão caras quanto uma solicitação de página inteira. Nos dois casos, você provavelmente está executando um pipeline de aplicativo da Web inteiro, acessando um banco de dados e aguardando uma resposta enquanto está sentado em uma preciosa conexão HTTP.
Aqui está um exemplo de como o ajax pode ficar feio no servidor rapidamente. Vamos dar um "painel executivo" típico que possui 4 slots para widgets. Digamos que o CEO goste de um relatório de vendas completo no lado direito, de uma lista dos 10 principais ganhadores no meio e de um relatório de preços de ações da empresa à direita. E digamos que faremos isso por meio de solicitações remotas ajax simples. Sem levar em conta folhas de estilo, imagens e outros ativos, sua página agora requer 4 viagens de ida e volta HTTP (página principal, cada um dos relatórios do painel) no servidor. Cada uma delas requer uma pilha da Web completa para executar - você estará acessando bancos de dados e renderizando HTML usando sua estrutura da Web, certo? Agora multiplique o CEO único por 2000 usuários remotos, alguns dos quais com conexões irregulares.
Por outro lado, você pode ter uma única página do lado do servidor que executa e retorna um esqueleto HTML, bem como os dados (incluídos no JSON na página) para renderizar os relatórios. Conexão única e maior, mas menos agressiva no servidor da Web no total, porque você não está lidando com 4 solicitações e ativando 4 pipelines, etc.
fonte
Se você estiver usando o AJAX para substituir o trabalho que o servidor estaria executando, sim, isso melhorará o desempenho do servidor. No entanto, você pode ter projetado as coisas para que o servidor ainda esteja fazendo o mesmo e agora o que está acontecendo com o AJAX está além do que o servidor já estava fazendo.
Principalmente, trata-se de coisas da interface do usuário, pois você não deve fazer mais nada no lado do cliente. Basicamente, tudo o que o servidor estava fazendo para oferecer suporte à interface do usuário (por exemplo, recarregar a página com um layout diferente em resposta à entrada do usuário) faz com JavaScript.
fonte
Se a renderização HTML for uma grande parte do perfil de desempenho do servidor de aplicativos, mover a renderização HTML para o cliente poderá ser uma conquista de desempenho no servidor de aplicativos.
No entanto, se a renderização HTML for uma pequena parte do perfil de desempenho do servidor de aplicativos, mais solicitações normalmente significarão mais viagens pela pilha, mais consultas, mais de tudo no servidor de aplicativos, uma perda de desempenho.
Obviamente, a única maneira de saber em seu caso específico é experimentá-lo.
fonte
Você deve considerar a melhor maneira de implementar sua solução. Uma forma simples e não dinâmica não precisa do ajax, e adicioná-lo pode realmente prejudicar o desempenho. Se o seu problema for péssimo, toda a otimização do ajax no mundo não proporcionará um aumento de desempenho aceitável.
Se seu servidor estiver sobrecarregado, você precisará descobrir o porquê.
Se você estiver recebendo muitos hits, o ajax não resolverá esse problema, você precisará de mais capacidade. Adicionar ajax apenas aumentará o número de solicitações que seu servidor precisa atender.
Se você tiver uma página complicada, verifique se há algo que possa fazer no lado do cliente para reduzir a carga no servidor. Se sua página é dinâmica, mas realmente possui um cache de pacote de dados limitado que, para o ajuste do lado do cliente, pode render melhor.
E algumas vezes o Ajax vai ajudar. Quando você tem formulários complexos com dados dinâmicos, o ajax vence o dia. Mas se suas consultas são complicadas e demoram muito para serem executadas, o ajax ainda não resolverá o seu problema.
fonte