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. No dia 10 de Setembro de 2012 19:48, Miguel Vaz <[email protected]>escreveu: > 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 <[email protected]> > >> 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 <[email protected]> >> >>> >>> 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? >>> >>> Miguel Vaz >>> >>> >>> >>> >>> 2012/9/10 João Fernandes <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>>> 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 <[email protected]> >>>>> >>>>>> 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 <[email protected]> >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> [email protected]. >>>>>>> Para anular a inscrição neste grupo, envie um e-mail para >>>>>>> [email protected]. >>>>>>> Para ver mais opções, visite este grupo em >>>>>>> http://groups.google.com/group/riapt?hl=pt-PT. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> João Fernandes >>>>>> >>>>>> -- >>>>>> 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 >>>>>> [email protected]. >>>>>> Para anular a inscrição neste grupo, envie um e-mail para >>>>>> [email protected]. >>>>>> Para ver mais opções, visite este grupo em >>>>>> http://groups.google.com/group/riapt?hl=pt-PT. >>>>>> >>>>> >>>>> -- >>>>> 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 >>>>> [email protected]. >>>>> Para anular a inscrição neste grupo, envie um e-mail para >>>>> [email protected]. >>>>> Para ver mais opções, visite este grupo em >>>>> http://groups.google.com/group/riapt?hl=pt-PT. >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> João Fernandes >>>> >>>> -- >>>> 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 >>>> [email protected]. >>>> Para anular a inscrição neste grupo, envie um e-mail para >>>> [email protected]. >>>> Para ver mais opções, visite este grupo em >>>> http://groups.google.com/group/riapt?hl=pt-PT. >>>> >>> >>> -- >>> 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 >>> [email protected]. >>> Para anular a inscrição neste grupo, envie um e-mail para >>> [email protected]. >>> Para ver mais opções, visite este grupo em >>> http://groups.google.com/group/riapt?hl=pt-PT. >>> >> >> >> >> -- >> >> João Fernandes >> >> -- >> 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 >> [email protected]. >> Para anular a inscrição neste grupo, envie um e-mail para >> [email protected]. >> Para ver mais opções, visite este grupo em >> http://groups.google.com/group/riapt?hl=pt-PT. >> > > -- > 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 > [email protected]. > Para anular a inscrição neste grupo, envie um e-mail para > [email protected]. > Para ver mais opções, visite este grupo em > http://groups.google.com/group/riapt?hl=pt-PT. > -- 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 [email protected]. Para anular a inscrição neste grupo, envie um e-mail para [email protected]. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.
