Coded ui para medir o desempenho

5

Recebi a tarefa de usar a interface de usuário codificada para medir o desempenho em um aplicativo de área de trabalho proprietário do Windows . A necessidade é medir quanto tempo leva para a próxima página / tela ser exibida depois que um usuário clica em um controle.

Por exemplo, um usuário insere seus IDs e PWs e clica em entrar. A necessidade é medir quanto tempo leva para a próxima tela ser exibida quando o usuário clica no botão de login. Eu entendo a necessidade de definir o que indica que a tela está carregada e pronta para uso. Uma abordagem é usar control.WaitForControlReady e usar BeginTimer / EndTimer.

O código é ui uma maneira confiável e precisa de medir o tempo?
O WaitForControlReady é o melhor método para determinar quando um controle está pronto para uso?

    
por gnat 11.01.2012 / 02:02
fonte

1 resposta

1

Difícil: tempo total do log

Se você tiver um < script > seção no final da sua página HTML, ele não será executado até que o restante da página esteja totalmente carregado e provavelmente renderizado (mas verifique isso). Observe que o cliente e o servidor provavelmente não terão o mesmo horário, mas você pode ter um < script > tag no final do seu documento envia uma requisição AJAX de volta ao servidor com um token único embutido informando ao servidor, "Request (request-identifier) é completado e exibido pelo browser."

No lado do servidor, as solicitações que você deseja registrar teriam que colocar uma hashtable dos identificadores de solicitação e dos registros de data e hora originais na sessão do usuário. A mensagem "request-complete" desse usuário será incluída como uma nova solicitação, que deverá procurar o identificador de solicitação para a solicitação na sessão, obter o carimbo de data / hora inicial e gravar a diferença no tempo final menos a hora inicial. para um log ou qualquer outra coisa. Em seguida, deve remover esse identificador de solicitação da hashtable.

Na verdade, talvez seja necessário limpar o hashtable, especialmente se o usuário cancelar uma solicitação (ela nunca será concluída) ou desconectar-se ou apenas fechar o navegador. Além disso, se o usuário solicitar qualquer coisa que não termine no seu JavaScript, como imagens, páginas que você esqueceu de adicionar a tag, etc. Isso provavelmente não é algo que você deseja deixar em execução no código de produção.

Mais simples: tempo de solicitação de log e tempo de renderização separadamente

Algo mais fácil de medir e provavelmente tão útil de uma perspectiva de negócios é quanto tempo leva o servidor da Web para atender à solicitação. O principal método do nosso master-servlet começa com:

// Start timing the request
long startMs = System.currentTimeMillis();

E termina com:

long elapsedMs = System.currentTimeMillis() - startMs;

if (elapsedMs > LONG_TIME) {
    logger.error("Done REALLY SLOWLY: " + elapsedMs + "ms");
} else if (elapsedMs > PRETTY_LONG_TIME) {
    logger.warn("Done SLOWLY: " + elapsedMs + "ms");
} else {
    logger.info("Done: " + elapsedMs + "ms");
}

Agora, seu aplicativo registra em seu servidor erros para solicitações longas. Você pode até ter uma página com você se algo está lento! Para saber a diferença entre o tempo do navegador e o horário do servidor, basta usar as ferramentas incorporadas no Chrome ou no Firefox que mostram quanto tempo cada parte de uma construção de página demorou. Há um gráfico de cronograma e outras coisas legais embutidas lá.

Talvez, se você tiver um aplicativo totalmente AJAX, seja um problema, mas você pode criar esse mesmo tempo no servidor e enviar um resultado de tempo para o servidor.

    
por 07.09.2012 / 19:24
fonte