| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | O artigo aborda um benchmark entre o Apache 2.0 e o Yaws que é um servidor web feito em Erlang. Nao e' por nada, e podem vir ja' os zelotas do Apache me atirar tijolos, mas o Apache em termos de servidores web nao e' exactamente a melhor coisinha que anda por ai. O facto do Yaws bater o Apache diz mais sobre o Apache do que o Erlang...
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | | | | Apache Vs. Zeus... sou só eu ou isto parece um combate de wrestling? Só falta o Tarzan Taborda nos comentários :D
---
Este espaço pode ser seu... |
| | | | Pode não ser o melhor que anda por aí, mas nesta humilde opinião de leigo, para mim é o melhor webserver open-source.
Parece ser bastante robusto, é de fácil gestão - heck, até eu consigo instalar e manter um Apache - e a documentação oficial deles é bastante boa.
Sobre a performance, bom, o tempo está cá é para isso mesmo :) dar a oportunidade de melhorar a coisa.
---
Este espaço pode ser seu... |
| | | | Eu era capaz de jurar que é o Zope (sim, eu sei que é mais do que um web server).
*Conceptualmente*, até o IIS é melhor do que o Apache.
--
Your first kiss is the one from all others will be judged.
And they'll always be behind. |
| | | | Contudo, o Zeus não é comparável pois falta um pormenor muito importante: não é Software Livre, logo os utilizadores estão em enorme desvantagem perante o fornecedor.
Uma comparação entre o Apache e o Yaws parece-me bem mais justa, pois podem competir livremente em questões técnicas, já que o licenciamento não é um problema sob questão alguma.
|
| | | | E ainda que o Zeus é caríssimo. Comparativamente com o Apache, o Zeus perde no binómio qualidade/preço.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | Vou começar a recomendar a leitura deste texto a todo aquele que abusar da palavra zelota...
A primeira frase é deveras elucidativa :-).
Tonidosimpostos: "a firewall mais segura que conheço é o cinto de castidade!" |
| | | | Em bom português, 'zealota' significa lambe-botas (para não dizer 'lambe-cús').
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Ou eu já sou muito velho ou um lambe-cús era o "graxa". Mas procura saber o que eram os zelotas e percebes a diferença ;-).
Tonidosimpostos: "a firewall mais segura que conheço é o cinto de castidade!" |
| | | | | Os Zelotas (grafia correcta) eram a seita mais extremista do judaísmo nas primeiras épocas do mundo cristão. Advogavam a resistência activa ao domínio romano e a restauração de facto do poder teocrático. Pejorativamente e por corruptela, não significa lambe-botas nem lambe-cus, mas alguém que é inamovível, mesmo face à força de mil razões. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | E ja agora peço desulpa por estar em inglês, nao me apetece estar a traduzir nada, e acho que no original fica sempre melhor do que eu poder ocurrer em algum erro, assim se ninguem se importar ( ou caso contrário o problema é inteiramente de que o fizer), aqui vai a descrição pormenorizada do que é um Zelotas:
Zealot; Zealots
zel´ut, zel´uts: Simon, one of the apostles, was called “the Zealot” Ζηλωτής, Zēlōtḗs from ζηλόω, zēlóō “to rival,” “emulate,” “be jealous,” “admire,” “desire greatly,” Luk_6:15; Act_1:13, the King James Version “Zelotes”). In Mat_10:4 and Mar_3:18 he is called “the Cananean” (so the Revised Version (British and American) correctly; not “the Canaanite,” as the King James Version says, following inferior manuscripts), ὁ Καναναῖος, ho Kananaíos. From the time of the Maccabees there existed among the Jews a party who professed great zeal for the observance of the “law.” According to Josephus (BJ, IV, iii, 9; v, 1; VII, viii, 1) they resorted to violence and assassination in their hatred of the foreigner, being at many points similar to the Chinese Boxers. It is not improbable that the “Assassins” (see ASSASSINS) of Act_21:38 were identical, or at least closely associated, with this body of “Zealots,” to which we must conclude that Simon had belonged before he became one of the Twelve. See, further, SIMON THE ZEALOT.
Regards,
Ao Orgulho segue-se a ruína, e a arrogância vem antes da queda (Prov. 16:18) |
| | | | Desculpa acabei por nao acrescentar nem as referencias nem o resto do texto...
(...)
The Zealots were a faction, headed by Judas of Galilee, who “in the days of the enrollment” (compare Act_5:37; Luk_2:1, Luk_2:2) bitterly opposed the threatened increase of taxation at the census of Quirinius, and would have hastened by the sword the fulfillment of Messianic prophecy.
(...)
Fonte: ISBE
Ao Orgulho segue-se a ruína, e a arrogância vem antes da queda (Prov. 16:18) |
| | | | | O facto de Simão ter sido zelota pode ter terminado com o seu chamamento como discípulo de Cristo. Muitas vezes as pessoas mudam, mas as alcunhas ficam. Não continuamos a chamar ao Durão Barroso «o chinês», lá por ele ter vindo do MRPP? Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | Hoje em dia é dificil encontrar um servidor http que não supere o Apache em benchmarks... No entanto vai continuar a ser utilizado. É o efeito manada, que curiosamente, muitos utilizadores desde site costumam criticar...
|
| | | | | | | | Ui... quantos benchmarks e' que precisas ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | Se queres provar o que dizes, pega em resultados comparáveis e mostra-os. Os benchmarks que apontas são completamente inúteis e irrelevantes, porque não têm uma base comum e ninguém aqui vai perder um dia inteiro a compará-los pesando todas as diferenças.
Estou-te mesmo a ver, sentado em frente ao computa dor a imaginar "vou-lhes atirar com um saco de números, e como ninguém se vai dar ao trabalho de os massajar, vão todos render-se à minha sabedoria".
Lamento, mas esperar que as pessoas acreditem em ti à conta de benchmarks avulsos, feitos cada um na sua máquina distinta da próxima, não é ser ingénuo, é ser parvo.
--
Carlos Rodrigues
|
| | | | Eu de facto não perdi muito tempo para comparar resultados mas gostava de deixar duas notas:
1) só um benchmark do Apache?
2) O único benchmark do Apache é de 2002?
---
Este espaço pode ser seu... |
| | | | | Portanto, resultados do SpecWeb99 (o benchmark standard para servidores web) nao serve ? Ok, preferias um benchmark feito por um tipo qualquer e publicado no Slashdot ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | O benchmark? Não quererás dizer os benchmarks?
Com essa idade e ainda não percebeste a diferença entre um amontoado de números e um comparativo?
--
Carlos Rodrigues
|
| | | | | Benchmark: To measure (a rival's product) according to specified standards in order to compare it with and improve one's own product. Queres comparar o Apache com outro produto ? Procura hardware semelhante nos tais numeros de que te queixas para o software que queres comparar, e compara os valores. Se o Apache nao estiver na lista isso por si so' talvez te diga algo em relacao 'a sua performance (os vendors de hardware nao vao escolher software lento para publicar resultados do seu hardware). Na tua idade tambem ja' devias saber como e' que funcionam os benchmarks da Spec.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | Boa, afinal sabes que esses valores que apresentaste são irrelevantes... parabéns!
--
Carlos Rodrigues
|
| | | | Mas já agora... acho que é perfeitamente óbvio que o TUX (Red Hat Content Accelerator) é bastante mais rápido do que o Apache a servir conteúdo estático (o que está a acontecer nesses testes), o que nada diz sobre a performance do Apache, que é apontado para situações do mundo real, onde o conteúdo dinâmico existe e é mais importante do que o estático.
O que interessa saber é a performance do Apache a servir um misto de conteúdos estáticos e dinâmicos, em comparação com outros webservers nas mesmas condições (de hardware, clientes, conteúdo, etc.).
Esses benchmarks em nada servem para isto, portanto de nada servem para concluir seja o que for sobre a qualidade do Apache. Portanto, vais ter de te esforçar mais para fazer vingar a tua ideia de que o Apache é fraco, se é que realmente essa tua convicção se baseia em factos, reais ou não, e não é apenas algo que sacaste do rabo.
--
Carlos Rodrigues
|
| | | | | A mim nada parece evidente porque claramente nem sabes o que carago e' o SpecWeb99... O que interessa saber é a performance do Apache a servir um misto de conteúdos estáticos e dinâmicos, em comparação com outros webservers nas mesmas condições (de hardware, clientes, conteúdo, etc.). O SpecWeb99 e' precisamente isso - ao contrario do que pensas inclui workload dinamico e as condicoes sao as mesmas - os clientes sao os mesmos, o conteudo e' o mesmo. So' o hardware e' que varia - e por isso e' que deves procurar hardware semelhante nos dados da Spec. Nao e' diferente dos benchmarks da TPC para bases de dados (que para ti tambem devem ser uma merda, so' os benchmarks favoraveis ao que tu dizes e' que te devem interessar). Portanto, vais ter de te esforçar mais para fazer vingar a tua ideia de que o Apache é fraco, se é que realmente essa tua convicção se baseia em factos, reais ou não, e não é apenas algo que sacaste do rabo Para, a serio -- ja' disseste o suficiente para se ver que o teu conhecimento destes assuntos e' profundo...
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | So' o hardware e' que varia - e por isso e' que deves procurar hardware semelhante nos dados da Spec.
Só o hardware é q varia... Tu és um comediante, leitão... Sem hardware equivalente qualquer interpretação dos resultados é falaciosa.
Quanto a procurar hardware equivalente para webservers distintos, procura lá, a ver se encontras...
ao contrario do que pensas inclui workload dinamico
Inclui CGI, mas o que diz isso da performance do Apache a servir, por exemplo, um misto de páginas estáticas e (mod_)PHP?
Para, a serio -- ja' disseste o suficiente para se ver que o teu conhecimento destes assuntos e' profundo...
Tu pareces os velhos a defenderem o seu clube numa discussão de tasca, muita presunção e poucos argumentos.
--
Carlos Rodrigues
|
| | | | | Só o hardware é q varia... Tu és um comediante, leitão... Sem hardware equivalente qualquer interpretação dos resultados é falaciosa. Quanto a procurar hardware equivalente para webservers distintos, procura lá, a ver se encontras... Vou-te deixar isso para trabalho de casa - usa la' este formulario e ve se e' dificil. Inclui CGI, mas o que diz isso da performance do Apache a servir, por exemplo, um misto de páginas estáticas e (mod_)PHP? Bom, considerando que o mod_php e' um modulo para o Apache, nao estou a ver de que forma e' que poderias comparar com seja la' o que for, mas pronto... Tu pareces os velhos a defenderem o seu clube numa discussão de tasca, muita presunção e poucos argumentos. Sim, que os teus argumentos claramente demonstraram seja la' o que for... Claro - porque es um daqueles zelotas do Apache de que falava ao principio. Vai falar com tipos que teem que manter server-farms de Apache's e ves exactamente se eles o acham divertido.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | | Vai falar com tipos que teem que manter server-farms de Apache's e ves exactamente se eles o acham divertido.
Então são burros. Já deviam ter mudado imediatamente para Zeus, por exemplo, que acabavam as dores de cabeça e tudo ficava bem..
Ah, claro, e só o dinheiro que gastariam caso tivessem 10 CPUs na FARM.. ou ainda, se usassem HyperThreading. Sim Senhor, sem dúvida uma excelente alternativa ao Apache!
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | Se for uma questão de capacidade adianta muito ser barato...
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | É o binómio/preço qualidade, digamos que patente em 90% das empresas. Claro que há outras que podem esbanjar quanto lhes apetecerem, mas não é esse o mercado alvo de que estava a falar.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | as decisões normalmente ponderam o preço/qualidade mas também outros factores, como por exemplo funcionalidade, performance, suportabilidade, etc. que podem fazer com que uma solução imbatível inicialmente (sem custo de aquisição e com qualidade) se torne mais onerosa depois de avaliar a solução completa tendo em conta o ciclo de vida projectado para ela.
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Tudo bem, mas não é o que acontece com 99% dos casos. Repara, basta ir ver as estatísticas da Netcraft para verificar que cada vez mais gente gosta do Apache e menos de todos os outros web servers. Isto revela que no binómio qualidade/preço o Apache não tem qualquer rival à altura.
Agora, se tirares o factor preço, até acredito que o Zeus tenha mais funcionalidades/performance/fiabilidade, whatever. Só que quem precisa desses factores extras e pode dispender valores absurdos como os que eles cobram são... 0.001% ? Para todos os outros, Apache serve e muito bem.
A adicionar o facto de que as actualizações da Zeus custam dinheiro, o que é um valor acrescido num projecto que como tu referes poderá ser a longo prazo.
Mas pronto, também questiono os tais 0.001%. Veja-se o caso da eBay que dia sim, dia não, trocam de web server. Já foi Sun, já foi Zeus, e agora passaram de Windows 2003 Server (IIS 6) para Windows 2000 (IIS 5) :-)
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | | Tudo bem, mas não é o que acontece com 99% dos casos. Repara, basta ir ver as estatísticas da Netcraft para verificar que cada vez mais gente gosta do Apache e menos de todos os outros web servers. Isto revela que no binómio qualidade/preço o Apache não tem qualquer rival à altura. Nao, o que quer dizer e' que cada vez mais FQDN's retornam um header do Apache. Mais nada. Se olhares para as estatisticas da Netcraft com olhos de ver (e nao com olhos de vires defender o Apache) vais reparar em tres coisas: - Os ganhos do Apache nao sao em relacao a outros servidores, mas por crescimento do numero de dominios questionados pela Netcraft,
- O total de dominios a correr em Zeus+IIS praticamente nao mudou desde 2000,
- As estatisticas para servidores SSL (ou seja, servidores de sites de e-commerce) sao muito diferentes.
Ou seja - o que as estatisticas da Netcraft dizem e' mais nada mas que existem montes de servidores "de garagem" a correr Apache. Mais nada. Agora, se tirares o factor preço, até acredito que o Zeus tenha mais funcionalidades/performance/fiabilidade, whatever. Só que quem precisa desses factores extras e pode dispender valores absurdos como os que eles cobram são... 0.001% ? Para todos os outros, Apache serve e muito bem. Claro que serve - ve la' que ate' eu corro Apache no servidor em casa! Mas isso nao faz o software melhor - o Apache em termos de qualidade de software e usabilidade, e' quer gostes ou nao, do piorzinho que se arranja. Basta pensares no pesadelo que e' o httpd.conf. adicionar o facto de que as actualizações da Zeus custam dinheiro, o que é um valor acrescido num projecto que como tu referes poderá ser a longo prazo. Nao desinformes, que estas a inventar -- e nao te esquecas que trabalhei la'... Veja-se o caso da eBay que dia sim, dia não, trocam de web server. Já foi Sun, já foi Zeus, e agora passaram de Windows 2003 Server (IIS 6) para Windows 2000 (IIS 5) :-) Ja' deves ter ouvido falar em coisas como reverse proxies, nao ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | | Repara, basta ir ver as estatísticas da Netcraft para verificar que cada vez mais gente gosta do Apache e menos de todos os outros web servers. Aproveito para acrescentar que as estatísticas também dizem que o Windows é o desktop mais usado. Deves crer então que é a melhor escolha para desktop. O total de dominios a correr em Zeus+IIS praticamente nao mudou desde 2000 Pela ideia que tenho, penso que tem até havido um crescimento do IIS desde lançamento do o Windows 2003... As estatisticas para servidores SSL (ou seja, servidores de sites de e-commerce) sao muito diferentes. Mas os servidores SSL são uma fracção do mercado de host, facilmente constatável pelo requisito de ip por domain, o que entra em colisão com muitos sistemas de alojamento vhost mais económicos. Claro que serve - ve la' que ate' eu corro Apache no servidor em casa! Mas isso nao faz o software melhor - o Apache em termos de qualidade de software e usabilidade, e' quer gostes ou nao, do piorzinho que se arranja. Basta pensares no pesadelo que e' o httpd.conf. Não questiono que o Apache é apenas mediano no universo de WebServers, mas não concordo com o que afirmas sobre o httpd.conf. É muito mais complicado meter um IIS 5.0 a funcionar de forma minimamente segura do que um Apache, para a maioria dos casos. Além disso, a documentação disponível é excelente. Não obstante (e por muito que doa aos zealotas do apache), o Apache, apesar de popular, não possui features "enterprise", nomeadamente a nível de fault-tolerance e load-balancing. As aplicações "enterprise" com Apache limitam-se a grupos de servers com sites montados em shares NFS com reverse proxy a fazer de load balancer foleiro. Se se precisar de uma solução fault-tolerant, com sessões cluster-wide, o apache pura e simplesmente não está lá. E isso é essencial em aplicações críticas, nomeadamente e-commerce (à escala do ebay, por exemplo).
|
| | | | | "Não obstante (e por muito que doa aos zealotas do apache), o Apache, apesar de popular, não possui features "enterprise", nomeadamente a nível de fault-tolerance e load-balancing." Não me considerando z-e-l-o-t-a, e muito menos fariseu, o Apache não possui "features enterprise", seja lá o que isso for, porque é um software web, não de clustering. "As aplicações "enterprise" com Apache limitam-se a grupos de servers com sites montados em shares NFS com reverse proxy a fazer de load balancer foleiro. Se se precisar de uma solução fault-tolerant, com sessões cluster-wide, o apache pura e simplesmente não está lá. E isso é essencial em aplicações críticas, nomeadamente e-commerce (à escala do ebay, por exemplo)." Ora diz-me lá o que já pesquisaste para dizer que a coise se limita a shares NFS e reverse proxy.
Tonidosimpostos: "a firewall mais segura que conheço é o cinto de castidade!" |
| | | | | Não me considerando z-e-l-o-t-a, e muito menos fariseu, o Apache não possui "features enterprise", seja lá o que isso for, porque é um software web, não de clustering. Não leves tão a peito a minha afirmação. Eu também uso o Apache e gosto muito dele. Para o que preciso, serve perfeitamente, mas o facto de ser um Webserver não quer dizer que não possa ter features de redundância. Eu acho inútil a comparação com o Zeus quando os targets de mercado do Apache e do Zeus são, regra geral, diferentes. Ora diz-me lá o que já pesquisaste para dizer que a coise se limita a shares NFS e reverse proxy. Agradeço que me indiques então uma solução de load-balancing para Apache que mantenha sessões entre máquinas de forma transparente, sem precisares de modificar aplicações web a serem corridas no apache, e/ou andares a inventar fortemente no sistema operativo.
|
| | | | Não levei a peito :-). Manter sessões não é transparente, tens que guardar informação algures e isso podes fazer com uma BD. Mas conjugar software de clustering como Ultramonkey, Super Sparrow, LVS ou OpenMosix, com Apache e JServ (não sei se entretanto apareceu algo melhor que o JServ, além deste limitar o espectro de utilização), pode ser uma solução interessante.
Esta página é relativa a parte dos projectos que mencionei.
Tonidosimpostos: "a firewall mais segura que conheço é o cinto de castidade!" |
| | | | As estatisticas para servidores SSL (ou seja, servidores de sites de e-commerce) sao muito diferentes.
Por acaso eu gostava de ver essas estatísticas, uma vez que não estão disponíveis publicamente. Ou vou ter simplesmente de acreditar porque tu o dizes?
--
Carlos Rodrigues
|
| | | | | Ah, para quem não tenha reparado, estas estatísticas têm um ano.
--
Carlos Rodrigues
|
| | | | | Yada, yada, yada...
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | achas o httpd.conf complicado??? OMG, é o fim do mundo :\
---
Este espaço pode ser seu... |
| | | | Aqui sou obrigado a concordar com o Leitão, o httpd.conf é um prato de esparguete sem ponta por onde se lhe pegue!
A última versão que experimentei num computador em casa foi a 2.0.50 que vem com o ubuntu e a coisa está um pouco mais organizada, mas infelizmente acho que não é mérito do httpd.conf mas dos gajos que fizeram o pacote para o ubuntu que criaram directorias onde se coloca ficheiros individuais para os virtualhosts e outra onde se colocam os ficheiros com as configurações por módulo, etc... (mas eles estão só a usr esses ficheiros como includes para organizar a esparguetada que é o httpd.conf).
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| | | | Epá, desculpa mas aí a culpa é tua. O que eles fazem (Debian ou Ubuntu) é o que tu já devias saber que dá para fazer: includes.
---
Este espaço pode ser seu... |
| | | | Bem, gostava de saber que casos de exemplo de server farms de apache conhecem... No verdadeiro sentido da palavra. Racks de servidores com reverse proxy em round-robin não contam.
Ah, claro, e só o dinheiro que gastariam caso tivessem 10 CPUs na FARM.. ou ainda, se usassem HyperThreading. Sim Senhor, sem dúvida uma excelente alternativa ao Apache! Se as vantagens do Zeus significassem menos um engenheiro a tomar conta das coisas, e assumindo que o engenheiro recebia 300 cts brutos, ao fim de um ano eram... 300*14=4200cts que não se gastavam. Por quanto fica o Zeus para os 10 cpu's? Humm para maquinas de 2 vias fica por 1650 Eur... Ou seja, os tais 4200 cts davam para comprar 12 licenças de 2 cpus...
|
| | | | Bem, gostava de saber que casos de exemplo de server farms de apache conhecem... No verdadeiro sentido da palavra. Racks de servidores com reverse proxy em round-robin não contam.
Ah, claro, e só o dinheiro que gastariam caso tivessem 10 CPUs na FARM.. ou ainda, se usassem HyperThreading. Sim Senhor, sem dúvida uma excelente alternativa ao Apache! Se as vantagens do Zeus significassem menos um engenheiro a tomar conta das coisas, e assumindo que o engenheiro recebia 300 cts brutos, ao fim de um ano eram... 300*14=4200cts que não se gastavam. Por quanto fica o Zeus para os 10 cpu's? Humm para maquinas de 2 vias fica por 1650 Eur... Ou seja, os tais 4200 cts davam para comprar 12 licenças de 2 cpus...
Nota: se isto aparecer duplicado, não se admirem. Não são copos a mais , é o maravilhoso mundo Gildot!
|
| | | | Aparentemente, segundo o artigo, a questão é que o apache faz uso de threads nativas, e como tal está limitado pelas restrições do SO.
O Erlang implementa ele proprio a concorrencia, sem threads nativas do SO, e como tal não está limitado desta forma.
Note-se que a unica coisa que se testou foi a capacidade de responder a MUITAS sessões concorrentes de páginas estáticas. Não sei se nesta aplicação o Apache seria a melhor opção (penso que para isto um "light-weight server" se comportaria melhor).
Cumps, JB .. acusaram-O de pirataria, por ter duplicado uma cesta de pão e cinco peixes, e disseram: crucifiquem-No .. (Biblia do Século XXI) |
| | | | | | para conteudo estático, o apache não é terrivelmente rápido.
o interessante deste outro servidor é a utilização distribuida de forma transparente (ou assim parece o súmario). no outro dia li opiniões interessantes de como as coisas vão virar para sistemas multiprocessador, uma vez q os GHZ já não dizem muito para a taxa de utilização de um sistema. e para dual core/o novo cell da ibm, as técnicas de programação não se adequam e vão ter que mudar.
tempos interessantes ;)
alguém sabe mais?
-----
Windows isn't done until Lotus won't run. |
| | | | uma vez q os GHZ já não dizem muito para a taxa de utilização de um sistema
Quando comprei o meu velhinho Pentium 100 com 16Mb de RAM já se dizia o mesmo, e hoje o trabalho de router e servidor de impressão é das poucas coisas que ainda consegue fazer.
--
Carlos Rodrigues
|
| | | | talvez, mas segundo a minha memória n tinhas q ter 3 ventoinhas a fazerem a barulheira que fazem agora (não, não compro um apple) nem fontes de 400 watts. os gastos de energia+gastos em ar condicionado+barulho das ventoinhas+espectativa de fazer várias tarefas ao mesmo tempo sem perder imenso em task-switching = problema.
IMHO. pelo menos em x86, o powerpc parece estar bem...
-----
Windows isn't done until Lotus won't run. |
| | | | um P100 ainda e' uma boa maquina e serve para muito mais do que simples router...
simples, tenta usar ou versoes mais antigas das coisas, ou melhor, programas diferentes, existem muitos por ai que sao feitos para serem mais leves (mais limitados, mas tambem nao contas correr um sevidor de web gigante la', ne'!)
podes ter pouca memoria, mas ele ainda se safa bem... nao contes tambem ter e' 20 sites la', claro esta' 8)
Higuita |
| | | | Eu sei que serve, mas apenas para trabalhos caseiros e leves.
Actualmente aquilo é um P133 com 96Mb de RAM e serve de firewall/router/shaper, dhcp, DNS, print server (cups/raw), scan server (sane - que agora se recusa a funcionar, não sei porquê) e apache+php+vsftpd (para uso interno esporádico).
--
Carlos Rodrigues
|
| | | | | Pode ser muita coisa.
O único resultado visivel é o gráfico throuput vs requests. O que se observa é que para poucos pedidos/segundo, tanto o Apache[1] como o yaws respondem com o ~800kB/s. Com mais pedidos, o Apache[1] começa a responder com _menos_ enquado o yaws se mantém pelos ~800kB/s. Ou seja, o Apache entra em DoS. Enfim, um benchmark idiota. [1] O Apache parece ter sido configurado com 250 threads. Além de não sabermos que versão de pthreads está a usar (linuxthreads ou nptl), também seria interessante ver o que _menos_ threads podem fazer.
|
| | | | Já agora, existem mais que uma implementação de Erlang. Parece-me que algumas usam pthreads, outras não. Também convinha saber qual foi usada.
|
| | | | | O Erlang implementa ele proprio a concorrencia, sem threads nativas do SO, e como tal não está limitado desta forma. O que me suscita uma dúvida... Como é que o Erlang se porta em sistemas SMP? Parece-me que uma das vantagens de utilização de linuxthreads, por exemplo, é a possibilidade de spawning para múltiplos cpu's. Além disso, existem arquitecturas em que a atribuição de cpu é per-process, ou seja, aplicações multiprocesso podem executar em vários cpu's simultaneamente, mas o mecanismo de thread tem afinidade ao processo, corre apenas em 1 cpu num dado instante. Alguém tem mais detalhes sobre isso?
|
| | | | Ainda sou novo nisto, mas por aquilo que andei a ler, o Erlang não possui threads (já há algumas tentativas para as emular) mas apenas processos.
Básicamente podes correr uma Erlang virtual machine a que se chama node ou nó. Um sistema distribuido em Erlang básicamente é uma rede de nós (típicamente 1 por processador, mas podem ser vários).
Um nó Erlang pode criar processos paralelos a correr noutros nós que talvez até possuam outros sistemas operativos. Os processos de diferentes nós comunicam da mesma forma como se tivessem no mesmo nó.
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | | Sem querer ser picuinhas, o que foi usado foi um modelo misto multi-process/multithread. São utilizadas várias threads por processo para optimizar o desempenho e vários processos para não comprometer a estabilidade. Estou de certa forma a reiterar a dúvida que expus num post abaixo, mas a arquitectura mista do apache2 parece ser muito mais vocacionada para sistemas SMP do que para máquinas com apenas 1 cpu. Seria interessante ver a comparação num sistema SMP.
|
| | | | Acho que não percebeste o que escrevi. No Erlang não existem threads só processos. Estes processos possuem um tamanho mais pequeno que os do sistema operativo e ainda mais pequenos que as threads.
Talvez se leres o White Paper do Erlang talvez fiques a perceber o seu funcionamento.
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| | | | Eu já tinha visto isso. Quando falei em threads/processes não me estava a referir a funcionalidades do Erlang, mas á execução em si. A API de lightweight processes, segundo percebi, está disponível apenas em aplicações escritas Erlang. Para o SO de host, onde estás a executar a aplicação, é apenas mais um processo em execução. A questão é se o mecanismo de lightweight process do Erlang é, na perspectiva do sistema operativo, apoiado por abordagem multiprocesso ou multithread, tendo ambas influência no que toca a SMP. Ou seja, imagina que tens um API todo giro de lightweight processes para userland, mas a aplicação que o vai usar é monoprocesso, e vais correr isso em OpenBSD com SMP, por exemplo. O que vai acontecer é que o processo vai correr só num CPU, ficando o outro eventualmente idle. A minha dúvida era se a virtual machine (que providencia o API) onde corres as aplicações é multithread ou multiprocesso, ou nenhuma das duas :)
|
| | | | No JAM/HiPE (o emulador aberto), cada node é um _processo Unix_ com uma única _thread Unix_ que pode correr vários _processos Erlang_, utilizando multitasking cooperativo. Para tirares partido de múltiplos CPUs, tens que correr vários nodes na mesma máquina (a comunicação entre _processos Erlang_ no mesmo node, em nodes diferentes ou até em nodes em máquinas diferentes é transparente, excepto pela diferença de performance).
No Erlang Compiler, cada node é um _processo Unix_ em que cada _processo Erlang_ é uma _thread POSIX_.
|
| | | | Danka era isso mm que queria saber!
|
| |
|
