Re: [androidbrasil-dev] Comunicação Cliente - Servidor

Acredito que tanto upgrades verticais quanto horizontais fariam
diferenças significativas num ambiente apache + php dependendo do tipo
de setup feito no apache.

O apache 2 é multithreaded e, o php, se instalado com a libphp, que é
um módulo do apache, suportaria threading também, o que, se, no caso
de um upgrade de processador com mais cores, beneficiaria o setup.

Memória, tudo depende do tipo de aplicação em questão, como os scripts
em PHP são short lived, ou seja, executam e morrem, raramente precisam
de muita RAM, o que pode ser feito é uma otimização no apache a fim de
limitar ou aumentar a quantidade de threads e requests por thread e a
quantidade de processos filhos que ele sobe inicialmente e qual o
máximo de quantidade de threads ele aguentaria, o que, sinceramente
consegue-se uma performance absurda.

Tudo isto poderia beneficiar-se de um upgrade de RAM, dependendo da
quantidade de memória definida por processo do PHP.

Confesso que após vários projetos em Java. onde para a aplicação
funcionar, precisava-se de um app server, e, consigo uma série de
setups, tunning e ajustes de segurança, o Java e a JVM em si comem
muita RAM, já o PHP é mais flexível nesta parte, e, por isto, o custo
de hospedagem é mais em conta.

Acredito que não exista bom ou ruim, nem melhor ou pior, o que define
muito o ecossistema de uma empresa, e sua infra de TI é a vontade de
adotar-se um padrão de desenvolvimento e por isto optam homogenização
da tecnologia e com isso o Java sai em vantagem por estar presente em
várias plataformas, inclusive embarcados.

O PHP também está, mas, como é mais voltado para a Web, e, não tanto
para comunicações remotas, tais como CORBA, RMI, IIOP e afins, ele
acaba perdendo interesse das grandes empresas.

Temos muitos casos de uso, mas, falando mais do PHP, o Facebook, por
seguir uma linha mais voltada à Web, e também para webservices, deu um
jeito interessante de inovar o PHP criando o compilador HIP HOP, que
transforma os scripts em C puro, e também está adotando um mecanismo
de JIT (Just in Time Compiler) justamente para poder tirar o máximo do
proveito da velocidade de execução dos scripts.

Bacana divagar sobre isto por horas, mas, o foco da lista é Android,
peço desculpas pelo OT, mas acho legal que os desenvolvedores da
lista tenham um entendimento mais macro de um ambiente distribuído e
também não mitifique uma tecnologia X ou Y.

Eu sou partidário de que o melhor sistema ou tecnologia é aquele que
funciona e dá lucro, independentemente da quantidade de bugs,
problemas ou sequer arquitetura, e, muitas vezes algumas linguagens da
qual o desenvolvedor é mais familiarizado dá à ele a possibilidade de
transofrmar a idéia em algo real e concreto, a fim de depois se
preocupar com problemas dos quais todos nós gostaríamos de enfrentar,
se, é claro, o negócio realmente for algo viável!

Abraço,

Ernani

2013/2/4 Ricardo Othuki <othuki@gmail.com>:
> Escalabilidade vertical seria um Upgrade no servidor, como por exemplo, um
> processador mais rápido, mais memória, maior numero de "cores", etc.
> Sem entretanto aumentar o numero de servidores. Com Apache + PHP, este tipo
> de upgrade fara pouca diferença em casos de alta concorrência.
>
> Normalmente tenta-se um upgrade vertical (de menor custo) e ao atingir o
> limite, parti-se a horizontal, incluindo mais servidores para atender a
> demanda, com mais servidores tem-se a necessidade de um load-balance ou
> outras soluções que impactam diretamente nos custos.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Brasil - Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to androidbrasil-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.