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

Edição atual tal como às 17h13min de 21 de novembro 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. Foi observada uma melhora na performance no sistema como:

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

Durante a execução dos testes foram encontrados problemas (não relacionados ao uso do redis) na aplicação, segue listagem abaixo:

1. Não foi possível balancear a carga entre os dois servidores.
2. Problemas de conexão da API com o banco de dados, que são os erros salvos como “The network path was not found”.
3. Problemas de timeout.
4. 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).
5. Encontrados alguns problemas no envio do request, salvos como “An error ocurred while sendind the request.”.
6. 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.

TOP 10 Queries mais lentas

• Item 01

1 update t set
2 		appKey = p.AppKey
3 	from
4 		@personTable t
5 		inner join Profile p on p.PersonId = t.personId

• Item 02

 1 MERGE INTO EventPerson _target
 2 	USING
 3 	(
 4 		SELECT
 5 			EventId
 6 			, PersonId
 7 		FROM
 8 			@personTable
 9 	) AS _source
10 	ON (_source.EventId = _target.EventId
11 		AND _source.PersonId = _target.PersonId)
12 	WHEN NOT MATCHED THEN
13 		INSERT
14 		(
15 			EventId,
16 			PersonId,
17 			[Read]
18 		)
19 		VALUES
20 		(
21 			_source.EventId,
22 			_source.PersonId,
23 			0
24 		)
25 	WHEN NOT MATCHED BY SOURCE AND _target.EventId = @eventId THEN
26 		DELETE;

• Item 03

 1 MERGE INTO SurveyPerson _target
 2 USING
 3 (
 4 	SELECT
 5 		SurveyId
 6 		, PersonId
 7 	FROM
 8 		@personTable
 9 ) AS _source
10 ON (_source.SurveyId = _target.SurveyId
11 	AND _source.PersonId = _target.PersonId)
12 WHEN NOT MATCHED THEN
13 	INSERT
14 	(
15 		SurveyId,
16 		PersonId,
17 		Answered,
18 		Viewed
19 	)
20 	VALUES
21 	(
22 		_source.SurveyId,
23 		_source.PersonId,
24 		0,
25 		0
26 	)
27 WHEN NOT MATCHED BY SOURCE AND _target.SurveyId = @surveyId THEN
28 	DELETE;

• Item 04

1 INSERT INTO @personTable (personId)
2 	SELECT x FROM dbo.FNC_CONVERT_VARCHAR_IN_TABLE(@ids, ',')

• Item 05

1 WITH split(i,j) AS 
2     ( 
3         SELECT i = CAST(1 AS BIGINT), j = CHARINDEX(@separador, @string + @separador)
4         UNION ALL 
5         SELECT i = j + 1, j = CHARINDEX(@separador, @string + @separador, j + 1) FROM split WHERE CHARINDEX(@separador, @string + @separador, j + 1) <> 0 
6     ) 
7     INSERT    @tabela (x) 
8     SELECT    RTRIM(LTRIM(SUBSTRING(@string,i,j-i))) FROM split OPTION (maxrecursion 10000)

• Item 06

1 INSERT INTO @personTable (PersonId, EventId)
2 	SELECT DISTINCT
3 		gp.PersonId
4 		, @eventId
5 	FROM
6 		GroupPerson gp
7 		INNER JOIN @groupTable gt
8 			ON gt.GroupId = gp.GroupId

• Item 07

1 select distinct
2 		p.AppKey
3 	from
4 		Profile p
5 		inner join @ids i on i.Id = p.PersonId
6 	where
7 		isnull(p.AppKey, '') != ''

• Item 08

1 INSERT INTO @personTable (PersonId, SurveyId)
2 SELECT DISTINCT
3 	gp.PersonId
4 	, @surveyId
5 FROM
6 	GroupPerson gp
7 	INNER JOIN @groupTable gt
8 		ON gt.GroupId = gp.GroupId

• Item 09

 1 MERGE INTO EventGroup _target
 2 	USING
 3 	(
 4 		SELECT
 5 			EventId
 6 			, GroupId
 7 		FROM
 8 			@groupTable
 9 	) AS _source
10 	ON (_source.EventId = _target.EventId
11 		AND _source.GroupId = _target.GroupId)
12 	WHEN NOT MATCHED THEN
13 		INSERT
14 		(
15 			EventId,
16 			GroupId
17 		)
18 		VALUES
19 		(
20 			_source.EventId,
21 			_source.GroupId
22 		)
23 	WHEN NOT MATCHED BY SOURCE AND _target.EventId = @eventId THEN
24 		DELETE;

• Item 10

1 SELECT
2 	DISTINCT
3 	gp.PersonId
4 FROM
5 	dbo.GroupPerson gp
6 	INNER JOIN @groupTable gt ON gt.Id = gp.GroupId

Cenários de uso

Resultado dos testes

Nesta seção serão apresentados os resultados obtidos da execução dos testes. Para identificação foram utilizadas as letras "R" e "A", sendo a primeira para identificar os resultados obtidos com a utilização do redis e a segunda para configuração com ASP.NET.

• Processador e disco

Contador: Percentagem de tempo ocioso.

Descrição: Este contador fornece quanto tempo o disco permaneceu em estado de repouso, ou seja, todos os pedidos do sistema operacional para o disco ter sido concluída e há zero de pedidos pendentes. Este contador varia de 100 (ou seja, sempre ocioso) para 0 (ou seja, sempre ocupado).

