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 <[email protected]> > 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 <[email protected]> > >> 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 >> On Sep 10, 2012 9:29 PM, "Hugo Ferreira" <[email protected]> wrote: >> >>> 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. >>> >> -- >> 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.
