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 No dia 11/09/2012, às 16:16, Miguel Vaz <[email protected]> escreveu: > > 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. -- 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.
