Melhorando o desempenho de aplicações em JSF

Transcrição

1 capa_ Melhorando o desempenho de aplicações em JSF Aumente a escalabilidade através de configurações e refatorações efetivas Adriano Castro adrianocastro189@gmail.com é formado em Ciência da Computação pela Universidade Federal de Juiz de Fora e atua como desenvolvedor Java pela TO Brasil. Além disso é criador e desenvolvedor dos projetos Checando.com.br e tostring ( / 12

2 Aplicações JSF possuem escalabilidade ameaçada quando utilizado sem o conhecimento básico da especificação do framework ou da implementação escolhida. Muitas vezes não sabemos como proceder diante de um cenário com recursos limitados e a performance da aplicação acaba sendo prejudicada. Este artigo irá mostrar como planejar e refatorar sistemas em JSF de acordo com a disponibilidade de recursos em ambientes de produção. que motiva a escolha do JSF como arquitetura de O referência para uma aplicação Web baseada em Java? Talvez seja a facilidade de desenvolver interfaces gráficas complexas; talvez seja sua capacidade de manter as camadas de modelo, controle e visualização bem separadas e injetáveis por containers, ou até mesmo sua característica orientada a eventos que permite o desenvolvimento de aplicações tão ricas quanto uma aplicação desktop. Mas o que torna o JSF tão robusto pode também o fazer pouco escalável. Segundo Eelco Klaver, na apresentação citada como referência para este artigo, enquanto aplicações web tradicionais servem a centenas de usuários, aplicações JSF podem não suportar 50 usuários. Nesse cenário, os maiores gargalos são o tamanho da sessão, o consumo de CPU e o uso de banda. Mas por que a utilização do JSF é tão custosa? Cada requisição feita a uma aplicação JSF faz com que o container instancie um objeto de contexto responsável por executar o fluxo de fases do framework. Esse objeto não é thread-safe, isto é, ele atende apenas a uma requisição por vez. Dessa forma, cada requisição, por mais que seja um simples post via AJAX, resulta em um grande consumo de processamento e memória no ciclo de vida desse objeto. Detalhado o problema é possível então modelar uma estratégia de otimização que visará diminuir o tempo e o consumo de recursos entre cada requisição e resposta de uma aplicação JSF. Tal estratégia será granularizada nos tópicos seguintes. É importante ressaltar que as decisões de implementação variam de acordo com as peculiaridades de cada sistema. Dessa forma, as estratégias de otimização nem sempre suprem completamente tais peculiaridades. Por isso é muito importante analisar o perfil da aplicação antes de decidir como arquitetá-la ou refatorá-la. Nos primeiros tópicos serão abordados o consumo de memória e processamento pelo JSF para manter o estado dos componentes visuais presentes na view. Você verá como é possível gerenciar a ordem de prioridade de cada um desses recursos em detrimento do outro levando-se em conta os recursos disponíveis no servidor de aplicações utilizado. Você verá também como fazer uso dos conversores e validadores presentes no JSF de uma forma menos impactante e, principalmente, o quanto é importante dizer ao JSF quando utilizá-los. Por fim serão apresentados parâmetros de configuração que podem contribuir em melhorias de desempenho. Espera-se, entretanto, que o leitor tenha um conhecimento mínimo da especificação do Java Server Faces ou que pelo menos esteja familiarizado com seu uso. De qualquer forma, no início de cada tópico será dada uma breve introdução a respeito do que motivou tal otimização. Saving State Method O saving state method (método de armazenamento de estado) foi escolhido para iniciar o processo de otimização de uma aplicação JSF. E não foi por acaso. Ele diz respeito a uma decisão arquitetural que refletirá impactando a aplicação por completo 13 \

3 pois refere-se a um recurso muito poderoso do JSF: a manutenção do estado de seus componentes que pode ser configurada através do parâmetro javax.faces.state_saving_method. Sabe-se que as requisições web são stateless (sem persistência de estado) ao contrário do JSF, que mantém o estado dos componentes entre as requisições. Para controlar os estados de todos os componentes presentes na view, uma árvore de estados gerenciada pelo framework deve ser armazenada em algum local de forma a ser carregada e atualizada. O JSF permite que o desenvolvedor decida onde mantê-la. Para dar suporte a essa escolha o JSF disponibiliza o parâmetro de contexto javax.faces.state_sa- ViNG METHOD que deve ser inserido no arquivo web. xml da aplicação. Os valores aceitos para este parâmetro são: server - valor padrão quando o parâmetro for omitido - e client, como exemplifica a Listagem 1. O que distingue as duas opções pode parecer simples: o método server armazena os estados no servidor enquanto o client os armazena no lado cliente da aplicação. As implicações em termos de consumo, entretanto, diferem muito. O método client faz com que o estado da árvore de componentes seja armazenado no cliente. Em outras palavras, o código da view que será gerado (HTML, por exemplo) passa a conter uma String enorme, codificada em Base64 e que representa o estado dos componentes que fazem parte dela. Com essa String armazenada no cliente, o servidor passa a manter menos informações na sessão do usuário, resultando em economia de memória em detrimento de CPU, já que a cada requisição o estado deve ser decodificado, remontado e codificado novamente para a resposta. Além disso, uma quantidade maior de informações trafega. isto é, abre-se mão de processamento e banda em prol de um menor consumo de memória. A figura 1 demonstra como essa grande String codificada é armazenada no código-fonte HTML de um cadastro simples de usuários com pouco menos de 10 campos. Neste exemplo, o valor do campo hidden cujo id é javax.faces.viewstate é enviado a cada requisição e decodificado para que o JSF possa restaurar o estado do formulário. Listagem 1. Exemplo de configuração do parâmetro. <context-param> <param-name> javax.faces.state_saving_method </param-name> <param-value>client</param-value> </context-param> A performance apresentada por uma aplicação em um determinado ambiente está muito relacionada à quantidade de recursos de processamento, memória e banda do hospedeiro. É necessário ter conhecimento da disponibilidade destes recursos, pois esta informação será relevante na escolha do método. Uma escolha malfeita resultará em desperdício de recursos e, consequentemente, na perda de performance. O processo de otimização se resume em colocar na balança o quanto de recurso se tem disponível e o consumo resultante de acordo com cada opção. O método de armazenamento server faz com que o JSF armazene o estado dos componentes no servidor, resultando em um maior consumo de memória nesse lado e um consumo menor no lado do cliente. Com esta opção, o consumo de banda é menor, já que não há necessidade de armazenar informações a respeito do estado dos componentes já que menos informações trafegam. Para aplicações que fazem uso intenso de ajax, onde o número de requisições é alto, percebe-se uma melhoria no tempo de resposta quando se tem limitações de tráfego por parte do servidor ou quando a conexão do cliente não é das melhores. Figura 1. Armazenamento do estado dos componentes no HTML gerado. Por outro lado, é muito importante analisar o que cada decisão implica em termos de usabilidade e se as consequências de uma opção não interferem no produto final. Por exemplo, a opção server prejudica a funcionalidade de navegação entre históricos do browser, enquanto o método client fornece pouca segurança, já que expõe o estado dos componentes no código gerado ao cliente. Além dessas, existem outras implicações que devem ser levadas em conta que não serão listadas aqui de forma a focar apenas na otimização de aplicações em JSF. Não existe, assim, uma opção melhor que a outra. Existe uma opção que melhor se adapta às necessidades de cada aplicação e essa análise deve ser feita por alguém que, além de conhecê-la por completo também conhece quem a hospedará. Por esse motivo, se a escolha acabar sendo a opção que apresenta a pior performance, deve-se pensar em aumentar a quantidade de recursos disponíveis no hospedeiro. / 14

4 Escopo dos managed beans Todo managed bean gerenciável pelo JSF deve possuir um escopo, ou pelo menos a indicação explícita de que não pertence a escopo algum. Este escopo determina o local onde o bean ficará armazenado e, principalmente, o tempo de vida de suas instâncias. Os escopos disponíveis pelo JSF são Request, View, Session, Application, Custom e None. A indicação do escopo ao bean pode ser feita tanto no faces-config.xml quanto por annotations na própria classe. De uma forma bem resumida - apontando apenas o que interessa para analisá-los em termos de desempenho e consumo de recursos - managed beans com escopo de Request são instanciados pelo JSF no início de uma requisição e morrem após o response ser enviado. Managed beans cujo escopo é o de View nascem quando o JSF cria uma nova view, permanecem vivos enquanto requisições post são realizadas para a mesma página e morrem quando outra view é criada a partir do modelo de navegação do JSF (vide JSF Navigation Model). O escopo de um managed bean, quando omitido, é o Request. É comum não informar o escopo de um bean, muitas vezes por desconhecimento, e isso faz com que todos os managed beans da aplicação sejam criados e eliminados durante uma única requisição. isso resulta em uma carga de processamento muito grande, pois beans que realizam instanciações aninhadas ou que acessam a base de dados em sua inicialização para carregar os dependentes são inicializados a todo o tempo, inclusive em requisições para atualizações parciais, como as em ajax. Outro equívoco cometido com frequência é a utilização do escopo View em todos os managed beans por manter os valores dos objetos de modelo vivos entre requisições para a mesma página ou por que eles são mais compatíveis com componentes de terceiros que envolvem paginação e estados mais complexos. Um bean cujo escopo é View pode ficar alocado na memória do servidor durante um longo período de tempo. Para grandes beans e muitos usuários o consumo de memória se torna absurdo. Managed beans cujo escopo é Session permanecem vivos enquanto a sessão do usuário estiver ativa e o escopo Application mantém os beans vivos enquanto a aplicação estiver viva. Por fim, o escopo Custom será detalhado no final deste tópico e o None significa que o bean tem seu escopo determinado pelo bean que o mantém. Selecionar bem o escopo dos managed beans de uma aplicação é crucial para seu desempenho. Quanto menos deles houver associados à sessão ou à aplicação melhor. Escolha com cuidado o escopo de seus beans Beans cujo escopo é Application, Session ou View podem ocupar significantemente grande parte da memória em ambientes acessados por grandes quantidades de usuários e por isso devem ser evitados. É recomendável guardar nestes beans somente os componentes ou as informações que realmente necessitam ser persistidas entre as requisições. Há quem critique o uso de mais de um bean por view, mas, em determinados casos, isso pode ser necessário, já que um dos beans pode ser usado apenas para os objetos que realmente precisam sobreviver a estas requisições e o outro para objetos que podem ser descartados após a resposta. Ao mesmo tempo é recomendável evitar que beans responsáveis por consultas ao banco tenham escopo de request quando a página possuir renderizações parciais. Requisições realizadas dentro desta página com o objetivo de renderizar porções da mesma, como, por exemplo, as feitas em ajax para popular combos ou preencher componentes, resultarão em uma nova instanciação dos beans e, consequentemente, uma nova consulta ao banco. Dessa forma, é necessário analisar, bean por bean, quais deles merecem ou não ter um escopo mais custoso, em termos de memória e processamento. Utilize o CustomScope com mais frequência Este subtópico foi baseado no livro Java Server Faces The Complete Reference, escrito por um dos desenvolvedores da especificação do JSF, Ed Burns. O escopo Request é muito utilizado em aplicações JSF por ser uma ponte de passagem de dados entre requisições e, principalmente, por ter um tempo de vida curto. Este escopo, entretanto, faz parte da especificação de Servlets e, por esse motivo, atende a seus contratos. Entre os termos deste contrato incluem-se as notificações de listeners que podem ou não ser registrados. independentemente de nenhum, um, ou até mais de um listener é possível perceber impactos na performance de cada requisição. Para dar base à otimização desses beans, voltamos à definição de escopos, onde apresentamos o CustomScope. Ele permite ao desenvolvedor definir, criar ou utilizar escopos personalizados ou fornecidos à parte. Tal escopo recebe como parâmetro uma EL que deve apontar para um objeto que implementa java.util.map. Dessa forma o tempo de vida do bean passará a depender do tempo de vida do mapa utilizado. Utilizar o CustomScoped com um escopo criado e gerenciado por você é uma tarefa trabalhosa e pode trazer ganhos ao desempenho se bem-feito, mas não 15 \

5 é a criação de escopo que será sugerida aqui, e sim a utilização de um escopo introduzido na versão 2.0 do JSF cujo tempo de vida é sutilmente reduzido e não tem seu desempenho impactado pelos motivos citados anteriormente. Este novo escopo é chamado de FacesContext attributes scope e tem o tempo de vida definido pelo tempo de vida da invocação do FacesServlet. Seu acesso é realizado através de uma EL como no exemplo abaixo: #{facescontext.attributes Recomenda-se, a partir daí, usar o CustomScoped apontando para este mapa de atributos do FacesContext como alternativa ao RequestScoped de forma a ter ganhos de desempenho para beans cujo objetivo foi citado no início = #{facescontext.attributes ) public class UmBeanQualquer { Otimizando as validações e conversões Converters e validators - conversores e validadores, respectivamente - são dois recursos muito poderosos do JSF e estão presentes nas primeiras fases do ciclo de vida de uma requisição. É através deles que os valores preenchidos nos clientes são convertidos de String para os tipos do modelo da aplicação e validados de acordo com as regras de negócio de cada um. Mais detalhes a respeito do ciclo de vida serão vistos no próximo tópico. É recomendável sempre utilizar os conversores e validadores presentes na implementação do JSF utilizada, pois eles atendem a maioria dos casos e já são otimizados. De qualquer forma, o JSF fornece interfaces que permitem aos desenvolvedores criar e reutilizar implementações próprias destes recursos. Quando componentes personalizados por demandas peculiares de uma aplicação são construídos é quase certo que eles acompanharão um conversor e, pelo menos, um validador, também personalizados. A forma mais comum de se implementar um conversor é criando uma classe que implementa a interface javax.faces.convert.converter e configurando o JSF através de entradas no faces-config.xml ou através de anotações para permitir ao container injetar instâncias destes recursos na aplicação. Estes dois passos já bastam, mas as boas práticas na criação de conversores e validadores serão omitidas por não fazer parte do escopo deste artigo. As Listagens 2 e 3 contêm um conversor e como eles são utilizados, respectivamente. Para isso será adotado um exemplo de cadastro de veículos. Listagem 2. Criação do conversor. package cadastroplacas; import javax.faces.bean.applicationscoped; import javax.faces.bean.managedbean; import javax.faces.component.uicomponent; import javax.faces.context.facescontext; import javax.faces.convert.converter; import = cadastroplacas. ConversorPlaca ) public class ConversorPlaca implements Converter { public ConversorPlaca() { System.out.println( Instância de ConversorPlaca criada. public Object getasobject(facescontext context, UIComponent component, String value) { return new Placa(value.substring(0, 3), public String getasstring(facescontext context, UIComponent component, Object value) { Placa placa = (Placa) value; return placa.getprefixo().touppercase() placa.getnumero(); Listagem 3. Utilização do conversor de placas. <h:body> <h:form> <h:panelgrid columns= 2 > <h:outputlabel value= Placa: /> <h:inputtext value= #{cadastroplacabean.placa converter= cadastroplacas.conversorplaca /> <h:outputtext value= /> <h:commandbutton value= Cadastrar /> </h:panelgrid> </h:form> </h:body> Foram omitidos também os outros campos que possivelmente seriam relevantes a um cadastro de veículos, assim como o bean de cadastro de placas, pois não queremos entrar no mérito da funcionalidade, mas sim no consumo de recursos dos conversores. / 16

6 Para se ter uma ideia dos efeitos causados na aplicação, colocamos uma chamada à saída padrão do Java no construtor de ConversorPlaca, pois iremos focar este tópico na instanciação desnecessária de conversores para casos onde eles são consumidos da maneira convencional. No momento em que a tela é carregada, assim como em cada evento disparado pelo botão Cadastrar, uma nova instância de ConversorPlaca é criada. isso acontece, pois no início o JSF busca o objeto do modelo para convertê-lo e exibi-lo no campo. Já durante o evento do botão, o valor do campo preenchido é convertido para ser validado e atualizado no modelo. É possível perceber esse comportamento pela escrita da frase instância de ConversorPlaca criada inúmeras vezes na saída padrão do Java enquanto se utiliza o cadastro - estamos utilizando a saída padrão apenas para simplificar o código, mas recomenda-se apontar sempre para o log da aplicação em questão. Sabe-se que a instanciação desnecessária e descontrolada de objetos é um fator que compromete o desempenho. No exemplo acima estamos falando apenas de um conversor e duas requisições, mas em ambientes reais pode haver uma grande quantidade deles em conjunto com um número maior de usuários e eventos. Cada instância criada deste conversor será descartada ao final da requisição e o coletor de lixo provavelmente cuidará dela, por isso não se preocupe, você não vai ter problemas de estouro de memória por culpa dos conversores de sua aplicação. Entretanto por que não reduzir essa quantidade de instanciações já que é possível? Você poupará a JVM de um trabalho desnecessário com apenas algumas modificações. Os beans cujo escopo é Application já foram descritos em tópicos anteriores e este escopo será utilizado para manter apenas uma instância do conversor durante o tempo de vida da aplicação. Para isso, o conversor será tratado a partir de agora como um managed bean e o JSF cuidará de sua instanciação antes de começar a atender às requisições. A única alteração necessária na classe do conversor está presente na Listagem 4. Listagem 4. Alterações no = cadastroplacas. ConversorPlaca = public class ConversorPlaca implements Converter { A partir de agora, sempre que a aplicação iniciar, uma instância de ConversorPlaca será criada e mantida até que a aplicação não esteja mais em execução. A Listagem 5 mostra como o componente deve consumir essa única instância do conversor. Listagem 5. Como a tela deverá passar a consumir o componente. <h:outputlabel value= Placa: /> <h:inputtext value= #{cadastroplacabean.placa converter= #{conversorplaca /> Com essa simples alteração economiza-se memória, já que menos objetos do conversor serão instanciados para cada requisição, além de evitar processamento desnecessário. Uso de immediate nos campos e eventos Como dito no início do artigo, uma de nossas metas será reduzir o tempo gasto em um request. O JSF processa cada requisição em um fluxo de seis fases. Explicar detalhadamente cada fase não faz parte do escopo do artigo, mas um entendimento superficial é necessário para otimizar as requisições que se aplicam a este tópico. Restore View é a primeira das seis fases. É aqui que o JSF obtém ou cria a view em que o usuário se encontra. Esta view é mantida através de componentes em estrutura de árvore. Logo após executada, se a requisição se trata de um post, as próximas fases serão executadas, caso contrário ele irá diretamente para a última delas. Considerando então uma requisição post, a segunda fase, Apply Request Values, recupera os valores preenchidos no formulário submetido em formato de String e que serão convertidos nos tipos corretos de acordo com a associação dos campos com os objetos em seu managed bean. Em seguida, a fase Process Validation realiza as validações dos campos e se todos os campos forem válidos, Update Model Values aplica os valores no modelo. Por fim invoke Application executa os eventos associados à requisição e Render Response atualiza a view a ser retornada para o usuário. Cada campo presente em um formulário passa por todas estas fases e não é possível ignorá-las. É possível, entretanto, aperfeiçoar parte do processo. Existem muitos casos onde um formulário possui procedimentos internos que o modifica à medida que o usuário o preenche. Para facilitar o entendimento imagine um exemplo de cadastro de usuários onde, na seção de endereço, há uma caixa de seleção de cidade cujo preenchimento depende do que foi selecionado previamente na caixa de seleção de estado. Este campo permanece vazio e é preenchido no momento em que um estado é selecionado. O evento que pre- 17 \

7 enche a caixa de cidades pode ser executado por uma requisição em ajax ou não, mas o que importa é que ela será executada seguindo o fluxo do JSF. Considere agora que esse formulário contém não somente os campos de UF e cidade, mas todos os campos relevantes de um cadastro de usuário completo como nome, data de nascimento etc. Qualquer evento no campo UF enviará todos os valores preenchidos nos campos e as fases do JSF se aplicarão a todos eles. Nestes casos há um desperdício de recursos, pois o formulário inteiro está sendo processado pelo fluxo do JSF quando o que importa ali é obter a UF selecionada e carregar uma lista de cidades para preencher o campo. A Listagem 6 ilustra esse exemplo. Listagem 6. Exemplo de uma tela de cadastro de usuários. <h:panelgrid columns= 2 > <h:outputlabel value= Nome: /> <h:inputtext value= #{flash.nome /> <h:outputlabel value= Data de nascimento: /> <h:inputtext value= #{flash.datanascimento /> <h:outputlabel value= Logradouro: /> <h:inputtext value= #{flash.logradouro /> <h:outputlabel value= Número: /> <h:inputtext value= #{flash.numero /> <h:outputlabel value= Complemento: /> <h:inputtext value= #{flash.complemento /> <h:outputlabel value= UF: /> <h:selectonemenu value= #{flash.estado onchange= this.form.submit() valuechangelistener= #{cidades.atualizarlistacidades > <f:selectitems itemlabel= #{estado itemvalue= #{estado value= #{cidades.estados var= estado /> </h:selectonemenu> <h:outputlabel value= Cidade: /> <h:selectonemenu value= #{flash.cidade > <f:selectitems itemlabel= #{cidade itemvalue= #{cidade value= #{cidades.cidades var= cidade /> </h:selectonemenu> <h:outputtext value= /> <h:commandbutton action= sucesso value= Cadastrar /> </h:panelgrid> Repare que foram omitidos muitos outros campos relevantes ao cadastro de usuários de forma a facilitar o entendimento das alterações que serão realizadas. Outro detalhe importante é a ausência de um managed bean para o usuário. Foi utilizado um tipo especial de memória chamada Flash em JSF que serve apenas como uma ponte para passagem de valores através de uma requisição. Um bean de cidades foi criado com a simples tarefa de retornar uma lista de acordo com a UF selecionada, mas ele será omitido, pois depende muito de como as camadas de negócio são implementadas em cada aplicação. O exemplo da Listagem 6 é uma prática ruim em JSF, pois, como dito anteriormente, há o desperdício de recursos na conversão e validação de todos os campos no evento disparado pela lista de estados. Dessa forma, para aperfeiçoar esta requisição precisaremos dizer ao JSF que eventos gerados a partir da lista de estados se tratam apenas de atualizações parciais em nossa view e não representam a ação de cadastro. É possível alcançar esse comportamento a partir do atributo immediate. Este atributo garante ao componente que sua conversão e validação, assim como os eventos dos botões, se darão na primeira fase Apply Request Values. Com isso, percorre-se um atalho no fluxo de fases somente com as informações que interessam para aquela requisição. E este atalho reduz o tempo do ciclo de vida da requisição, dando lugar à próxima requisição mais rapidamente (lembre-se que cada requisição é executada unitariamente pelo JSF, pois o Faces Context não é thread-safe). Voltando ao exemplo da Listagem 6, iremos adicionar o atributo immediate= true no campo que irá disparar o evento e adicionar um novo botão, também com este atributo, que irá disparar o request pegando o atalho discutido anteriormente. Não iremos adicionar o atributo no botão Cadastrar, pois não queremos que o formulário inteiro tenha este comportamento. Vamos otimizar somente o que dá pra otimizar aqui. Por fim alteraremos o evento onchange para chamar o novo botão criado. A Listagem 7 mostra como ficará o código. Listagem 7 Aplicação do atributo immediate= true no cadastro <h:panelgrid columns= 2 > <h:outputlabel value= Nome: /> <h:inputtext required= true value= #{flash.nome /> <h:outputlabel value= Data de nascimento: /> <h:inputtext value= #{flash.datanascimento /> <h:outputlabel value= Logradouro: /> <h:inputtext value= #{flash.logradouro /> <h:outputlabel value= Número: /> <h:inputtext value= #{flash.numero /> <h:outputlabel value= Complemento: /> <h:inputtext value= #{flash.complemento /> / 18

8 <h:outputlabel value= UF: /> <h:selectonemenu immediate= true value= #{flash.estado onchange= document. getelementbyid( form:atualizarcidades ).click() valuechangelistener= #{cidades.atualizarlistacidades > <f:selectitems itemlabel= #{estado itemvalue= #{estado value= #{cidades.estados var= estado /> </h:selectonemenu> <h:outputlabel value= Cidade: /> <h:selectonemenu value= #{flash.cidade > <f:selectitems itemlabel= #{cidade itemvalue= #{cidade value= #{cidades.cidades var= cidade /> </h:selectonemenu> <h:outputtext value= /> <h:commandbutton action= sucesso value= Cadastrar /> </h:panelgrid> <h:commandbutton style= visibility: hidden id= atualizarcidades value= atualizarcidades immediate= true /> Para grandes formulários é possível notar uma diferença significativa - em questão de milissegundos - nos eventos disparados em ajax que passam a usar o immediate como forma de não submetê-los por completo ao fluxo de fases do JSF. É necessário lembrar que este recurso não se restringe a requisições em ajax, mas também para requisições convencionais que envolvam o refresh da página por completo. Recomenda-se que, para aplicações em processo de otimização, todos os formulários sejam revistos e, sempre que houver atualizações parciais em sua estrutura, o atributo immediate= true seja utilizado nos campos e em botões com a finalidade única de realizar a requisição do evento. As requisições terminarão mais rapidamente e o JSF irá suportar uma quantidade maior delas em um dado espaço de tempo. Configurações adicionais A especificação do JSF traz uma série de parâmetros de inicialização que permitem aos desenvolvedores configurá-la. Quanto maior for o conhecimento desses parâmetros e do perfil da aplicação maior serão a qualidade e o desempenho do produto gerado. Além desses parâmetros há também os parâmetros específicos de cada implementação do JSF. Cada implementação pode ainda fornecer valores padrões para estes parâmetros. Descrever cada um dos parâmetros tornaria este artigo enorme, por isso serão fornecidos dois exemplos de como é possível obter melhores resultados em uma aplicação a partir de pré-configurações. Estas configurações deverão ser aplicadas no web.xml de sua aplicação. Project Stage O JSF 2.0 introduziu um parâmetro responsável por manter referência à fase atual da aplicação representado pelo enum javax.faces.application. ProjectStage. Os valores de fase permitidos são Development, UnitTest, SystemTest e Production. Para não fugir ao escopo deste artigo não serão detalhados os comportamentos da aplicação de acordo com cada fase disponível. Basta saber que o JSF consome mais recursos quando a aplicação está em fase de desenvolvimento, pois ele trabalhará focado em fornecer aos desenvolvedores facilidades como mensagens de erro mais detalhadas e possibilidades de diagnóstico da aplicação maximizadas, tudo isso a custo de processamento e memória. Um detalhe que passa despercebido é que algumas ides adicionam, por conta própria, o valor Development para este parâmetro no momento da criação de novos projetos. Muitas vezes este valor é mantido nos ambientes de produção após a publicação por descuido ou por desconhecimento do parâmetro, o que é prejudicial ao desempenho. Veja o exemplo da Listagem 8 que contém um trecho do web.xml gerado automaticamente pelo NetBeans quando da criação de uma nova aplicação web: Listagem 8. Exemplo de configuração automática do NetBeans. <context-param> <param-name>javax.faces.project_stage </param-name> <param-value>development</param-value> </context-param> De acordo com a especificação do JSF, o valor default de PROJECT_STAGE é Production, por isso remova esta tag de seu web.xml antes de cada publicação. Mantenha este valor somente em seu ambiente local de desenvolvimento. Facelets Refresh Period Durante a fase de desenvolvimento de uma aplicação, por questões de produtividade, é desejável que as alterações nos arquivos físicos das páginas sejam compiladas em tempo de execução para que elas fiquem disponíveis no browser sem que haja a necessidade de um restart no servidor. E para que isso seja possível o Facelets verifica se há alterações nestas páginas periodicamente. Essa varredura consome re- 19 \

9 Conheça mais sua implementação Fabricantes de implementações da especificação JSF geralmente fornecem parâmetros de inicialização adicionais que permitem ajustar ainda mais sua aplicação. Por isso não se limite a conhecer somente a especificação do JSF, mas também a documentação da implementação utilizada. Até a data desta publicação, o The Apache Software Foundation fornecia em seu site oficial ( myfaces.apache.org) uma seção chamada Web Context Parameters contendo a lista de parâmetros presentes no JSF e os valores padrões adotados pelo MyFaces - uma das implementações do JSF disponíveis - além de seus parâmetros específicos. Há uma categorização dos parâmetros e uma das categorias é performance. Dê uma atenção especial a ela. Espera-se que cada fabricante forneça essas informações, por isso é recomendável que você estude e trace um plano de configuração de acordo com o perfil de sua aplicação. cursos e muitos não sabem, mas é possível aumentar seu período de execução ou até mesmo desativá-la. A utilidade dessa recompilação automática se restringe ao ambiente de desenvolvimento. Afinal de contas, a frequência com que uma aplicação é publicada em ambientes de produção não justifica manter o recurso ativado. Além disso, em muitos casos, publicações acompanham arquivos.java e sua atualização requer o restart do servidor. Quando omitido, o período de atualização padrão do Facelets depende da implementação do JSF utilizada JSF é uma especificação e não uma implementação - e recomenda-se desligá-lo antes de cada publicação. Para desabilitar este recurso basta armazenar o valor -1 em seu parâmetro de inicialização correspondente, como mostra a Listagem 9, que é um trecho do web. xml de uma aplicação web. Listagem 9. Desativação do recurso de atualização do Facelets. <context-param> <param-name> javax.faces.facelets_refresh_period </param-name> <param-value>-1</param-value> </context-param> Considerações Finais Não existe uma receita de bolo a ser seguida para otimizar suas aplicações. Como você pode ter percebido fizemos uso apenas da especificação do JSF de forma a selecionar as decisões arquiteturais de acordo com os recursos que temos disponíveis para hospedar uma aplicação. A árdua tarefa de otimizar aplicações complexas requer paciência, mas também requer que você saiba o que está fazendo. Parte-se do princípio que ela já atende a seus clientes, mas pode atender melhor. Um bom trabalho de otimização exige que você conheça bem sua aplicação e o framework utilizado. Por isso recomendo que leiam a especificação do JSF e pelo menos um livro de referência completo. Muita coisa já poderá ser óbvia pra você, mas sempre é possível extrair detalhes pequenos que refletem melhorias no produto final. Além disso, recomendo utilizar ferramentas de perfil para que você possa observar as melhorias consequentes das modificações e se o caminho seguido está correto. /referências > Java Server Faces The Complete Reference, Ed Burns, Chris Schalk; > Tuning JSF Applications - Session size matters: sessions/00017/; > JSF Best Practices: > JSF 2.0 Reminder: Project Stage: blog/driscoll/archive/2009/09/28/jsf-20-reminder-projectstage / 20