AMFPHP 2.1 - performance (ou falta dela)

78 views
Skip to first unread message

Miguel Vaz

unread,
Sep 10, 2012, 1:19:50 PM9/10/12
to ri...@googlegroups.com
Boa tarde,

Realizei alguns testes ao nivel do AMFPHP e estou a ter alguma (demasiada) lentidão na recepção dos dados.
O código de testes é um mero remoteobject directo com um serviço em PHP que envia resultados de um query numa BD MySQL para o Flex. Tenho um button que faz trigger à chamada e ao timer e um método de retorno para popular uma datagrid (não interfere na performance..).

resultados:

- O tempo da query (tem cerca de 4500 registos) ronda os 0,26s
- O tempo de método no PHP ronda os 0,5s
- O tempo entre clique na aplicação Flex e retorno dos dados é de quase 5s

Testei uma query de apenas um elemento e o tempo total (do clique no botão ao retorno do serviço) é quase imediato (<1s), o que me leva a apontar o dedo ao tempo de serialização, ou do AMFPHP ou no Flex - não consigo identificar o culpado.

Aborrece-me considerando que não é falta de optimização de código ou query, mas apenas algo no Flex ou AMFPHP.

Alguém tem algum problema de performance com AMFPHP? Já notaram esta situação? Dicas? Sugestões? Já tenho as chamadas a utilizar VOs (que embora boa prática praticamente não interfere com os tempos)

Obrigado.

Miguel Vaz

hferre...@gmail.com

unread,
Sep 10, 2012, 1:34:00 PM9/10/12
to ri...@googlegroups.com
Humm, estranho.
Uso o amfphp à muito tempo e acho-o bastante rápido.
5s para 4500 registos não é muito tempo, é uma eternidade. Não é aceitável.

O teste de 1 registo não prova nada porque não é quantificável.
Será algum problema na estrutura e dependência do teu vo ?

Como sugestão podes utilizar uma ferramenta como o charles para saber precisamente o tempo que dura a tua chamada e fazer alguns testes mas partilha aí o teu vo completo.

Enviado do meu iPad 3
--
Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google.
Para publicar uma mensagem neste grupo, envie um e-mail para ri...@googlegroups.com.
Para anular a inscrição neste grupo, envie um e-mail para riapt+un...@googlegroups.com.
Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.

João Fernandes

unread,
Sep 10, 2012, 1:34:57 PM9/10/12
to ri...@googlegroups.com
Nunca usei AMFPHP mas se fosse a ti analisava com o charles proxy o tempo de resposta do servidor relativamente a esse request.
O problema poderia ser do flex caso te indicasse que o tempo de resposta do servidor fosse o caso mas caso não se confirme, poderá ser sim da conversão de objectos PHP para AMF bytecode.

Sei que no CF por exemplo existiram várias melhorias relativas ao melhoramento da serialização/deserialização tais como:
Substituir AS > JAVA > CF por AS > CF
Uso do scope "This" em vez de getters/setters
Uso de objectos anónimos em vez de converter a query para uma lista de objectos que posteriormente teriam de ser convertidos para AMF.

Certamente existirão formas de melhorar o desempenho de resposta mas com AMFPHP desconheço para te ser sincero. Talvez o João Saleiro te consiga ajudar (ou outros que tenham experiência com AMFPHP).

2012/9/10 Miguel Vaz <pago...@gmail.com>

Miguel Vaz

--
Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google.
Para publicar uma mensagem neste grupo, envie um e-mail para ri...@googlegroups.com.
Para anular a inscrição neste grupo, envie um e-mail para riapt+un...@googlegroups.com.
Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.



--

João Fernandes

Miguel Vaz

unread,
Sep 10, 2012, 2:00:12 PM9/10/12
to ri...@googlegroups.com
Obrigado pelas respostas.

O teste que descrevi é devidamente acompanhado pelo Charles, que reporta um tempo de 4.7s na mesma chamada.