Limite recomendado: Abaixo de 75 %.

Análise: Grande parte do tempo encontra-se ocioso.

Contador: Percentagem de espaço livre.

Descrição: Mostra a porcentagem do espaço total utilizável no disco lógico selecionado.

Limite recomendado: Acima de 25%.

Análise: Aplicação está dentro do recomendado.

Tempo total do processador.

Descrição: Mede a utilização da CPU de cada processador.

Limite recomendado: Não exceder 80% por mais de 10 minutos ao longo do período de teste.

Análise: A aplicação em vários momentos durante a execução do teste chegou a utilizar 100% de processamento no processo W3wp.exe no servidor web que utilizava para o teste.

Contador: Mudança de contexto.

Descrição: A mudança de contexto ocorre quando o kernel muda o processador de um segmento para outro, por exemplo, quando um segmento com uma prioridade maior do que o segmento em execução torna-se pronto.

Limite recomendado: O valor ideal recomendado é de no máximo 10000 por CPU.

Análise: A aplicação encontra-se acima do recomendado.

• Memória

Contador: Páginas/segundo.

Descrição: Mede o número de páginas por segundo que são paginadas fora da memória RAM para a memória virtual.

Limite recomendado: Se o número for alto indica falhas graves. O limite normalmente é de 20 páginas/s

Análise: A aplicação apresentou diferentes tempos para o ARR, SQL e servidores Web. No ARR ficou dentro do recomendado, no SQL por sua vez, apenas com a utilização do redis e com até 100 usuários simultâneos a aplicação ficou dentro do recomendado. Nos demais casos a média do tempo de página/s foi superior ao recomendado. Indicam um delay no sistema utilizado.

Contador: % Memória virtual comprometida.

Descrição: Indica a percentagem da memória comprometida utilizada dentro do limite dado pela soma da memória RAM e Page File.

Limite recomendado: Abaixo de 75% e que não tenha grande variação no indicador.

Análise: Com a utilização do redis a aplicação encontra-se dentro do recomendado. Quando utiliza o ASP.NET é possível visualizar uma variação no indicador.

Contador: Memória disponível em MBytes.

Descrição: Indica quantidade de memória disponível para alocação em MBytes.

Limite recomendado: Se o valor for inferior a 20/25 por cento de RAM instalada é uma indicação de memória insuficiente. Menos de 100 MB é uma indicação de que o sistema é muito carente de memória e paginação.

Análise: Os servidores web aproximam-se bastante dos limites recomendados.

• Network

Contador: Kbytes totais pela interface de rede.

Descrição: Indica quantos Kbytes foram enviados e recebidos a cada segundo pela interface de rede.

Limite recomendado: Menor que 5 Mbytes para uma rede de 100Mbps, menor que 50 Mbytes para uma rede de 1000 Mbps. (Quanto menor melhor).

Análise: O tráfego na rede ocorre devido a possibilidade de conexão e sem perda de sessão durante os testes. Sem o uso do redis não é possível realizar uma quantidade de login satisfatória para que tenha tráfego na rede.

Contador: Falhas de conexão (TCP)

Descrição: Este é o número bruto de conexões TCP que falharam desde que o servidor foi iniciado. Uma falha normalmente indica uma perda de dados em lugar no processo. A perda pode ocorrer em muitos locais. Esta poderia ser uma indicação de um outro dispositivo que está sendo para baixo, ou problemas com a configuração do lado do cliente do software.

Limite recomendado: Quanto menor melhor.

Análise: Grande ocorrência de falhas nos servidores webs a partir de 100 usuários simultâneos conectados.

• SQL

Contador: Expectativa de vida da página.

Descrição: Indica o número em segundos que uma página vai ficar na área de buffers, sem referências.

Limite recomendado: Quanto menor melhor.

Análise: Com a utilização do redis o sistema possui quantitativo satisfatório.

• WEB

Contador: Requests/sec.

Descrição: Mostra o número de requisições por segundo que seu site está atendendo. Na maioria das aplicações este número é relativamente baixo não passando de 5 ou 10 já que pra que este contador seja incrementado é necessário que as requests sejam executadas exatamente no mesmo segundo. Isto geralmente acontece em duas situações: você tem vários usuários acessando sua aplicação ao mesmo tempo ou caso suas requisições demorem muito pra terminar a execução.

Limite recomendado: O número é relativamente baixo não passando de 5 ou 10.

Análise: Com a utilização do redis o sistema possui quantitativo satisfatório.

• IIS

Contador: Current Applicantion Pool Uptime.

Descrição: Permite que você veja se o pedido tiver sido reiniciado ou não.

Limite recomendado: Quanto menor melhor.

Análise: Com a utilização do redis com até 100 usuários simultâneos conectados o sistema possui quantitativo satisfatório.

• Redis

Descrição: Dados do redis disponibilizados pela equipe do DevOps para comparativos.

Usuários simultâneos: 50 usuários.

Descrição: Dados do redis disponibilizados pela equipe do DevOps para comparativos.

Usuários simultâneos: 100 usuários.

Descrição: Dados do redis disponibilizados pela equipe do DevOps para comparativos.

Usuários simultâneos: 150 usuários.

• JMeter

Descrição: Quantidade total de samplers.

Descrição: Quantidade total de samplers.

Descrição: Porcentagem de erro total.

Descrição: Vazão.