| Autor |
Mensagem |
|
|
Já remodelamos a camada de banco de dados, sem nenhum frame de persistência, mas com as classes organizadas ao menos (DAO, Impl e Beans).
Agora queremos trabalhar na melhoria da Interface e Controle da aplicação, sem perder as caracteristicas visuais e funcionais do sistema, que utiliza um bocado de Ajax e algumas CustomTags.
Alguma dica?
|
 |
|
|
[quote=cintia]Olá,
Estou tendo o mesmo problema que vc e ja nao sei mais o que faco. Já to quase desistindo do java :(
Vc conseguiu resolver seu problema? Pode me dar umas dicas?
Muito obrigada
Cintia[/quote]
Sim troquei de servidor, era problema de hardware mesmo!
|
 |
|
|
|
http://www.plugin.com.br/ajuda/pergunta/207/como-disponibilizar-calculo-de-frete-em-minha-loja-virtual
|
 |
|
|
O perfil dos clientes atuais que compartilha a solução atual se resolve bem no Tomcat.
A questão é, melhorar esse ambiente apenas, ou partir para uma solução J2EE completa?
O número de clientes que utilizam JSP é muito inferior aos que usam ASP e PHP, o servidores JSP que temos hoje são praticamente semidedicados.
Como fazer para colocar mais clientes em um servidor Tomcat para reduzir o valor da hospedagem é outra pergunta que nos fazemos.
Nossa estratégia em todas as tecnologias é ter um produto barato para o varejo e outro mais customizado e completo com um custo maior e em alguns casos em servidores dedicados.
É esse o pepino que está na minha mão, decidir entre qual web servers utilizar em cada um desses cenários. Levando em conta que o número de soluções é enorme recorro a comunidade para tentar oferecer um produto show de bola para essa mesma comunidade que pesso ajuda agora.
Nossa empresa quer ajudar o GUJ e o Portal Java hospedando os seus fóruns, mas para isso precisamos melhorar o custo-benefício do nosso serviço! Uma solução dedicada para o GUJ e Portal Java teria um custo muito alto para os mantenedores destes dois portais.
|
 |
|
|
Pessoal,
Preciso propor uma nova solução para servidores web Java/JSP compartilhado para vários clientes, tenho uma idéia de melhoria no ambiente atual (clássico Apache + Tomcat) e outras 2 opções fortes que teria que estudar do zero, Gerônimo e Glassfish.
1 - Apache + Tomcat - Servidores compartilhados J2SE + Algumas funcionalidade do J2EE que rodam no Tomcat:
- Tomcat 5.5 + JSDK 1.5.x ou Tomcat 6 + JSDK 1.6.x (tenho feedbacks de que é muito mais rápida essa nova versão, e otimiza melhor o uso da memória);
- mod_jk com dois apontamentos, porta 8080 para o Tomcat do ambiente de Produção e 8081 para o Tomcat do ambiente de Testes;
- Diretórios dos Tomcat de testes e produção devem ser diferentes para que seja possível ter dois arquivos server.xml diferentes;
- Servidor de Testes não carregaria automaticamente as aplicações no startup, e teria a opção reloadable=true, além de reinicialização sob demanda, e programada 1 vez por hora;
- Criação automática de um subdomínio test.dominio.ext para o cliente acessar o ambiente de testes sem a necessidade de chamar pela porta 8081, ou seja teríamos duas entradas no httpd.conf para uma ativação;
- Servidor de Produção, carrega automaticamente as aplicações no startup, e teria a opção reloadable=false, sua reinicialização ocorreria uma única vez duarante a madrugada;
- Criação de novos hosts em arquivos XML separados, e não dentro do server.xml, eliminando a necessidade de restart do servidor para uma nova ativação. Ex.: CATALINA_HOME/conf/Catalina/localhost/dominio.ext.xml
- A estrutura desses arquivos XML é muito parecida com a estrutura dos hosts dentro do server.xml. Ver exemplo no SAAP.
- Este diretório deverá ser único, no ambiente de produção, o ambiente de testes deverá linká-lo apenas, assim criamos e apagamos os domínios em um único lugar;
- Fazer um bench para definir as libs padrão para o Tomcat, que deverão ficar em CATALINA_HOME/common/lib/*.jar
2 - Solução totalmente nova suportando J2EE:
- Versão open source do Websphere, o Apache Gerônimo, que é uma solução J2EE;
- Glassfish, solução open source da SUN, mas pelo que vi ainda está em desenvolvimento.
O que vocês acham?
|
 |
|
|
Pessoal,
Preciso propor uma nova solução para servidores web Java/JSP compartilhado para vários clientes, tenho uma idéia de melhoria no ambiente atual (clássico Apache + Tomcat) e outras 2 opções fortes que teria que estudar do zero, Gerônimo e Glassfish.
1 - Apache + Tomcat - Servidores compartilhados J2SE + Algumas funcionalidade do J2EE que rodam no Tomcat:
- Tomcat 5.5 + JSDK 1.5.x ou Tomcat 6 + JSDK 1.6.x (tenho feedbacks de que é muito mais rápida essa nova versão, e otimiza melhor o uso da memória);
- mod_jk com dois apontamentos, porta 8080 para o Tomcat do ambiente de Produção e 8081 para o Tomcat do ambiente de Testes;
- Diretórios dos Tomcat de testes e produção devem ser diferentes para que seja possível ter dois arquivos server.xml diferentes;
- Servidor de Testes não carregaria automaticamente as aplicações no startup, e teria a opção reloadable=true, além de reinicialização sob demanda, e programada 1 vez por hora;
- Criação automática de um subdomínio test.dominio.ext para o cliente acessar o ambiente de testes sem a necessidade de chamar pela porta 8081, ou seja teríamos duas entradas no httpd.conf para uma ativação;
- Servidor de Produção, carrega automaticamente as aplicações no startup, e teria a opção reloadable=false, sua reinicialização ocorreria uma única vez duarante a madrugada;
- Criação de novos hosts em arquivos XML separados, e não dentro do server.xml, eliminando a necessidade de restart do servidor para uma nova ativação. Ex.: CATALINA_HOME/conf/Catalina/localhost/dominio.ext.xml
- A estrutura desses arquivos XML é muito parecida com a estrutura dos hosts dentro do server.xml. Ver exemplo no SAAP.
- Este diretório deverá ser único, no ambiente de produção, o ambiente de testes deverá linká-lo apenas, assim criamos e apagamos os domínios em um único lugar;
- Fazer um bench para definir as libs padrão para o Tomcat, que deverão ficar em CATALINA_HOME/common/lib/*.jar
2 - Solução totalmente nova suportando J2EE:
- Versão open source do Websphere, o Apache Gerônimo, que é uma solução J2EE;
- Glassfish, solução open source da SUN, mas pelo que vi ainda está em desenvolvimento.
O que vocês acham?
|
 |
|
|
Parece que ninguém sabe
|
 |
|
|
Os clientes pediram, o preço baixou! Agora a hospedagem Java está disponível a partir do plano Standart Plus.
http://www.plugin.com.br/
ou
https://ssl03.plugin.com.br/portal/compra-online/passo1.php?plano=standard_plus&promocao=2&referencia=&idPublicacao=
|
 |
|
|
Estou com o mesmo problema, descobri agora esse daemon jsvc, estava com esperanças de que resolveria o problema, mas se vc já está usando ele e o problema ocorre também volto ao plano anterior.
Apache - JK - Tomcat (node1, node2 e node3 em loadbalance)
|
 |
|
|
bobmoe wrote:
baladao wrote:O servidor rodando PHP/Perl, suporta tranquilamente 10 vezes mais clientes que o rodando JSP/Java.
De forma alguma!
As aplicações CGI utilizam um PROCESSO para cada conexão. As aplicações Java, através dos servlets, utilizam apenas uma THREAD para cada conexão. E isso representa uma diferença enorrrme.
t+
Entendo seu ponto de vista, e concordo na questão da performance, porém como vejo um volume de servidores em produção muito grande onde trabalho a impressão que tenho é a seguinte:
Os serviços que exigem mais processamento (processos, cgi, interpretadores) geram menos problemas que serviços que exigem mais memória (threads, JVM, .Net, mod_perl)!
|
 |
|
|
urubatan wrote:em vez de usar um tomcat usem o jetty ...
utilizem mod_jk em vez do mod_proxy para integração com o apache, ou melhor ainda, deixem o jetty na porta 80 e removam o apache do servidor que vai servir JSP.
usem o jetty 6 junto com JDK 1.6 ...
facilitem as configurações de vocês disponibilizando para o cliente o diretório webapps do dominio dele, o que vai diminuir a mão de obra necessária e deixar os clientes mais felizes ...
deixem o security manager habilitado para evitar que um cliente detone com o servidor ...
não rodem o jetty/tomcat como root (se não me engano o tomcat rodava como root na ultima vez que tive um site hospedado com vocês)
acho que com isto tu vai conseguir diminuir a diferença para no máximo 5x a quantidade de clientes ...
da para ajudar alguns parametros da JVM também ...
mas a partir dai depende também da qualidade do código dos clientes 
Anotadas suas dicas!
Sobre a questão da "qualidade do código dos clientes", eu diria o seguinte, em Java um código ruim impacta negativamente muito mais sobre o servidor do que um em PHP por exemplo. As vezes fico com pena dos administradores... como é difícil manter a estabilidade de um servidor Java em relação a outros tipos de servidores, inclusive IIS/ASP.
|
 |
|
|
A resposta é simples. Considerem dois servidores iguais, um em produção rodando Apache > PHP/Perl, outro Tomcat > JSP/Java.
O servidor rodando PHP/Perl, suporta tranquilamente 10 vezes mais clientes que o rodando JSP/Java.
Se souberem como otimizar isso me digam como que irei implementar junto com os administradores aqui na Plug In (www.plugin.com.br) e depois brigo com a diretoria para baixarem os preços!
|
 |
|
|
rodrigopmatias wrote:cara isto ocorria comigo quase que semanalmente quando meu servido estava com problemas de memoria, o que ocorria era que o java estava criando processos e nao os conseguia matar, e a memoria enchia e a maquina morria como um kernel panic.
Pode ter relação sim! Mas o que vc fez a respeito para reduzir esse número de processos e resolver o problema? Eu baixei o limite máximo da VM para 512mb e até agora não deu pau mais... porém como "ando com os dois pés atrás", acho que pode ter algum problema de hardware, talvez alguma área da memória detonada. Consegui outro servidor para migrar o ambiente de produção, só não fiz ainda pq a máquina é muito melhor, por isso quero configurar algmas máquinas virtuais antes, inclusive a que vai rodar o sistema, isso para aproveitar melhor o hardware.
Detalhe, fazer downgrade simplismente não adiantou... fiquei feliz em saber que a SUN não colocou uma VM podre no mercado.
|
 |
|
|
Já fiz testes de stress em uma aplicação bem simples nos dois SISOP.
O resultado em termos de performance foi muito parecido.
Estabildade não foi testado.
|
 |
|
|
Achei que o que vc queria saber era como forçar o cache...
Para ignorá-lo usar
já é o sufuciente mesmo para o IE...
|
 |
|
|
|
|