Permite-me discordar sobre o que dizes sobre o teste de uma query com apenas 1 registo. Considero importante já que, embora não seja quantificável como query, é-o como teste de tempo de serialização pelo número de registos. Ou seja, se o número de registos muda, o tempo altera-se drasticamente, o que deveria demonstrar (ou refutar) algo - que infelizmente ainda não sei o quê. :-P

O meu VO é simples:

PHP

<?php
    class voEmail {
        public $id_email;
        public $email;
        public $nome;
public $id_user;
public $obs;
    }
?>

Flex:

package vo
{
[Bindable]
public class emailVO
{
public var id_email:int;
public var id_user:int;
public var nome:String;
public var email:String;
public var obs:String;
}
}

Pelos testes, parece-me seguro inferir que o problema está na serialização, algures no AMFPHP ou já no Flex. Agora acho absurdo acontecer num projecto limpo. E já testei em ambiente de desenvolvimento local(windows, etc) e produção (linux, etc.) com os mesmos resultados/problemas.



Miguel Vaz



2012/9/10 João Fernandes <joaopedromar...@gmail.com>

João Fernandes

unread,
Sep 10, 2012, 2:08:52 PM9/10/12
to ri...@googlegroups.com
Se o charles te indica 4.7 s então o problema encontra-se server-side pois o charles analisa o tempo de resposta do servidor e não consegue medir a parte de serialização por parte do flash player.

Existe algum programa de profiling para PHP? Sem dúvida seria onde eu iria dedicar o meu tempo, nada como um bom profiler para encontrar o código culpado.

João Fernandes

2012/9/10 Miguel Vaz <pago...@gmail.com>



--

João Fernandes

Miguel Vaz

unread,
Sep 10, 2012, 2:24:23 PM9/10/12
to ri...@googlegroups.com

Sim, entendo. Mas o AMFPHP não funciona a nível de servidor? O argumento é correcto, o Charles não analisa o tempo de flex.
Não existe a necessidade de um profiler, o meu método no PHP tem um timer interno também, conforme referi, que marca apenas 0.5s desde a chamada da função à linha antes do return.

Posso executar o método directamente no servidor e medir o tempo...ora 1 minuto e vai já o resultado neste e-mail: 

- Se executar o método directamente, o resultado é de 0.57s. O problema encontra-se no AMFPHP, portanto. Agora onde exactamente... parece-me que o amfphp está com dificuldade em "digerir" os registos - quantos mais forem, mais lento fica.

Nenhuma outra sugestão?

João Fernandes

unread,
Sep 10, 2012, 2:36:51 PM9/10/12
to ri...@googlegroups.com
Miguel por isso é que te referi um profiler pois este vai analisar todo o codigo que é executado (incluindo o do AMFPHP) e vai te descriminar o tempo que leva a executar cada função.

2012/9/10 Miguel Vaz <pago...@gmail.com>



--

João Fernandes

Miguel Vaz

unread,
Sep 10, 2012, 2:38:19 PM9/10/12
to ri...@googlegroups.com

Testei a performance da minha classe e métodos de teste com o Service Browser do AMFPHP e levo com um 0.279s. Que raio se passa aqui? É na serialização, conversão, transmissão, navegação, código após PHP e até chegar ao Flex.

MV



2012/9/10 Miguel Vaz <pago...@gmail.com>

Miguel Vaz

unread,
Sep 10, 2012, 2:48:23 PM9/10/12
to ri...@googlegroups.com
Muito obrigado pelas respostas. Vou-me entreter a encontrar um profiler que faça o ..profiling de PHP e amfphp.




MV





2012/9/10 João Fernandes <joaopedromar...@gmail.com>

Hugo Ferreira

unread,
Sep 10, 2012, 4:29:47 PM9/10/12
to ri...@googlegroups.com
Boa noite Miguel,

Tenho uma aplicação em Flex com backend em PHP e utiliza SSL em que numa rotina específica posso trazer muitos registos do servidor remoto.
O VO em causa tem 10 variáveis que mapeiam para 10 campos na tabela e várias propriedades para dados "virtuais".

