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

adrcmendes@gmail.com, miltonazara@gmail.com,

phernandescast@outlook.com

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.