| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Uma das coisas que me retiveram mais a atenção no artigo, foi a enfâse que deram à diferença de comportamento entre os web servers normais e os app servers em condições de heavy traffic, mas não fiquei muito convencido, ou melhor: partindo do princípio que há uma tarefa xpto a ser executada, porque é que é mais rápida por exemplo em Zope do que em Apache ?
Mário: apesar de estarem no artigo uma série de justificações, gostava de ouvir de quem sabe da poda.
Mário Gamito
"Make everything as simple as possible... but not simpler"
Albert Einstein |
| | | | | | Li na diagonal o artigo mas posso dizer o que sei da minha própria experiência.
Relembrando a ideia base de web servers e app servers: Quer se queira quer não cada vez que há que responder a um get/post é necessário fazer processamento seja ele ultra-simples (conteúdo estático) ou ultra-complexo (conteúdo dinâmico). Se ficarmos a olhar para um access.log debaixo de heavy traffic qualquer um nota que o número de pedidos de conteúdo estático (tipicamente imagens) é maior do que conteúdo dinâmico (na maior parte dos sites que existem). Tendo webservers optimizados para servir conteúdo estático (webservers simples) e outros para servir conteúdo dinâmico (appservers), tendo obviamente mais para conteúdo estático do que dinâmico, observa-se uma maior capacidade em lidar com heavy traffic e a performance de um site globalmente, nestas condições extremas, aumenta. Um webserver tipicamente deve ser capaz de responder a mais pedidos de conteúdo estático por segundo do que um appserver. O número certo de webservers e de appservers, o seu hardware e software normalmente é o segredo do negócio :) Normalmente tanto o excesso como a falta prejudica o objectivo de atingir o máximo de performance possível num determinado caso. O esquema mais adoptado é o de ter sempre webservers na frente (que são normalmente os que vão parar as estátisticas) que fazem proxy dos pedidos de conteúdo dinâmico para os appservers normalmente mais "potentes" (ver o exemplo do que a redhat quer atingir com o tux, o webserver embutido no kernel).
Uma tarefa ser mais rápida (seguindo o exemplo) em Zope do que em Apache depende do tipo de tarefa. Eu considero que um Apache com mod_php, mod_perl ou alike passa de webserver para a categoria de appserver. Estes mods implementam esquemas de partilha de conecções de base de dados, caching, etc.. Se um Apache appserver é mais rápido ou menos que um Zope appserver acho que se vai tornar mais uma daquelas questões "religiosas" que felizmente o open source tem :) (tipo vi vs emacs) e depende muito da filosofia de implementação da execução dessa tarefa. Fazendo uso da orientação OO do Zope e de cache de objectos que sejam bastante utilizados: sim, em certos casos o Zope poderá ser mais rápido do que o Apache. Mas essas diferenças não devem ser medidas na resposta a um pedido igual feito a ambos mas sim em milhares e milhares de pedidos e no fim ver qual dos dois foi mais rápido num determinado período de tempo.
Da minha experiência acho curioso que os "milhares e milhares" de pedidos na vida real produzem resultados que não se consegue nos testes de carga por mais que se tente reproduzir um comportamento real. Noto como appservers respondem melhor debaixo de carga por não terem de tratar também do conteúdo estático e de poderem aproveitar os recursos que usariam para esse fim para melhorar a sua tarefa de fornecer conteúdo dinâmico bem como os webservers podem usar mais recursos para respoderem aos muitos mais pedidos estáticos. Mas tudo isto só faz sentido se realmente esperamos ter "heavy load" de uma forma constante e se temos um razoável número de conteúdo estático bem como necessidade de utilização inteligente dos ("frágeis") recursos existentes.
Esquecendo os chavões isto não é mais de que uma tentativa de resolver os problemas com heavy load de alguns tipos de sites fazendo um uso mais inteligente dos recursos disponíveis. Por exemplo, não acho que sites slashdot-like beneficiem muito deste tipo de arquitectura... mas um de ecommerce é um caso a pensar (dependendo do tamanho). A que lembrar sempre que falamos em condições de heavy load onde a memória e o processamento das máquinas consegue chegar praticamente aos limites das mesmas (teremos desses casos em Portugal??)... será que a largura de banda disponível não acaba antes de chegarmos a esse ponto ?
|
| | | | | Eu considero que um Apache com mod_php, mod_perl ou alike passa de webserver para a categoria de appserver. Concordo plenamente com todo o teu post, menos com esta afirmacao. Alias, nem discordo: pura e simplesmente estás errado O mod_perl providencia pooled data connections (persistent connections) ? Acho que sim. Database queries cache ? Acho que nao. Single query to multiple heterogeneous databases (ou seja ter apenas um statement SQL que pode ser executado a conexoes simultaneas a um Oracle, um Sybase e um MS SQL) ? I dont think so. Failover ? Tb nao. Fine grained security (algo mais que user/passwd num .htpasswd) ? Tb nao. Versioning ? Sistemas de workflow (criacao de codigo/validacao/aprovacao/publicacao) ? WebDAV ? XMLRPC ? The list goes on... Se disseres que podes transformar um Apache numa especie de app server juntanto o mod_perl/php, com mais o mod_X, mod_Y, mod_Z, mod_W, etc, etc, ainda concordo. Boa sorte em gerir essa porra toda :-). Cumprimentos Mario Valente
|
| | | | | partindo do princípio que há uma tarefa xpto a ser executada, porque é que é mais rápida por exemplo em Zope do que em Apache ? Não é :-) Ou antes, pode nao ser. Depende da tarefa xpto. Primeiro e' interessante ler sobre o C10K Problem, um artigo sobre arquitectura de servidores e a sua performance. Dai e possivel chegar a uma pagina sobre comparacao da performance de Web servers. Tb e referido o Medusa, que esta na base do Zope (e, ja agora do egroups/yahoogroups). Para alem de se notar que existem web servers bem mais rapidos que o Apache para conteudo estatico (e ate' dinamico/CGI), o que se nota, especialmente no grafico, e' que o Apache, como servidor de paginas dinamicas/CGI, nao escala. Vide o grafico. Como dizia acima, tudo depende da tarefa xpto. E' uma pagina a dizer "Hello World" ? O Apache e' mais rapido. E' uma pagina que faz uma query SQL simples a uma pequena tabela ? O Apache e' capaz de ser mais rapido; creio que Apache e Zope ficarao ela por ela. E' uma pagina que mantem uma sessao de um shopping cart quando este depende de multiplas queries/joins a 3 bases de dados diferentes com grande business logic kung fu pelo meio (tipo "o carrinho so' pode ter produtos da classe X mas nao mais do que 30, excepto se o valor ainda nao for 1000 Euro") ? O Zope sera' com certeza mais rapido. Como ja' alguem disse e diz o proprio artigo, isto nao pode ser medido com 1 pedido num Apache e um pedido num Zope. Tem de ser medido estatisticamente, pelo que so' faz sentido aplicar um App server em servidores com cargas respeitosas. Mário: apesar de estarem no artigo uma série de justificações, gostava de ouvir de quem sabe da poda. Posso-te dar detalhes mais especificos e exemplos mas via email... ;-) Cumprimentos Mario Valente
|
| | | | | Mário: apesar de estarem no artigo uma série de justificações, gostava de ouvir de quem sabe da poda. Entretanto: podes/podem ver a lista de clientes do Zope assim como alguns case studies. Nao deixar de prestar atenção aos comentario na coluna direita, dos quais o meu favorito é: "Zope is what Cold Fusion wants to be." :-) Cumprimento Mario Valente
|
| | | | Por outro lado tens Apache em:
www.gdls.com -> General Dynamics
www.oracle.com -> Oracle
www.gm.com -> General Motors
WWW.NAVY.MIL - US NAVY (pelo menos nao estao com o zope la...)
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it... |
| | | | | Bom link. Nao conhecia. Mas melhor do que ver so' os "bonecos" :) é ler o artigo todo Cumprimentos Mario Valente
|
| | | | Os Application Servers nao passam de wraparounds a volta de coisas. Trata-se de mais uma buzzword. Neste sentido o mod_perl pode ser considerado um AS de perl, Zope de python, tomcat de servlets, etc.
Para conteudos estacticos, mas que nao dispensam capacidades http avancadas, nao se quer outra coisa que o Apache. Para coisas mais basicas, ha quem use o squid como proxy acelerador, o khttpd, e as vezes combinacoes dos tres.
Numa situacao ideal, os AS ficam relegados como backends, em zonas com normas de seguranca um pouco mais elevadas, devido a correrem codigo um nadinha mais complexo do que o html.
Acho que comparar o Apache com o Zope e comparar alhos com bogalhos, ou Apache httpd com apache tomcat. Embora os segundos consigam fazer http tambem, nao sao tao bons de forma nenhuma como o primeiro!!
No entanto, esta na moda, especialmente lancada pela MS, para tentar deitar abaixo o Apache httpd. *sigh* e o pior e que ha quem coma...
Hugs, Cyclops
|
| | | | | | | Os Application Servers nao passam de wraparounds a volta de coisas. Trata-se de mais uma buzzword. E' como os compiladores: nao passam de wraparounds 'a volta de assemblers. Trata-se apenas de uma buzzword. Alias, o Linux tb e' apenas mais uma buzzword. Ao fim e ao cabo não é mais nada do que um wraparound 'a volta de device drivers... Para os deficientes em humor e inteligencia: isto e' uma ironia(TM). Neste sentido o mod_perl pode ser considerado um AS de perl, Nao sejas tolo. Como tu proprio disseste: Acho que comparar o Apache com o Zope e comparar alhos com bogalhos Se quiseres dizer que o Mason (que depende do mod_perl) pode ser considerado um AS de perl, ainda vá lá. Agora o mod_perl é tanto um App server como o mod_python ou o mod_php o são. Ou seja, não são. E o mod_python NAO é um App server; mas o Zope é. Para conteudos estacticos, mas que nao dispensam capacidades http avancadas, nao se quer outra coisa que o Apache Ora nem mais. Embora eu preferisse o thttpd, mas pronto. Para conteudos estaticos até o Apache é demais. Numa situacao ideal, os AS ficam relegados como backends, em zonas com normas de seguranca um pouco mais elevadas, devido a correrem codigo um nadinha mais complexo do que o html. Numa situacao ideal, os Web Servers ficam relegados como frontends, em zonas com normas de seguranca simples, devido a nao estarem preparados para correrem "codigo" um nadinha mais complexo do que o html. No entanto, esta na moda, especialmente lancada pela MS, para tentar deitar abaixo o Apache httpd. *sigh* e o pior e que ha quem coma... Bem, se há algo que eu nao "coma" sao as atoardas da MS. Mas para alem da indole pessoal, o teu comentario é completamente estupido. Como o proprio artigo diz, a MS nem sequer tem uma oferta de App server; o IIS é apenas um Web server e o BizTalk...enfim...olha, é uma especie de mod_perl :-) Cumprimentos Mario Valente
|
| | | | Quem é que registou ironia como (TM)? ;)))))))
|
| | | | Comparar Biztalk e mod_perl!
Estão a gozar ?
Bye !
|
| | | | servlet engines, ejbs, trinta por uma linha: fornecer o que se consegue fazer com perl e php para a linha do java (mais a sua filosofia objectual)
Ok, se calhar o mod_perl e demasiado baixo nivel, realmente o mason e mais adequado para ser chamado de AS do que o mod_perl :)
Quanto ao apache ser demais apra conteudos estacticos, isso depende. Depende do que queres fazer, autenticacao sobre ssl, alias, proxies, etc.
Ainda bem que os frontends nao andam a executar codigo, e sempre mais uma camada de proteccao para o que realmente interessa, nao e Mario? A questao nao e de terem mais ou menos poder, e de seguranca.
Quanto a MS nao oferecer um App Server... bem... has-de-me explicar o que sao aquelas merdas todas que um IIS traz activas por default entao, por exemplo, incluindo o vb serverside.
Nao sei onde e que o comentario e assim tao estupido, ate porque a propria Microsoft, em comparacoes com o atrasadinho do Apache, vangloriava-se de fornecer so com o IIS um Application Server.
Quem e que teve o comentario mais estupido afinal? Nao habia nexexidade...
|
| | | | "No entanto, esta na moda, especialmente lancada pela MS, para tentar deitar abaixo o Apache httpd. *sigh* e o pior e que ha quem coma..." "Nao sei onde e que o comentario e assim tao estupido, ate porque a propria Microsoft, em comparacoes com o atrasadinho do Apache, vangloriava-se de fornecer so com o IIS um Application Server." estes teus dois comentarios, onde criticas a MS por esta guerra Web/App servers so pra deitar abaixo o Apache é errada. Pois como podes ver a maioria das app servers corre tecnologias Java, JSPs, servlets, java beans, etc. Se o surgimento dos app servers de ha alguns anos pra ca serviu pra alguma coisa foi pra safar as Oracles, Sysbases, IBMs, Suns, etc, "nesta historia da Internet". E dar algum a muita boa gente. (Pelo menos ate ao ano passado) ;) E digote mais senao fosse os Appservers o proprio java ja tinha morrido!!! pois java applets sao muito bonitos mas nao dao alimento a ninguem. Mas tb convenhamos a explicacao racional é que nao podes ter num grande sistema empressarial um servidor WEb a xutar paginas e a correr apps! Com 20/30 "manfias" por tras a deitar o server abaixo e a compilar codigo!! Simplesmente nao funciona! Apps srevers nao sao competicao sao evolucao. E pra mim desde q essa evolucao se faça com Java, tou descansado. Quero bem q a M$ se lixe mais o seu .Net!!!
|
| | | | YAP Sun ONE é muito melhor que .NET. Agora vamos ver se o markting e o peso da Microsoft não conseguem dar a volta a isso. Espero bem que não.
Já agora a plataforma Sun ONE está disponivel em http://www.sun.pt/starterkit/ á borla para quem quiser encomendar.
|
| | | | Nunca usei o Zope e não sei como funciona nem se suporta java.
Mas todos os aplications servers (desde o tomcat, websphere, iplanet etc...) que conheço funcionam juntamente com um web server ou na mesma box ou em outras box's mas não é possivel ter um aplication server sem um webserver. Não tou a compreender este Web servers vs App servers da noticia, são duas tecnologias complementares e não adversárias.
O uso de aplications servers passa muito o que se fez notar na noticia e não servem para servir só paginas dinamicas. Servem desde portais WAP passando por mercados electronicos até funções de EDI (elecronic data interchange) para aprovisionamento em Linha. Sem falar da distribuição de aplicações que os aplications servers permitem facilmente com CORBA.
Mas a sua maior utilidade (no meu ponto de vista) tem a ver com a "integração de processos" quer através dos aplication servers ou através de outras aplicações ligadas a eles. Servem para ligar os processos externos como os portais e comercio electronico com os processos internos da empresa como o CRM ou ERP ou a produção.
Isto tudo faz uso do Java , Soap ou XML entre (é por isso que são conhecidos como servidores de aplicações Java)e não de PHP ou perl ou python como apareceu nos comentários.
Não faz qualquer sentido comparar webservers com application servers.
|
| | | | | | | Nunca usei o Zope e não sei como funciona nem se suporta java. Podes la' por apps Java, mas nao suporta Java como linguagem de development. Why should it ? mas não é possivel ter um aplication server sem um webserver A nao ser que o app server tb funcione como web server. E' o caso do Zope (embora possas usar qq outro web server como frontend). Ou do OracleXi. Isto tudo faz uso do Java , Soap ou XML entre (é por isso que são conhecidos como servidores de aplicações Java)e não de PHP ou perl ou python como apareceu nos comentários. Não faz qualquer sentido comparar webservers com application servers. Que tolice. Um web application server NAO TEM de fazer uso do Java e nao e' por correr apps java que um app server e' um app server. Por isso o facto de a linguagem nao ser Java nao justifica nao haver comparacao entre um web server e um app server. Um app server pode funcionar com qq ou varias linguagens (o Vignette usa Tcl; o Cold Fusion uma linguagem propria; o Zope pode usar o DTML [proprio], o Perl ou o Python. És capaz de estar um bocado baralhado sobre O QUE É um web application server. NAO É obrigatoriamente um Java servlet server. Cumprimentos Mario Valente
|
| | | | Pois tems razão :-), Tou só abituado a lidar com aplication servers de java que me esqueço dos outros.
|
| | | | És capaz de estar um bocado baralhado sobre O QUE É um web application server. NAO É obrigatoriamente um Java servlet server.
Pois mas quase todos os app server usam a plataforma J2EE
mas não é possivel ter um aplication server sem um webserver
A nao ser que o app server tb funcione como web server. E' o caso do Zope (embora possas usar qq outro web server como frontend). Ou do OracleXi.
A nao ser que o app server tb funcione como web server. E' o caso do Zope (embora possas usar qq outro web server como frontend). Ou do OracleXi.
tens o Tomcat tb
Um app server pode funcionar com qq ou varias linguagens (o Vignette usa Tcl; o Cold Fusion uma linguagem propria; o Zope pode usar o DTML [proprio], o Perl ou o Python.
O coldfusion usa CFML pra serverside scr1pting(a la PHP).
Podes é criar beans ou componentes em java.
|
| |
|