Testei com o meu utilizador e no Charles ficou registado 2708 vo's e um custo total de tempo 1.1 segundos e seguindo uma regra de 3 simples, demoraria 1.8 segundos a transmitir 4500 registos portanto tem de haver ai outro problema.

A minha dica cá vai :)
Eu uso o amfPHP 1.9 Legacy e tu está a utilizar o amfPHP 2.1 Generator.

Se for o caso de algum problema de microsegundos na performance do amfPHP 2.0 ou 2.1, isso poderá traduzir-se nesses segundos a mais em 4500 registos. No meu projecto, utilizo o amfPHP 1.9, pelo talvez valha a pena investires algum tempo testado com esta versão para despiste do amfPHP e por favor depois partilha os resultados :)

Nunca cheguei a actualizar o amfPHP para a versão 2.0 por diversas razões:
  • Havia algum problema específico com a versão 2.0 que é um grande refactoring da versão 1.9 (não me lembro agora qual era o problema mas sei que era impeditivo de migrar num projecto já grande e em produção, se calhar até foi da performance mas muito sinceramente não me lembro)
  • O amfPHP tem uma função muito específica e cumpre todas as necessidades actuais e futuras pelo que o risco de migração no meu caso não fez sentido
  • Tenho o actual amfPHP 1.9 bastante customizado por mim ao longo dos tempos :D
Quando à versão 2.1, talvez um dia possa testar e ver se traz benefícios na migração mas para mim só se tiver muito melhor performance, o que acho um pouco díficil.


Cumps,
Hugo.

Miguel Vaz

unread,
Sep 10, 2012, 9:14:35 PM9/10/12
to ri...@googlegroups.com

Boa noite, Hugo,

Teoricamente a nova versão deveria melhorar um pouco a performance, mas é como disseste, convém testar a versão anterior para remover essa variável.

Neste momento não estou no serviço...bem, são duas da manhã, mas amanhã vou fazer mais esse teste e escrevo novamente com os resultados.

Entretanto estive a procurar um profiler, no seguimento da sugestão do João, e também deixarei eventuais comentários sobre isso. Embora tenha alguma dúvida, já que se a má performance não é directamente no flex ou na minha classe/método, se for no amfphp, não existe muito que possa fazer - a não ser provavelmente utilizar outra versão, se resolver.

Nestas situações imagino que poderão existir vários factores que degradem a performance, mas se, hipoteticamente, duas iterações de uma aplicação degradam essa performance, era de existir mais gente a queixar-se. Ou até a própria silex (hm, acho que é o nome correcto da empresa do amfphp) detectar problemas. A performance é um ponto fulcral desta aplicação.

Espero que a versão 1.9 resolva, hugo. :-) Muito obrigado pelo email. Independentemente do resultado, deixarei aqui novo email para futuros utilizadores com situações semelhantes.

Miguel

João Fernandes

unread,
Sep 11, 2012, 5:52:07 AM9/11/12
to ri...@googlegroups.com
Se o profiler funcionar como suposto, ele poderá indicar-te onde está a perder tempo dentro do AMFPHP, e suponho que este seja OpenSource certo? Por isso poderia ser possivel alterar o código original para melhorar o seu desempenho.



2012/9/11 Miguel Vaz <pago...@gmail.com>

Boa noite, Hugo




--

João Fernandes

Miguel Vaz

unread,
Sep 11, 2012, 11:16:25 AM9/11/12
to ri...@googlegroups.com

Boa tarde,

