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.
