O ideal será sempre fazer profiling tanto à parte do front-end como do
backend para se identificar onde se encontram os blocos mais lentos. Por
exemplo em AMF, o ideal é devolver colecções de registos em Arrays em vez
de ArrayCollections, principalmente se existirem multiplos níveis de
hierarquia pois a deserialização de VOs mesmo que seja rápido no Flash
Player, quando são arrayCollections, estes terão de inicializar sempre o
seu processo de listeners, criar UIDs para os elementos etc. Nós em certas
áreas passamos de respostas de 3s para colecções muito pesadas para menos
de 200ms.

A nivel do PHP não sei que ferramentas poderás encontrar mas no que diz
respeito ao Flash podes (e deves) usar o Scout. Este dá-te informação
detalhada e consegues encontrar rapidamente a origem dos problemas.


2013/10/18 Hugo Ferreira <[email protected]>

> Então esses delays poderão não estar ao nível do amfphp mas sim a nível da
> tua lógica de backend ou mesmo BD.
>
> Tenho um caso em que o utilizador pressiona um botão numa app e é
> efectuado um pedido que tem de passar pelo meu backend (com amfphp) e ir a
> outra máquina via web services e tem de ser o mais rápido possível porque a
> lógica de negócio assim o exige. Se demorar mais de 3 segundos inviabiliza
> totalmente a após centenas de testes efectuados é sempre instantaneo (nunca
> chega a 1 segundo). Também estou a falar de servidores de topo, claro.
>
>
>
>
>
> No dia 18 de Outubro de 2013 às 11:37, Miguel Vaz 
> <[email protected]>escreveu:
>
>
>> Também tenho problemas de performance com a 2.x, estranhamente, mas mesmo
>> com a 1.9 tenho alguns delays que não consigo identificar. De qualquer
>> forma, estou disposto a mudar seja para o que for se aumentar a performance.
>>
>> Miguel
>>
>>
>> 2013/10/18 Hugo Ferreira <[email protected]>
>>
>>> Bom dia,
>>>
>>> Eu utilizo amfphp 1.9 (legacy). Quando a versão 2 saiu, fui logo testar
>>> e teve problemas de performance.
>>> A versão 1.9 tinha um problema com datas que eu corrigi do meu lado mas
>>> de resto serve muito bem o seu prepósito e cria o mínimo de resistência no
>>> processo.
>>>
>>> Em .NET usei fluorinefx.
>>>
>>>
>>> No dia 18 de Outubro de 2013 às 11:28, Miguel Vaz 
>>> <[email protected]>escreveu:
>>>
>>>> Bom dia,
>>>>
>>>> Considerando a thread anterior, que mostra que ainda existem pelo menos
>>>> uns 12 programadores em flex, qual é a vossa opinião/experiência com
>>>> comunicação flex<->BD(mysql,postgresql, etc)?
>>>>
>>>> tenho utilizado amfphp e weborb como interface entre a base de dados e
>>>> as aplicações flex, mas não estou completamente satisfeito com as
>>>> velocidades de resposta.
>>>>
>>>> Se não existirem condicionantes de tempo, servidor, qual é a tecnologia
>>>> mais rápida para este efeito? Há uns anos participei num projecto em que
>>>> essa comunicação assentava num tomcat+java e a resposta era extremamente
>>>> rápida, ainda há alguém que utilize este par?
>>>>
>>>> Muito 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 anular a subscrição deste grupo e parar de receber emails deste
>>>> grupo, envie um email para [email protected].
>>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>>> [email protected].
>>>> Visite este grupo em http://groups.google.com/group/riapt.
>>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>  --
>>> 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 anular a subscrição deste grupo e parar de receber emails deste
>>> grupo, envie um email para [email protected].
>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>> [email protected].
>>> Visite este grupo em http://groups.google.com/group/riapt.
>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> 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 anular a subscrição deste grupo e parar de receber emails deste
>> grupo, envie um email para [email protected].
>> Para publicar uma mensagem neste grupo, envie um e-mail para
>> [email protected].
>> Visite este grupo em http://groups.google.com/group/riapt.
>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>
>
>  --
> 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 anular a subscrição deste grupo e parar de receber emails deste
> grupo, envie um email para [email protected].
> Para publicar uma mensagem neste grupo, envie um e-mail para
> [email protected].
> Visite este grupo em http://groups.google.com/group/riapt.
> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>



-- 

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 anular a subscrição deste grupo e parar de receber emails deste grupo, 
envie um email para [email protected].
Para publicar uma mensagem neste grupo, envie um e-mail para 
[email protected].
Visite este grupo em http://groups.google.com/group/riapt.
Para mais opções, consulte https://groups.google.com/groups/opt_out.

Responder a