Ainda não consegui utilizar um profiler que fizesse a análise com sucesso, mas segui o conselho do hugo e instalei a versão 1.9 do amfphp. Enfim, os tempos são ridiculamente inferiores.
O mesmo processo leva menos de 1s, a contar do clique ao display dos registos. Não consigo entender qual poderá ser o problema. Não encontro este tipo de queixas (2.0/1 mais lento que 1.9) em nenhum lado.
Quando tiver mais disponibilidade ainda regressarei ao profiling para tirar dúvidas, mas para já vou ficar pelo 1.9 que me garante uma performance definitivamente mais aceitável que versões superiores. É necessário um profiler que não dependa do IDE ou de execução directa do script PHP. Ainda tentei instalar o xdebug mas, embora a extensão fique activa, não consigo que funcione correctamente.

Já agora: Recordo-me que existia uma extensão para o php que tornava o amfphp ainda mais eficiente, recordam-se? Cheguei a utilizar numa outra empresa e tenho ideia que reduzia um pouco o tempo de processamento, mas não encontro nos meus backups. Alguém a utiliza? Poderiam enviar-me? hugo? Chamava-se AMFEXT mas não encontro site para download.

Muito obrigado por toda a ajuda.


Miguel




2012/9/11 João Fernandes <joaopedromar...@gmail.com>

hferre...@gmail.com

unread,
Sep 11, 2012, 2:16:21 PM9/11/12
to ri...@googlegroups.com
Boa tarde,

"Não encontro este tipo de queixas (2.0/1 mais lento que 1.9) em nenhum lado"
Suponho que a maioria começou no 2.0 ou tem projectos pequenos ou o seu grau de exigência seja baixo.
A versão 1.9 foi bem desenvolvida e já fazia tudo o que era suposto fazer para algo tão concreto e na altura pelos meus testes, fiquei com a sensação que a v2.0 mais parece que foi um refactoring feito por teóricos (que medo para se usar num projecto comercial).

"Quando tiver mais disponibilidade ainda regressarei ao profiling para tirar dúvidas, mas para já vou ficar pelo 1.9 que me garante uma performance definitivamente mais aceitável que versões superiores"
Sem dúvida e pelos visto a v2.1 não é melhor que a v2.0 pelo que nem vou investir tempo nessa versão também.

"Chamava-se AMFEXT mas não encontro site para download"
Muito bom. Desconhecia e é algo que vale a pena investigar um dia destes pois a performance e segurança são muito importantes mas encontrei aqui as instruções para instalar esse módulo: http://amfphp-v1.silexlabs.org/docs2/amfext.html

Enviado do meu iPad 3

Miguel Vaz

unread,
Sep 11, 2012, 2:36:28 PM9/11/12
to ri...@googlegroups.com
Boa tarde,

O link para o AMFEXT também conheço, tanto esse como uns quantos outros. O problema é onde fazer download. Encontro a source, mas, além de não saber por onde começar, não tenho tempo para investir e compilar uma versão para windows. Conforme referi, recordo-me que a extensão ajudava um pouco a performance, por isso não perdia nada. Vou procurar em backups mais antigos a ver o que encontro. :-)

Deixei um post no forum da silexlabs e sugeriram remover plugins e fazer alguns testes. Pelo que tentei até agora, retirando alguns plugins, reduzi o tempo em cerca de 1s (a chamada fica nos 3s), mas vamos ver o que acontece. Disseram que as diferenças nesta versão 2.x é estrutural, que faz algumas optimizações em largura de banda (logo perdendo algum tempo, mas nada significativo). Continuo sem entender.



MV


Sandrio Fontes

unread,
Sep 11, 2012, 9:12:27 AM9/11/12
to ri...@googlegroups.com
Boa tarde Miguel

Como profiler podes utilizar uns dos dois seguintes: XHProf ou Xdebug.

O XHProf é mais fácil de utilizar mas o Xdebug faculta informação mais detalhada.

Cumprimentos,

Sandrio Fontes







2012/9/11 Miguel Vaz <pago...@gmail.com>

João Cardoso

unread,
Sep 18, 2012, 4:11:07 PM9/18/12
to ri...@googlegroups.com
pelo que li da extensao que falas, tens que instalar isto pelo pecl, ou seja pelo package manager do php. e depois activar no php.ini
Reply all
Reply to author
Forward
0 new messages