| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | por Anonimo Cobarde em 11-09-00 23:08 GMT (#1)
|
| | | | | | | olé!
como o meu abó já dizia e passo a citar
"mais bale tarde que nunca netinho! tu amanda-lhe! ;)"
|
| | | | olé!
como o meu abó já dizia e passo a citar
"mais bale tarde que nunca netinho! tu amanda-lhe! ;)"
|
| | | | | Apache sucks... IIS forever...
Nelson Marques |
| | | | Apache sucks... IIS sucks... Zope ZServer forever!!!
==========
Hugo Ramos - hugo@zopers.org
ZopersORG - www.zopers.org |
| | | | | | Sim, ZServer por detras de um Apache :)
Where exactly does Apache suck?
|
| | | | >Sim, ZServer por detras de um Apache :)
Para quê ? Quando muito Zope por detrás de um Apache... Usando o Apache o ZServer nao é preciso para nada.
O Zope é o sistema de publicação de objectos; esses objectos podem ser apresentados em HTML através do ZServer ou do Apache ou do IIS ou whatever. ZServer por trás de Apache não faz muito sentido; é um HTTP server atrás de outro.
>Where exactly does Apache suck?
Bem, nos buracos descritos do WebDAV por exemplo :-). Tambem se pode referir o facto de ser filesystem based (com os decorrentes potenciais problemas de segurança, exemplificados pelo outro buraco descrito) ou até mesmo a arquitectura (pre-fork em vez de ser select() based, como todos os bons servers :-) (ex: Zeus, Roxen, Medusa [no qual é baseado o ZServer])
Mais informações interessantes aqui
Cumprimentos
-- Mario Valente
|
| | | | >pre-fork em vez de ser select() based, como >todos os bons servers :-) (ex: Zeus, Roxen, >Medusa
Desculpem o erro, mas quando referi o Roxen queria referir-me ao Boa. O Roxen e' threads-based. Já agora outro exemplo de um servidor HTTP select()-based é o thttpd.
Cumprimentos
-- Mario Valente
|
| | | | > Bem, nos buracos descritos do WebDAV por exemplo > :-). Tambem se pode referir o facto de ser > filesystem based (com os decorrentes potenciais > problemas de segurança, exemplificados pelo > outro buraco descrito) ou até mesmo a > arquitectura (pre-fork em vez de ser select() > based, como todos os bons servers :-) (ex: Zeus, > Roxen, Medusa [no qual é baseado o ZServer]) e evidente que coisas como o apache, sendmail, mysql, tem muito mais bugs de seguranca (95% deles irrisorios e ultrapssados) do que o Zeus, Zope, o qmail. o facto de cerca de 60% dos sites utilizarem o apache provoca essa reaccao. filesystem-based : concordo em parte; pode-se sempre proteger de n formas, mas tudo bem, de acordo ;)
|
| | | | >o facto de cerca de 60% dos sites utilizarem o >apache provoca essa reaccao
Portanto, quanto mais um software é utilizado, mais bugs tem ? Não me lixes...
Pensando bem, o teu raciocinio, embora errado, explicava o porquê de tantos bugs no Windows ;-)
Cumprimentos
-- Mario Valente
|
| | | | | Bom, pelo menos quando ha' mais utilizadores ha' mais gente a utilizar descuidadamente. E como e' dificil fazer software completamente `a prova de disparate, mais situacoes de risco sao criadas e mais publicidade se da' aos bugs mais "mediaticos". Os bugs nao aumentam com a utilizacao, mas a possibilidade de se manifestarem sim, e a notoriedade deles, quando sao descobertos, tambem. Vivam os sistemas capazes de manter a reputacao nessas situacoes... Enfim, que pena que nem tudo no mundo seja tao bem feito como o TeX.
|
| | | | | Richard M. Stallman, Linus Torvalds, and Donald E. Knuth engage in a discussion on whose impact on the computerized world was the greatest. Stallman: "God told me I have programmed the best editor in the world!" Torvalds: "Well, God told *me* that I have programmed the best operating system in the world!" Knuth: "Wait, wait - I never said that."
|
| | | | sabes bem que nao foi isso que eu quiz dizer. o que eu quero dizer e que se eu e a malta la do bairro fizer um webserver cheio de bugs, ninguem os vai gritar aos 7 ventos porque ninguem nos conhece de lado nenhum. chama muito mais a atencao uma nova versao do apache e do iis que de outro web server qualquer, ou nao achas?
|
| | | | | > (pre-fork em vez de ser select() based, como todos os bons servers :-) de facto, o apache1 suporta apenas pre-forking, o mesmo já não se passa com o apache2 (ainda em alpha).
de qualquer modo, a crítica que faz parece-me um pouco radical... quer elaborar?
|
| | | | | De facto o Apache 2.0_ALPHA suporta multi-process e multi-thread alem do pre-fork... Apenas a resposta nao eh consistente com o que foi dito anteriormente!!! O que aqui se referiu eh que nenhum dos sistemas suportados pelo apache (pre-fork, multi-process e multi-thread) se livra da mah performance, quando comparado com qq um select() based web server, nomeadamente o Zeus ou o grande ZServer (web server do Zope). No entanto eh sempre bom ver os esforcos que a equipa do apache anda a fazer para se livrar do problema das 125 coneccoes concorrentes...
problema esse descrito no fim desta pagina no grafico.
==========
Hugo Ramos - hugo@zopers.org
ZopersORG - www.zopers.org |
| | | | | Apresentar este benchmark levanta algumas questões: - estes testes foram realizados em 1998 (não é necessário, julgo, argumentar)
- Nas notas do teste temos:
- The benchmark test system is a 297MHz Ultra Sparc with 256MB RAM / 512MB swap running Solaris 2.6, otherwise totally quiescent. RLIMIT_NOFILE is 256 soft / 1024 hard, and v.v_maxup is 3941.
- All programs are in their out-of-box configuration, except as needed for the tests (e.g. enabling CGI)
Quanto às configurações da Sun, parece-me que fizeram o mesmo que às configurações do apache... não lhes mexeram. Realizei um teste utilizando o mesmo software com as seguintes configurações: - UltraSPARC-IIi 440MHz
- 256MB RAM, 512M Swap
- apache_1.3.12 com:
- MaxKeepAliveRequests 5000
- MinSpareServers 100
- MaxSpareServers 500
- StartServers 300
- MaxClients 500
- lim_fd_cur = 512
- lim_fd_max = 4096
- ligação cliente-servidor sobre 100BaseTX Full Duplex (switched)
benchmark # http_load -parallel 400 -seconds 10 urls 3966 fetches, 400 max parallel, 2.76034e+06 bytes, in 10.0002 seconds
696 mean bytes/connection
396.59 fetches/sec, 276027 bytes/sec
108.486 mean msecs/connect
318.323 mean msecs/first-response
Os resultados falam por eles próprios. De onde vêm essa das 125 conexões?
|
| | | | >Apresentar este benchmark levanta algumas >questões:
>[...]
>estes testes foram realizados em 1998 (não é >necessário, julgo, argumentar)
>[...]
>Realizei um teste utilizando o mesmo software >com >as seguintes configurações: > >UltraSPARC-IIi 440MHz
>[...]
>benchmark > >
># http_load -parallel 400 -seconds 10 urls
>[...]
>396.59 fetches/sec,
Portanto, realizaste um teste dois anos depois, numa versao mais recente, com hardware melhor e a melhoria conseguida foi de 250 requests/sec para 396 requests/sec ? Nao me parece grande melhoria. Especialmente tendo em conta que os outros servers tambem foram melhorados e tambem beneficiam da melhoria de performance do hardware.
>Os resultados falam por eles próprios.
Concordo plenamente :-)
Cumprimentos
Mario Valente
|
| | | | | Façamos aqui umas contitas baseadas neste fenomenal gráfico de performance... Consideremos o tamanho médio de uma página em 20KB.
Para um utilizador puxar esta página num segundo, gasta 160Kbps.
Então temos: Benchmark sobre 100BaseTX (segundo o gráfico): Zeus - 12 lusers simultâneos - 1000 hits/s
Apache - 12 lusers simultâneos - 280 hits/s Benchmark sobre um link E1 (1920Kbps) Zeus - 12 lusers simultâneos - 12 hits/s
Apache - 12 lusers simultâneos - 12 hits/s Benchmark sobre um link 10BaseTX Zeus - 62 lusers simultâneos - 62 hits/s
Apache - 62 lusers simultâneos - 62 hits/s Face a estes resultados, porquê optar por um "less-featured", select() based server em substituição do apache?
|
| | | | Se queres performance não queres select(), nem sequer poll() (que é o que querias realmente dizer com select), o que queres realmente é asynchIO e o Tux do Ingo.
|
| | | | >o apache1 suporta apenas pre-forking, >o mesmo já não se passa com o apache2 (ainda em >alpha).
Correcto. A palavra chave é alfa :-)
>de qualquer modo, a crítica que faz parece-me um >pouco radical... quer elaborar?
Eu acho que já elaborei :-) Sugeria a visita ao link que referi.
De qq forma, elaborando um pouco: o facto de o Apache servir ficheiros e CGIs a partir do filesystem é a principal via de exploração de buracos de segurança; é dai que se torna possivel, por esta ou aquela razão, ler source code de CGIs, /etc/passwds ou mm criar files no disco. Em relação à arquitectura do servidor, nomeadamente a forma de concorrência escolhida,em vez de elaborar tanto, sugeria mais uma vez o link já indicado, ou então o paper onde se diz claramente que " "...factoring out I/O, the primary determinant to server performance is the concurrency strategy." "
Os resultados de benchmarks estão à vista, saindo claramente vencedores os HTTP servers que se baseiam num select() loop.
Por estas (principalmente) e por outras razões, nao acho que a critica feita seja assim tão radical. Não é à toa que muita gente está a mudar para Zeus ou thttpd. São select() based. E convem sempre lembrar que o nome Apache foi originado por se estar a fazer "a patch" ao NCSA HTTP server. O Apache neste momento já se devia chamar TooManyPaches :-); e o tamanho do código e a sua arquitectura já começam a acusar a idade e a pesar na performance, quando comparado com outros approaches.
Cumprimentos
-- Mario Valente
|
| | | por Anonimo Cobarde em 13-09-00 9:48 GMT (#21)
|
| > Eu acho que já elaborei :-) Sugeria a visita ao link que referi.
As benchmarks ja' nao sao propriamente recentes. De qualquer maneira aplicam-se a conteudos estaticos, e a direcçao actual sao os conteudos dinamicos.
Quando estamos a lidar com conteudos dinamicos, os servidores baseados em select nao sao propriamente os mais indicados (na minha opiniao). Como e' que utilizas um back-end embebido no espaco de enderacamento do servidor web com select e que NAO tenho um mecanismo interno de multi-tarefas?? o backend devolve o processador voluntariamente? (pseudo preempcao manual). Nao vais fazer um fork pois nao???
Ou estas a falar de um servidor web com selects que funcione como um proxy invertido que se limite a fazer um tunel para conteudos estaticos e sirva directamente (ou tunel com cache) de conteudos estaticos?? (ainda nao vi nenhum que o faça)
Julgo que onde obterás melhor performance será um servidor (qualquer que ele seja) que sirva os conteúdos dinâmicos em modo utilizador com um servidor em modo kernel para conteúdos estáticos.
O IIS fá-lo, o solaris fá-lo, o linux 2.4 fá-lo (khttpd) e brevememente o Tux fá-lo ainda melhor.
O tux tem uma aproximação brilhante, serve conteúdos estáticos e tem hooks para interagir com servidores que corram em modo utilizador. (podes inclusivé fazer cache de conteúdos dinâmicos usando os hooks do Tux)
Tiago Pascoal
|
| | | | >As benchmarks ja' nao sao propriamente recentes.
O que não muda a sua validade, especialmente se se tiver em conta que a evolucao havida entretanto se aplica a todos os servidores. Vide por exemplo os testes feitos e postados por outro participante da discussão.
>De qualquer maneira aplicam-se a conteudos >estaticos, e a direcçao actual sao os conteudos >dinamicos
Sem duvida. Ve lá bem o benchmark e vais ver que se refere tanto a conteudos estaticos como a dinamicos (CGIs)
Julgo que onde obterás melhor performance será um servidor (qualquer que ele seja) que sirva os conteúdos dinâmicos em modo utilizador com um servidor em modo kernel para conteúdos estáticos.
Sem duvida. Vide um dos links que referi sobre o JAWS, que é um servidor HTTP que adapta a sua forma de funcionamento ao tipo de conteudo a ser servido.
Cumprimentos
Mario Valente
|
| | | por Anonimo Cobarde em 13-09-00 11:23 GMT (#25)
|
| > Sem duvida. Ve lá bem o benchmark e vais ver que se refere tanto a conteudos estaticos como a dinamicos (CGIs)
CGI's??? ai os forks. O único sistema operativo que conheço que é mais ou menos imune (leia-se leve) ao peso dos forks será o linux (um fork tem o mesmo peso que a criação de uma thread (mais ao contrário mas pronto)), um fork é uma brutalidade e um sistema destes será sempre um criminoso para a máquina.
De qualquer maneira, o uso de CGI's é cada vez mais pequeno. (estou a falar de aplicações n tier com um browser por cliente)
> Sem duvida. Vide um dos links que referi sobre o JAWS, que é um servidor HTTP que adapta a sua forma de funcionamento ao tipo de conteudo a ser servido.
Sim estava consciente deste soft (vapor? :-)) mas este viola a tua premissa, ao ser adaptativo deixa de usar um select :-)
Umas das coisas que sempre me intrigou foi como é que o zeus suporta uma API e usa um select. Mas nunca tive tempo nem paciência para investigar.
Já para não falar que o select não escala para multi-processadores. (podes sempre usar um modelo hibrido à la netscape e apache 2.0 claro)
Tiago Pascoal
|
| | | | | Uma pergunta sobre serviços baseados no filesystem e buracos de segurança: Há razões para pensar que um serviço não baseado no filesystem pode ter menos buracos de segurança do que um baseado no filesystem? Pergunto porque, não sabendo a resposta, tenho uma opinião "heuristica": Um serviço que não se baseia no filesystem baseia-se nalguma espécie de base de dados que habita no filesystem. À primeira vista parece que se acrescenta um elemento à cadeia, e portanto acrescenta-se uma possível fonte de problemas. Ou seja, fica-se com um sistema (teoricamente) menos fiável. Estou muito enganado? Há alguns exemplos em que a coisa na prática acabe por ser doutra forma (por exemplo, por o sistema baseado no filesystem necessitar de ter mais vias exploráveis abertas para fazer o mesmo trabalho...)?
|
| | | | | Se tudo correr bem, um servico centrado num sistema cujos acessos ao file system sejam muito bem controlados, e com o qual sejam feitas directamente todas as "conversas" HTTP sem cada uma "pedir" acesso a algo diferente no filesystem, podera' ser mais seguro. Essencialmente, trata-se de reduzir o tipo de mexidas no file system necessarias para satisfazer um pedido, portanto com menos tipos de eventos (do ponto de vista "externo" ao servico HTTP) cuja seguranca tem que ser avaliada e prevenida.
|
| | | | >Há razões para pensar que um serviço não baseado >no filesystem pode ter menos buracos de >segurança do que um baseado no filesystem?
Heuristicamente há :-). A partir do momento em que não há acesso a coisas como .rhosts, /etc/passwds e outros, acho que há alguma razao para pensar que existirao menos buracos de segurança.
>Um serviço que não se baseia no filesystem >baseia-se nalguma espécie de base de dados que >habita no filesystem. À primeira vista parece >que se acrescenta um elemento à cadeia, e >portanto acrescenta-se uma possível fonte de >problemas. Ou seja, fica-se com um sistema >(teoricamente) menos fiável.
À primeira vista e teoricamente é o que parece :-). Na realidade, não tem sido essa a minha experiência. Acho que depende do middleware (o tal elemento que se acrescenta à cadeia).
>Estou muito enganado? Há alguns exemplos em que >a coisa na prática acabe por ser doutra forma
Posso dar exemplos com o Zope: originalmente guarda toda a informação da OODB (BD object oriented) num ficheiro (Data.fs) que é guardado no filesystem. Isto ajuda à performance dado que não é necessário o constante open/lock/close de varios ficheiros; a ajuda à performance é tanto maior quanto pior for o filesystem do OS (Win NT por exemplo).
De inicio isso fazia-me alguma confusão. Chateava-me pensar que no caso de uma falha/erro no ficheiro, estava lixado e perdia TODOS os objectos; tinha a sensação que era preferivel ter um armazenamento filesystem-like, ou seja, cada objecto num file.
O que se verifica é que esse Data.fs é extremamente fiavel e resiliente. E nos casos em que há problemas, é relativamente fácil de recuperar.
No entanto, há obviamente quem não goste da ideia. E nesse caso o Zope pode armazenar a OODB em diferentes sistemas. É possivel por exemplo armazenar em Berkeley DB, uma BD tida em muita consideração pela sua fiabilidade e rapidez. Também é possivel armazenar os objectos Web em Oracle, tirando partido das funcionalidades relacionais e de administração. Não será muito dificil imaginar um sistema de armazenamento directo numa partição propria, à semelhança do que já fazem outros sistemas (como o Oracle).
Qualquer destas opções (BD, SGBDR, partição) parece-me melhor em termos de segurança (e quiçá em termos de fiabilidade) do que o armazenamento no filesystem.
Cumprimentos
Mario Valente
|
| | | | | >>Há razões para pensar que um serviço não baseado
>>no filesystem pode ter menos buracos de
>>segurança do que um baseado no filesystem? >Heuristicamente há :-). A partir do momento em
>que não há acesso a coisas como .rhosts,
>/etc/passwds e outros, acho que há alguma
>razao para pensar que existirao menos buracos de
>segurança. Mas basear um serviço no filesystem não e' sinonimo de dar acesso ao /etc/passwd & friends. Pode e' acontecer que esses detalhes sejam habitualmente descurados, mas isso e' outra historia... [...]
>Posso dar exemplos com o Zope: originalmente
>guarda toda a informação da OODB (BD object
>oriented) num ficheiro (Data.fs) que é guardado
>no filesystem. O exemplo do zope e' dos piores. Nesse caso o middleware (zope) permite (pior, fomenta!) a administracao por browser dos objectos (Data.fs), o que possibilita o surgimento no ecossistema dos exploits de, por exemplo, client-side trojans invulgarmente poderosos. Isto e' tragico, pois permite que a engenharia social deixe de necessitar de um humano a perguntar-nos "qual e' a password" (coisa de que se pode sempre desconfiar) e passa a ser feita silenciosamente por via dos mecanismos de administracao (o browser sabe a password, ele diz, nao e' preciso perguntar a mais ninguem!). Estas e outras levam-me a pensar que o problema não é do middleware ser este ou aquele, mas antes de *haver* middleware. Uma das tragedias da engenharia é que acrescentar elos a uma cadeia enfraquece sempre a cadeia. Enfim, claro que tem que haver alguma coisa. A (minha) objeccao mais importante à minha heuristica inicial é: O trabalho tem que ser feito. Se as pessoas, para evitar problemas potenciais de seguranca associados ao acrescentar de elementos à cadeia, ficam com a vida dificultada, entao vao *elas mesmas* acrescentar buracos de seguranca para fazerem o seu trabalho sem muitas chatices. Assim a minha questao inicial mais importante tinha a ver com casos em que as pessoas, para conseguir fazer o seu trabalho, tenham recorrido a expedientes que enfraquecem o sistema (e melhor ainda, com informacao sobre estudos e estatisticas de casos desses).
|
| | | | | Como preferes usar o Zope por detras do Apache? Do que eu vi, parece que a solucao preferida em termos de performance e' mesmo continuar a usar o ZServer, com o Apache com ProxyPass; claro que isto se torna mais interessante com uma "quinta" de servidores Zope e Apache (ou outro proxy) em front-end, mas os comentarios que vi referiam-se tambem a uma unica maquina. Porque usar Apache tambem? Por funcionalidade que nao exista em Zope, para permitir coexistencia de servicos nao integrados no Zope, e por vezes por razoes de performance, ja' que o Zope nao e' ideal para TODAS as situacoes... e convem deixar servir alguns ficheiros (estaticos) de fora dele. Quanto aos problemas de seguranca... bom, tudo os pode ter. Claro que estou a pensar na situacao de um administrador que nao vai usar acriticamente o ficheiro de configuracao do Apache tal como ele veio na distribuicao de Linux, por exemplo. O Apache da' liberdade para disparatar mas se formos crescidinhos podemos usar essa liberdade de forma responsavel e ter uma vida relativamente pacifica mesmo com um servidor que nao e' a prova de disparates... Quanto `as outras criticas contra o Apache... Interessa ver um pouco alem das corridas de performance ou genialidade de arquitectura e lidar com a vida terrivel no mundo real. Nao digo que as criticas sao infundadas, mas para mim a escolha de uma package resulta do equilibrio entre varios factores. Ha' varios aspectos no Zope de que nao gosto, mas no conjunto considero-o satisfatorio (para as minhas necessidades, claro). Tal como nao gosto de certas caracteristicas do Apache, e ja' nem falo (porque nao precisei ou tive tempo para pensar niso) da elegancia do codigo ou dos limites de performance. Suponho que na pratica a performance do Apache, para muitas servicos WWW, nao sera' o "estrangulamento" do servico. Por outro lado, a natureza "patchy" do Apache, apesar do que for mais feio, acabou por responder a uma quantidade enorme de problemas encontrados "em accao". Naturalmente, espera-se que alguem um dia arregace as mangas e torne a montar tudo deitando fora o lixo. Antes do Apache usava o WN. O WN podera' ser um servidor simplezinho, sem muitas das capacidades dos primos "grandes", mas tem a virtude de ter uma documentacao excelente e curta e uma preocupacao muito marcada com a seguranca; e no que toca a questoes de seguranca, a simplicidade ajuda. Quando precisei de mais funcionalidade, passei para o Apache, depois juntei o Zope ao bando... Sem ignorar os problemas de seguranca, acho que se pode viver bastante feliz sem entrar na guerra detalhada da performance e elegancia. Ate' porque afunilar para dentro dessa guerra pode ser um mau guia para a escolha de uma solucao global para construir um servico.
|
| | | | >Como preferes usar o Zope por detras do Apache?
São gostos :-)
Mas não é o que prefiro. O que prefiro é usar o Squid como frontend para um parque de maquinas com o Zope/ZServer/ZClientStorage que usa o ZopeStorageServer num backend. Só acho que o Zope por trás do Apache é melhor do que o ZServer por trás do Apache. Primeiro porque não faz sentido: é um servidor HTTP por trás de um servidor HTTP; segundo porque diminui a performance (verificado na prática).
>Do que eu vi, parece que a solucao preferida em >termos de performance e' mesmo continuar a usar >o ZServer, com o Apache com ProxyPass
Ou seja, usar o Apache como proxy :-). Prefiro o Squid. Obviamente o uso do Apache permite usar outras funcionalidades, que nem o Zope nem o Squid teêm.
>Porque usar Apache tambem? Por funcionalidade >que nao exista em Zope
Correcto...
>e por vezes por razoes de performance, ja' que o >Zope nao e' ideal para TODAS as situacoes
Correcto também...
>Quanto aos problemas de seguranca... bom, tudo >os pode ter
>[...]
>Nao digo que as criticas sao infundadas, mas >para mim a escolha de uma package resulta do >equilibrio entre varios factores
>[...]
>Quando precisei de mais funcionalidade, passei >para o Apache, depois juntei o Zope ao bando... >Sem ignorar os problemas de seguranca, acho que >se pode viver bastante feliz sem entrar na >guerra detalhada da performance e elegancia
Concordo plenamente com tudo :-).
Cumprimentos
Mario Valente
|
| | | por Anonimo Cobarde em 12-09-00 14:52 GMT (#8)
|
| | |
|
