Artigo benchmark moodle
-
Upload
milton-azara -
Category
Technology
-
view
570 -
download
6
description
Transcript of Artigo benchmark moodle
Moodle Benchmark
Adriano C. Mendes, Milton F. de Azara Filho, Paulo Hernandes C.
Faculdade de Tecnologia SENAC Goiás
Av. Independência, Nº 1.002, Setor Leste Vila Nova
Goiânia-GO - CEP: 74645-010
[email protected], [email protected],
Resumo: O artigo, em questão, tem o objetivo de analisar e traçar um perfil do
crescimento do uso de CPU (Central Processing Unit), uso de memória RAM
(Random Access Memory) e tráfego de rede da aplicação Moodle sob
diferentes quantidades de usuários simultâneos.
Abstract: This article, in question, aims to analyze and draw a profile of
increased use of CPU (Central Processing Unit), memory RAM usage
(Random Access Memory) and network traffic application Moodle when
subjected to different amounts of concurrent users.
1. Introdução
O objetivo deste estudo é analisar e comparar o desempenho da aplicação Moodle
quando submetida à quantidades distintas de usuários. Tais ações objetivam a tomada de
decisão quando da implantação de um servidor Moodle, considerando a projeção do
número de usuários simultâneos1.
Para tanto, duas questões são levantadas: como simular com fidelidade um
número “n” de usuários, interagindo de forma aleatória com o sistema; e como garantir
que os resultados obtidos sejam compatíveis com um ambiente em produção.
Questionamentos que serão respondidos no decorrer deste artigo, tendo como base a
metodologia utilizada e, sobretudo, a análise dos resultados obtidos.
Na realização do experimento, será utilizado um servidor Moodle com as
configurações similares ao de um servidor em produção, tais como: inscrição de
usuários, sala de aula, atividades e recursos disponíveis no ambiente.
As análises de desempenho serão baseadas nas tarefas que os usuários realizam
com freqüência no ambiente, isto é, em suas interações com o sistema, as quais
permitirão a coleta de informações sobre o comportamento da plataforma. Para isso,
será utilizada a ferramenta Apache Jmeter, que executará um script com as interações
dos usuários, contendo variáveis, decisões e requisições necessárias à simulação.
Essas interações com o sistema gerarão dados referentes ao uso de CPU (%), uso
de memória RAM (MB) e tráfego de rede (Mb/s), pontualmente para cada quantidade
de usuários, os quais serão organizados de maneira a traçar um perfil do crescimento da
utilização dos recursos computacionais à medida em que o número de usuários aumenta.
O estudo faz-se importante dado o momento de expansão da Educação à
Distância em todo o Brasil, impulsionado em boa parte por investimentos em programas
1 Fazem uso da aplicação em um mesmo intervalo de tempo.
de capacitação do Governo Federal (Profuncionário, Universidade Aberta do Brasil -
UAB). Junta-se a isso, o fato de que o Moodle é a plataforma de ensino à distância
gratuita mais utilizada no mundo, com mais de 80 mil instalações registradas; das quais
seis mil estão no Brasil [MOODLE, 2013].
Com esse panorama, e tendo por base este estudo, profissionais de Tecnologia da
Informação terão um ponto de partida no dimensionamento de recursos computacionais
para implantação da plataforma Moodle. Fato que contribui para o bom funcionamento
da aplicação.
2. Fundamentação teórica
No âmbito da computação, efetuar um Benchmark é tido como o ato de executar um
conjunto de avaliações, sobre determinadas aplicações, de modo a obter o desempenho
relativo de cada uma delas. Essas avaliações são efetuadas utilizando-se um conjunto
padrão de testes e devem permitir, a partir da análise dos resultados obtidos, que seja
realizada alguma comparação entre as mesmas [GOMES, 2009].
2.1. Moodle
Acrônimo de Modular Object Oriented Distance Learning – MOODLE – é um sistema
modular de ensino à distância orientado a objetos.
A expressão “orientado a objetos” está, na verdade, relacionado à maneira como
o sistema foi construído. Trata-se de um paradigma de análise, projeto e programação de
sistemas de software baseado na cooperação e interação de diversas unidades de
software chamadas de objetos [NAKAMURA, 2008].
Conhecido por muitos como AVA (Ambiente Virtual de Aprendizagem),
enquanto framework2, pode ser definido como um CMS (Course Management System)
ou mesmo LMS (Learning Management System). Em suma, o Moodle é uma plataforma
de aprendizagem criada para facilitar a implementação de cursos de ensino à distância.
2.2. Apache Jmeter
É uma aplicação desktop gratuita, opensource, 100% desenvolvida em Java, projetada
para realizar testes funcionais e de desempenho. Pensada originalmente para testes em
aplicações Web, mas, hoje, se expandiu para outras funções [JMETER, 2013].
Pode ser utilizada para mensurar o desempenho de sites estáticos ou dinâmicos,
simulando acessos à uma determinada aplicação. Importante desde simples testes em
servidores web até testes mais complexos em aplicações específicas, como o Moodle
[JMETER, 2013].
Algumas características da ferramenta:
Suporta requisições do tipo HTTP e HTTPS;
Suporte a multithread, possibilitando a simulação de usuários concorrentes;
Criação e customização de scripts baseados em testes lógicos e
controladores múltiplos;
2 É uma coleção de códigos-fonte, classes, funções, técnicas e metodologias que facilitam o
desenvolvimento de novos recursos (LISBOA, 2008).
Criação de usuários baseados em threads, com armazenamento de sessão,
configuração de cache e atribuição de variáveis, estáticas ou dinâmicas.
2.3. Zabbix
Ferramenta de gerenciamento que monitora os elementos e serviços de rede. Coleta
dados através de consultas SNMP (Simple Network Manangement Protocol). Após
coletados, os dados são armazenados em uma base de dados SQL, permitindo a geração
de relatórios pré-definidos e personalizados, e ainda a utilização de ferramentas
especializadas para gerar relatórios [PEIXINHO, 2013].
Dentre os relatórios principais gerados pelo Zabbix, destacam-se os relatórios de
disponibilidade, de nível de serviços, de tráfego de rede e de utilização de recursos.
Aqui, utilizaremos três relatórios: uso de memória RAM, uso de CPU (%) e tráfego de
rede.
3. Experimento
Composto por três etapas, o experimento tem como base simular usuários interagindo
com a plataforma Moodle e analisar o comportamento dos recursos já descritos. Para
tanto, a primeira etapa trata da configuração do servidor Moodle de modo a torná-lo o
mais próximo possível de um servidor em produção. A segunda, trata do
desenvolvimento do script de testes com a ferramenta Jmeter. Por fim, a terceira parte
refere-se à simulação propriamente dita: como foi seu planejamento e, principalmente,
como se deu sua execução.
3.1. Configuração do servidor Moodle
Para realização de testes, foi preparado um ambiente, conforme o cenário representado
pela figura 1, com as seguintes características:
Dois computadores equipados com processador AMD Phenom II X4 B97
64bits, 500GB de espaço em disco. O primeiro, destinado ao servidor que
hospedará a aplicação Moodle, terá 6GB de memória RAM. O segundo,
destinado somente ao Banco de dados, com 4GB de memória RAM;
Um notebook com processador Intel Core I5, dois núcleos, 16GB de
memória RAM e 500GB de espaço em disco, responsável por executar o
script de teste através do Jmeter;
Uma máquina virtual, com 2GB de memória, responsável por coletar os
dados dos testes, utilizando para isso o Zabbix.
Figura 1: Ambiente de testes
A aplicação foi separada do banco de dados para facilitar a análise dos
resultados, deixando claro qual a carga gerada unicamente pela aplicação. Além disso, é
importante evidenciar que, em ambientes mais robustos, esta estratégia é amplamente
utilizada.
Na Aplicação Moodle foi instalado e configurado o sistema operacional Linux,
com a distribuição Ubuntu 12.10, com os seguintes serviços:
Apache 2.2.22;
PHP 5.4.6-1;
Moodle 2.5.
Tanto o Apache quanto o PHP estão com a configuração padrão, ou seja, todos
os testes não levam em conta a otimização destes serviços. O módulo prefork do Apache
está habilitado e com a diretiva MaxClients configurada em 200.
A base de dados do Moodle foi instalada e configurada no Gerenciador de Banco
de Dados MySql 5.5.32 com sua configuração padrão, no sistema operacional Linux,
com a distribuição Ubuntu 12.10.
Para simular um servidor Moodle em produção, deve-se perguntar antes: quais
os principais recursos e atividades utilizados no ambiente? Como se dá a dinâmica de
interação dos usuários com o sistema?
A primeira questão foi respondida facilmente, devido a experiência obtida
administrando a plataforma. Portanto, os recursos e atividades utilizados são
apresentados na Tabela 1.
Tabela 1. Principais recursos e atividades
Recursos
Rótulo Texto, imagem, ou qualquer elemento que pode ser incorporado na página do
curso.
Imagem Inserida através dos rótulos, pode ser do tipo JPEG, PNG, BMP.
Arquivos Arquivos PDF são os mais utilizados. Por padrão, a versão do Moodle utilizada
exibe esse tipo de arquivo, no próprio navegador, através de um plugin nativo.
Link Web Página com elementos em HTML, hospedada no próprio Moodle.
Atividades
Envio de
arquivo Contempla o envio de arquivos de diversos tipos; avaliados posteriormente.
Fórum Ferramenta mais importante do ambiente. Permite a discussão entre os usuários
através de tópicos e posts.
Questionário Formado por diversos tipos de questões, podendo ser: discursivas, múltipla
escolha e de "V ou F".
A segunda questão necessita de uma análise mais profunda, pois refere-se a
dinâmica dos acessos. Tal análise leva em conta o número médio de interações, com o
ambiente, para cada número “n” de usuários em um determinado intervalo de tempo.
Em outras palavras, o número médio de entradas, na tabela de log, em um dado
intervalo. Esta análise foi importante para configuração dos períodos de atraso na
realização das tarefas pelos usuários.
Com base nisso, chegou-se a um número médio de quatro registros, por usuário,
no intervalo de um minuto. E tendo como base esse número, é que o script foi
desenvolvido.
Foram cadastrados também 1000 usuários no Moodle. Todos devidamente
matriculados na sala em que serão realizados os testes, seguindo o padrão: estudante1 à
estudante1000, senha 12345678. Esses dados serão utilizados na execução do script de
testes.
Por fim, a sala foi dividida em dois blocos, o primeiro, contendo os recursos e o
segundo, as atividades. Tal divisão deu-se unicamente para melhor disposição dos
elementos. O resultado pode ser visto na Figura 2:
Figura 2: Recursos e Atividades
3.2. Desenvolvimento do script de testes com Jmeter
O script de testes tem como finalidade simular os usuários interagindo com o sistema.
Foi desenvolvido com a ferramenta Jmeter, fazendo uso dos diversos recursos que ela
propicia, dentre as quais se destacam:
Uso de threads, possibilitando a simulação “n” de usuários simultâneos;
Gerenciadores de cache, cookies e cabeçalhos HTTP;
Definição de variáveis locais e globais;
Funções pré-definidas pela ferramenta;
Configuração de requisições do tipo HTTP;
Contadores, iterações, geradores de atraso, extratores de expressões
regulares;
As etapas do script fazem referencia a aplicação como um todo, desde o
login/logout, acesso a página inicial, passando pelos usuários, recursos e as atividades.
Desse modo foi imprescindível que a aplicação já estivesse concluída antes de iniciar o
desenvolvimento do script. Sua composição pode ser vista na figura 3.
Figura 3: Fluxograma descritivo do script de testes
Para acompanhar o funcionamento do script, o fluxograma foi dividido em duas
partes de modo a especificar melhor cada etapa de sua construção. Com isso, a primeira
parte detalhada pode ser vista na figura 4:
Figura 4: Primeira parte detalhada do script de testes
Observando a primeira parte, o número de threads equivale ao número de
usuários; portanto, “n” threads equivalem a “n” usuários. Desse modo, é possível
simular tantos usuários quanto necessário, levando em conta, inclusive, a
simultaneidade entre eles.
a. O Jmeter inicia "n" threads em "n" segundos, logo, 10 usuários levam 10 segundos
para serem iniciados.
b. Para cada thread que chega a este passo, é gerado um número (i) que varia entre 1 e
“n”, número esse que é incrementado a cada thread. O resultado disso é a string
“estudante(i)” que, combinada à senha 12345678, resulta na “tupla” username +
password necessários para o login dos usuários.
c. Agora, cada thread faz uma requisição HTTP à página de login do Moodle, contendo
como parâmetros, cada uma, o nome de usuário e senha. Como resultado dessa
requisição, o usuário autentica-se na plataforma.
d. Após o login, cada thread armazena consigo a chave da sessão sesskey, username e
userid. Todas elas são variáveis globais.
A figura 5 detalha o funcionamento da segunda parte do script.
Figura 5: Segunda parte detalhada do script de testes
A segunda parte do script trata das interações com os recursos e atividades. Após
o acesso á página inicial do curso, cada thread entra em um loop (contador temporal) e
realiza diversas ações durante 30 minutos. Inicialmente, cada thread passa por um
controlador e é direcionada aleatoriamente para uma de quatro etapas. São elas:
a. Visualiza um arquivo no formato PDF ou uma página Web. Dentro desta etapa, ainda
será escolhido, aleatoriamente, um arquivo de quatro possíveis ou uma página Web
entre duas configuradas. Os arquivos possuem tamanhos diferentes: 124KB, 573KB,
1.2MB e 2.9MB.
b. Faz upload de arquivo. Momento onde, sempre, cada thread escolhe de forma
aleatória um dentre quatro arquivos possíveis e com tamanhos distintos: 247KB,
573KB, 1.3MB e 2.8MB. Após isso, faz o upload do arquivo.
c. Posta no fórum. O conteúdo do post é uma string equivalente a um parágrafo com
cinco linhas.
d. Responde ao questionário composto por quatro questões objetivas e duas
dissertativas.
Cada thread realiza apenas uma das quatro etapas por vez. Ao fim de cada etapa,
caso o tempo de permanência no loop seja menor que 30 minutos, a thread realiza uma
das etapas novamente. Importante notar que essa contagem de tempo é feita de forma
independente para cada thread. Ao fim dos 30 minutos, cada usuário faz logoff do
Moodle, tendo como padrão, o posterior direcionamento à página inicial.
3.3. Simulação
Consiste em executar o script de testes com quantidades distintas de usuários, tendo o
servidor Moodle como alvo. Em cada teste serão contabilizadas as médias e os máximos
dos valores obtidos. Ao final, os resultados serão tabulados e dispostos na forma de
gráficos, ficando assim, visível o comportamento dos recursos à medida que o número
de usuários aumenta.
Para que o teste anterior não tenha influência no próximo, foi adotado o
procedimento de reiniciar o servidor Moodle sempre ao final de cada teste. Com isso, os
recursos serão liberados e dessa maneira todos os testes serão iniciados em critério de
igualdade.
Garantindo o correto funcionamento do Jmeter, foi alocado 8GB de memória
virtual para o Java, e também como o servidor Moodle, ele foi reiniciado ao fim de cada
teste, a fim de liberar recursos.
Cada teste tem duração entre 30 e 40 minutos. O que causa essa variação é o
tempo gasto para iniciar cada grupo de usuários somado ao tempo gasto para que este
mesmo grupo "deslogue" da plataforma.
O Zabbix faz a coleta dos dados a cada 30 segundos, via protocolo SNMP
(Simple Network Management Protocol), e armazena em uma base de dados MySQL.
Em seguida, para cada teste, os dados são retirados por meio de consultas feitas ao
banco.
4. Resultados
Ao todo foram realizados 13 testes, cada um com uma quantidade definida de usuários.
Para cada teste, foram armazenados os valores relativos aos três recursos a serem
analisados.
As informações foram retiradas e organizadas através de consultas à base de
dados do Zabbix. Para cada teste foram contabilizados a média e o máximo referente ao
uso de memória RAM (MB), uso de CPU (%) e tráfego de rede (Mb/s).
O tempo de coleta configurado no Zabbix foi de 30 segundos para todos os
recursos. Desse modo, foi possível traçar um perfil de crescimento, com base nos
valores da média e do máximo de usos.
4.1. Memória RAM
O sistema operacional e os serviços carregados na sua inicialização somam 259MB de
memória RAM, em média. Portanto, todos os testes realizados tiveram esse número
como ponto de partida. O calculo feito pelo Zabbix de memória em uso, é dado pela
soma de duas chaves: vm.memory.size[active] e vm.memory.size[wired], ou seja, a
memória ativa e a memória usada pelo kernel, respectivamente.
Os valores obtidos podem ser vistos na Tabela 2.
Tabela 2. Uso de memória RAM (MB)
Nº de Usuários Média (MB) Máx. (MB)
1 474,25 495,17
10 646,64 696,72
20 748,1 843,76
30 889,5 1051,37
40 1003,25 1202,48
60 1119,029 1544,88
80 1513,69 1967,28
100 1800,04 2399,42
130 2364,18 2954,45
160 2979,09 3970,27
200 3729,49 5103,85
240 4142,34 5314,58
1000 4963,03 5301,46
Com base na tabela acima, tem-se o gráfico descritivo do uso de memória RAM
para cada quantidade de usuários, apresentando a média e o máximo obtidos para cada
teste. Sua representação gráfica pode ser vista na Figura 6.
Figura 6: Média e máximo do uso de memória RAM/usuários
4.2. Uso de CPU (%)
A porcentagem do uso de CPU é dada pela soma entre os processos do kernel
(system.cpu.util[,system]) e os processos dos usuários (system.cpu.util[,user]); cujos
resultados podem ser vistos na tabela a seguir.
Tabela 3. Uso de CPU (%)
A partir da Tabela 3, foi gerado o gráfico descritivo do uso de CPU, conforme a
figura 7.
0500
10001500200025003000350040004500500055006000
1 10 20 30 40 60 80 100 130 160 200 240 1000
Me
mó
ria
RA
M (
MB
)
Usuários
Uso de memória RAM (MB) Média Máx
Nº de Usuários Média (%) Máx (%)
1 0,68 1,32
10 6,38 7,72
20 12,78 15,65
30 18,75 24,38
40 23,96 29,2
60 31,61 45,44
80 46,49 63,34
100 62,17 77,88
130 85,28 100
160 86,12 100
200 83,5 100
240 86,63 100
1000 54,54 100
Figura 7: Média e máximo do uso de CPU (%)
O crescimento no uso de CPU, até 130 usuários, deu-se praticamente de forma
linear, com uma média de 6% a 9% de aumento, a cada incremento de 10 usuários. A
partir daí, em todos os testes, o uso de CPU chegou a 100% de pico, com média de
86%, até o teste com 240 usuários.
O último teste, com 1000 usuários, atingiu um pico de 100% conforme esperado;
porém, diferente dos testes anteriores, obteve uma média de 54%. Após o 5° minuto,
com 340 usuários "logados", tanto CPU quanto memória RAM atingiram o pico, a partir
de então a Aplicação Moodle, por conta da limitação desses recursos, passou a recusar
quase todas as conexões, abaixando o nível de processamento consideravelmente,
comprovando a média baixa em relação aos demais testes (ver Figura 8).
Figura 8: Uso de CPU (%) para 1000 usuários
4.3. Tráfego de Rede
A medição do tráfego de rede levou em conta o fluxo de entrada e saída, no intuito de
0
10
20
30
40
50
60
70
80
90
100
1 10 20 30 40 60 80 100 130 160 200 240 1000
CP
U (
%)
Usuários
Uso de CPU (%) Média (%) Máx (%)
0
10
20
30
40
50
60
70
80
90
100
32
:01
33
:31
35
:01
36
:31
38
:01
39
:31
41
:01
42
:31
44
:01
45
:31
47
:01
48
:31
50
:01
51
:31
53
:01
54
:31
56
:01
57
:31
59
:01
00
:31
02
:01
03
:31
05
:01
06
:31
08
:01
09
:31
11
:01
12
:31
CP
U (
%)
Tempo (mm:ss)
CPU (%) 1000 usuários CPU (%)
evidenciar a diferença no comportamento entre ambos.
A tabela 4, inicialmente, apresentará os dados obtidos na medição do tráfego de
entrada:
Tabela 4. Tráfego de rede - entrada (Mb/s)
Nº de Usuários Média (Mb/s) Máx. (Mb/s)
1 0,12 0,52
10 1,28 2,17
20 2,38 3,57
30 3,56 5,09
40 4,48 6,52
60 5,22 10,45
80 8,49 14,08
100 10,71 16,56
130 12,63 21,36
160 12,90 21,55
200 12,61 20,28
240 12,68 19,78
1000 8,12 15,86
Até o teste com 130 usuários, o tráfego de entrada cresceu quase que de forma
linear, variando entre 1,4Mb/s à 1,8Mb/s, a cada incremento de 10 usuários, conforme
gráfico da Figura 9.
Figura 9: Média e máximo do tráfego de rede - entrada (Mb/s)
A partir de 130 usuários, o crescimento do tráfego não acontece mais de forma
linear, chegando a cair após os 160 usuários. O motivo é que o Moodle passou a não
responder todas as requisições feitas pelo Jmeter, por conta da sobrecarga de
processamento e memória.
0
2
4
6
8
10
12
14
16
18
20
22
24
1 10 20 30 40 60 80 100 130 160 200 240 1000
Tráf
ego
(En
trad
a M
b/s
)
Usuários
Tráfego de rede - Entrada (Mb/s) Média Máx
O resultado do teste com 1000 usuários é importante para ratificar as
informações anteriores. Nele, a média e o máximo estão bem abaixo dos demais testes,
comprovado pela análise do gráfico na Figura 10.
Figura 10: Tráfego de rede (entrada) para 1000 usuários
Os dados referentes ao tráfego de saída podem ser vistos na Tabela 5.
Tabela 5. Tráfego de rede - saída (Mb/s)
Nº de Usuários Média (Mb/s) Máx. (Mb/s)
1 0,05 0,46
10 0,46 1,11
20 0,89 1,92
30 1,34 2,77
40 1,65 3,64
60 2,12 4,98
80 3,26 6,67
100 4,24 10,43
130 5,02 9,95
160 5,28 10,41
200 5,27 10,64
240 5,73 11,01
1000 2,96 9,46
De forma análoga ao tráfego de entrada, o tráfego de saída cresce linearmente;
mas, somente até o teste com 100 usuários. A partir de 100, tende a se manter entre
10Mb/s à 11Mb/s de pico e 5Mb/s à 6Mb/s de média.
O que faz o tráfego de saída ser menor que o de entrada é, sobretudo, a
configuração de cache utilizada pelo Jmeter. Dessa forma, cada usuário "baixa"
determinado arquivo somente uma vez. Como os testes são cíclicos, requisições ao
0
2
4
6
8
10
12
14
16
18
15
:32
15
:33
15
:35
15
:36
15
:38
15
:39
15
:41
15
:42
15
:44
15
:45
15
:47
15
:48
15
:50
15
:51
15
:53
15
:54
15
:56
15
:57
15
:59
16
:00
16
:02
16
:03
16
:05
16
:06
16
:08
16
:09
16
:11
16
:12
Tráf
ego
de
en
trad
a (M
b/s
)
Tempo (mm:ss)
Tráfego de entrada - 1000 usuários Entrada
mesmo arquivo são comuns.
Figura 11: Média e máximo do tráfego de rede - saída (Mb/s)
O comportamento observado no teste com 1000 usuários difere-se, mais uma
vez, por conta da sobrecarga gerada pelo número de usuários. De acordo com o gráfico
da figura 12, houve uma queda acentuada após o 5° minuto. Período, esse, que coincidiu
com o pico de processamento da plataforma, recusando a maioria das requisições em
diante. O que justifica a queda brusca no tráfego (ver Figura 12).
Figura 12: Tráfego de rede (saída) para 1000 usuários
5. Considerações finais
As simulações feitas foram baseadas em condições ideais e todos os testes deram início
em situação de igualdade. Os computadores utilizados, durante os testes, são
equivalentes aos usados por qualquer pessoa; isto é, equipamentos normais e usuais,
0123456789
101112
1 10 20 30 40 60 80 100 130 160 200 240 1000
Tráf
ego
(Sa
ída
Mb
/s)
Usuários
Tráfego de rede - Saída (Mb/s) Média Máx
0
1
2
3
4
5
6
7
8
9
10
15
:32
15
:33
15
:35
15
:36
15
:38
15
:39
15
:41
15
:42
15
:44
15
:45
15
:47
15
:48
15
:50
15
:51
15
:53
15
:54
15
:56
15
:57
15
:59
16
:00
16
:02
16
:03
16
:05
16
:06
16
:08
16
:09
16
:11
16
:12
Tráf
ego
de
saíd
a (M
b/s
)
Título do Eixo
Tráfego de saída- 1000 usuários Saída
conforme especificações descritas na sessão 3.1. Portanto, levando em conta a
particularidade dos testes e tendo em mente as especificações dos equipamentos
utilizados, pode-se traçar conclusões a respeito dos dados obtidos.
Ao analisar de forma conjunta CPU, memória RAM e tráfego de rede, percebe-
se o aumento no uso destes recursos quase que de forma linear. Sobretudo até o teste
com 130 usuários, quando foi atingido 100% de uso de CPU. Fato que comprometeu a
dinâmica dos testes seguintes.
Atingindo o máximo de processamento, o Moodle, embora continuasse a atender
as requisições, começou aumentar seu tempo de resposta, fazendo com que a quantidade
de ações (logs) não acompanhassem a evolução do número de usuários. Quanto mais
aumentava esse número, aumentava, também, o tempo de resposta, até o momento do
teste com 1000 usuários, onde a aplicação passou a recusar praticamente todas as
conexões.
Nisso, observa-se que o "gargalo" ocorreu inicialmente, em termos de
processamento; antes mesmo de atingir o pico de memória RAM. O que faz sentido!
Tendo em vista a capacidade do processador utilizado e o fato do Moodle ser uma
aplicação dinâmica, ou seja, as páginas são construídas basicamente a cada requisição
(característica que exige muito processamento).
Logo, com esses recursos de hardware, é possível garantir o atendimento de até
130 usuários simultâneos sem a perda significativa de rendimento. Mas, para instalações
de maior porte, é aconselhável o uso de equipamentos mais robustos, sobretudo, com
maior capacidade de processamento, como servidores dedicados por exemplo. Uma
alternativa para essa situação, é balancear a aplicação em dois (ou mais) computadores,
fazendo com que a solução seja escalável e aumente, assim, a capacidade dos recursos.
6. Trabalhos futuros
Alguns temas surgem a partir da análise do referido estudo, seja para complementar ou
refinar os resultados já obtidos ou mesmo para seguir outra linha de pesquisa. São eles:
Realizar os mesmos testes; mas, analisar outros quesitos, como escrita em disco,
servidor Web e banco de dados;
Trabalhar com mais atividades e recursos: Banco de dados, Wiki, Glossário, etc;
Realizar os mesmos testes, com o mesmo script, mas, modificando os
parâmetros do servidor Web e analisar os resultados a partir disso;
Analisar o comportamento do banco de dados quando submetido aos mesmos
testes;
Analisar o comportamento do Moodle com o uso de bases de dados distintas.
Ex: MySql, Oracle, Postgres, ou até com outro webserver (Nginx).
Referências bibliográficas
MOODLE. Disponível em: <https://moodle.org/stats/>. Acesso em 20 de Setembro de
2013.
NAKAMURA, Rodolfo. (2013) "Moodle: Como criar um curso usando a plataforma
de Ensino à Distância". Editora Farol do Forte, São Paulo, Brasil.
GOMES, Paulo Roberto. (2009) "Um estudo sobre avaliação e execução do BLAST em
ambientes distribuídos". Dissertação de Mestrado, PUC Rio de Janeiro, Brasil.
LISBOA, Flavio Gomes da Silva. (2008) "Zend Framework, Desenvolvendo em PHP5
orientado à objetos com MVC". Editora Novatec, São Paulo, Brasil.
JMETER. Disponível em: <http://jmeter.apache.org/>. Acesso em 2 de Outubro de
2013.
PEIXINHO, Ivo de Carvalho; FONSECA, Francisco Marmo; LIMA, Francisco
Marcelo. (2013) "Segurança de Redes e Sistemas". Escola Superior de Redes: Rio de
Janeiro, Brasil.