Mudanças entre as edições de "Approxima 1.0.0.74"

Edição das 20h28min de 23 de setembro de 2016

Sistemas Verificados

• Approxima, versão 1.0.0.74
• CoreSSO, versão 2.0.5.0
• CoreEdu, versão 0.0.0.4
• Approxima API, versão 1.0.0.74

Verificação de Segurança

Em verificação.

Verificação de Desempenho

Observações sobre o teste

O teste foi realizado para verificar a diferença/impacto da utilização do redis junto a aplicação. Para a realização dos testes foram utilizado:

• 1 Servidor SQL.
• 2 Servidores Web.
• 1 Test controller.
• 1 Test agent.

Durante a gravação dos cenários foram observadas diferenças no funcionamento da aplicação no ambiente de produção e o ambiente de teste. No ambiente de teste foi possível realizar redirecionamento e navegação do site sem utilização do usuário.

Além disso, foram encontrados alguns bugs na aplicação. Segue listagem abaixo:

1. Não possui validação caso o usuário que esteja acessando pelo core não for uma pessoa no Approxima.
2. Na home ("TimeLine") ao clicar em "Carregar itens" nada acontece quando o usuário logado é um aluno.
3. Exitem imagens que não existem na pasta mas são chamadas para aplicação (as mesmas foram adicionadas apenas no ambiente de teste):
   • /App_Themes/Approxima/style/iconfont/materialIcons/MaterialIcons-Regular.woff2
   • /Default/images/logos/213_logoImagemMenu.png
   • /Default/images/logos/logo-area-aluno.png
4. Ao clicar em "Nova enquete" o texto do botão cancelar está em caixa alta diferente do texto exibido em "Enviar".
5. Ao tentar cadastrar um comunicado preenchendo os campos e clicando em "Enviar" a página demora para redirecionar para as mensagens, dando a impressão da tela não estar funcionando.
6. Ao acessar a tela de criação de enquete e na seção de informação da enquete abrir o calendário e clicar na data previamente exibida e clicar fora do calendário a data fica em branco e nenhuma mensagem de validação é exibida.

Foi encontrado um erro intermitente no logout do sistema, o mesmo é salvo como erro "An item with the same key has already been added.", no log de erro os mesmos apontaram para:

• MSTech.CoreSSO.Web.WebProject.Logout.CreateSAMLResponse() in d:\b\MSTech SSO\CoreSSO_Main.Revision\src\MSTechSSO\Main\src\MSTech.CoreSSO.Web.WebProject\Logout.cs:line 244
• MSTech.CoreSSO.Web.WebProject.Logout.ProcessRequest(HttpContext context) in d:\b\MSTech SSO\CoreSSO_Main.Revision\src\MSTech SSO\Main\src\MSTech.CoreSSO.Web.WebProject\Logout.cs:line 72

Análise do teste

A utilização do redis possibilitou utilizar a aplicação com uma quantidade de erros inferior de erros de login, além da perda de sessão. Além foi observada uma melhora na performance no sistema como:

• Menor utilização de hardware.
• Melhoras no tempo de resposta.
• Quantidade maior de usuário logados simultâneos.

Durante a execução dos testes foram encontrados problemas na aplicação listadas abaixo:

• Não foi possível balancear a carga entre os dois servidores.
• Problemas de conexão da API com o banco de dados, que são os erros salvos como “The network path was not found”.
• Problemas de timeout.
• Problemas de aborto de thread (devido a própria propriedade de timeout do APS.Net, que não tem a resposta do servidor dentro do tempo esperado, nessa situação pode dar timeout ou o abortar a thread).
• Encontrados alguns problemas no envio do request, salvos como “An error ocurred while sendind the request.”.
• Processo W3wp.exe consome 100% da cpu.

Os erros listados acima ocorrem já com 50 usuários simultâneos (carga de usuários inicial do teste), com a utilização ou não do redis. Podemos dizer que a aplicação, do modo que está hoje no meu ambiente, suportaria uma carga superior a 50 usuários e inferior a 100.

Cenários de uso

Resultado dos testes

Em análise.