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
No dia 11 de Setembro de 2012 14:12, Sandrio Fontes <[email protected]>escreveu: > 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 <[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. >> > > -- > 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.
