session | Veille technologique et autres

Maintenant que nous avons une application à tester, nous pouvons utiliser gatling pour simuler de la charge et voir comment se comporte l’application en cas de chute d’un noeud master.

Le script se contente de se logguer, et de rafraîchir 3 fois la page index. Il va injecter 20 users par seconde pendant 5 minutes:

package com.axioconsulting

import scala.concurrent.duration._

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.jdbc.Predef._

class Session extends Simulation {

val httpProtocol = http
.baseURL("http://172.17.0.83:8080")
.inferHtmlResources(WhiteList(), BlackList())
.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
.acceptEncodingHeader("gzip, deflate")
.acceptLanguageHeader("en")
.connection("keep-alive")
.doNotTrackHeader("1")
.userAgentHeader("Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0")

val headers_1 = Map("Accept" -> "image/png,image/*;q=0.8,*/*;q=0.5")

val uri1 = "http://172.17.0.83:8080"

val scn = scenario("Session")
.exec(http("Login")
.get("/session-webapp/login.html?userName=benoit")
)
.pause(7)
.exec(http("refresh_1")
.get("/session-webapp/index.jsp")
.resources(http("request_4")
.get(uri1 + "/favicon.ico")))
.pause(1)
.exec(http("refresh_2")
.get("/session-webapp/index.jsp")
)
.pause(1)
.exec(http("refresh_3")
.get("/session-webapp/index.jsp")
)

/*setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)*/
setUp(scn.inject(constantUsersPerSec(20) during(5 minutes))).protocols(httpProtocol)
}

package com.axioconsulting

import scala.concurrent.duration._

import io.gatling.core.Predef._

import io.gatling.http.Predef._

import io.gatling.jdbc.Predef._

class Session extends Simulation {

val httpProtocol = http

.baseURL("http://172.17.0.83:8080")

.inferHtmlResources(WhiteList(), BlackList())

.acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")

.acceptEncodingHeader("gzip, deflate")

.acceptLanguageHeader("en")

.connection("keep-alive")

.doNotTrackHeader("1")

.userAgentHeader("Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0")

val headers_1 = Map("Accept" -> "image/png,image/*;q=0.8,*/*;q=0.5")

val uri1 = "http://172.17.0.83:8080"

val scn = scenario("Session")

.exec(http("Login")

.get("/session-webapp/login.html?userName=benoit")

)

.pause(7)

.exec(http("refresh_1")

.get("/session-webapp/index.jsp")

.resources(http("request_4")

.get(uri1 + "/favicon.ico")))

.pause(1)

.exec(http("refresh_2")

.get("/session-webapp/index.jsp")

)

.pause(1)

.exec(http("refresh_3")

.get("/session-webapp/index.jsp")

)

/*setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)*/

setUp(scn.inject(constantUsersPerSec(20) during(5 minutes))).protocols(httpProtocol)

}

J’ai arrêté un noeud master avec la commande supervisor :

supervisor> stop redis-1
redis-1: stopped

1 2	supervisor> stop redis-1 redis-1: stopped

Ce qui nous donne:

On peut voir qu’il y a des erreurs pendant près de 10s, le temps que le slave prenne le pas sur le master.

Il faudrait peut être modifier le session-manager pour tenir de ce problème. A suivre…

Après avoir créé une première image contenant une application basique sous tomcat, je vais tester une montée en charge. Pour cela, nous allons lancer 2 containers tomcat et mettre en place un HA proxy (il s’agit d’un load balancer logiciel qui va répartir la charge entre les 2 containers tomcat.

Je vais utiliser l’image suivante : https://index.docker.io/u/dockerfile/haproxy.

Il y a juste à surcharger la configuration pour l’adapter à nos besoins:

global
  log 127.0.0.1 local0
  log 127.0.0.1 local1 notice
  chroot /var/lib/haproxy
  user haproxy
  group haproxy
  # daemon

defaults
  log global
  mode http
  option httplog
  option dontlognull
  contimeout 5000
  clitimeout 50000
  srvtimeout 50000
  errorfile 400 /etc/haproxy/errors/400.http
  errorfile 403 /etc/haproxy/errors/403.http
  errorfile 408 /etc/haproxy/errors/408.http
  errorfile 500 /etc/haproxy/errors/500.http
  errorfile 502 /etc/haproxy/errors/502.http
  errorfile 503 /etc/haproxy/errors/503.http
  errorfile 504 /etc/haproxy/errors/504.http

listen session-webapp :80
    balance roundrobin
    server tomcat1 172.17.0.3:8080 check
    server tomcat2 172.17.0.4:8080 check
    stats enable
    stats uri /stats

global

log 127.0.0.1 local0

log 127.0.0.1 local1 notice

chroot /var/lib/haproxy

user haproxy

group haproxy

# daemon

defaults

log global

mode http

option httplog

option dontlognull

contimeout 5000

clitimeout 50000

srvtimeout 50000

errorfile 400 /etc/haproxy/errors/400.http

errorfile 403 /etc/haproxy/errors/403.http

errorfile 408 /etc/haproxy/errors/408.http

errorfile 500 /etc/haproxy/errors/500.http

errorfile 502 /etc/haproxy/errors/502.http

errorfile 503 /etc/haproxy/errors/503.http

errorfile 504 /etc/haproxy/errors/504.http

listen session-webapp :80

balance roundrobin

server tomcat1 172.17.0.3:8080 check

server tomcat2 172.17.0.4:8080 check

stats enable

stats uri /stats

j’ai repris le fichier de l’image et j’ai ajouté la partie en bas. On va donc faire du round robin entre nos 2 serveurs tomcat qui sont ensuite définis. J’ai gardé la partie stats pour vérifier que tout se passe bien.

En démarrant un container, on obtient le résultat suivant:

docker run -i -t  -v /tmp/session-webapp/src/main/haproxy:/haproxy-override dockerfile/haproxy

1	docker run -i -t -v /tmp/session-webapp/src/main/haproxy:/haproxy-override dockerfile/haproxy

[WARNING] 143/194932 (12) : Server session-webapp/tomcat1 is DOWN, reason: Layer4 timeout, check duration: 2002ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 143/194933 (12) : Server session-webapp/tomcat2 is DOWN, reason: Layer4 timeout, check duration: 2002ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[ALERT] 143/194933 (12) : proxy 'session-webapp' has no server available!

[WARNING] 143/194932 (12) : Server session-webapp/tomcat1 is DOWN, reason: Layer4 timeout, check duration: 2002ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

[WARNING] 143/194933 (12) : Server session-webapp/tomcat2 is DOWN, reason: Layer4 timeout, check duration: 2002ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

[ALERT] 143/194933 (12) : proxy 'session-webapp' has no server available!

Le serveur ne trouve aucun serveur « backend ». C’est ce que l’on constate aussi en regardant les stats:

En démarrant un container tomcat, on peut voir que les choses s’améliorent:

docker run -i -t session-webapp/1.0-SNAPSHOT

1	docker run -i -t session-webapp/1.0-SNAPSHOT

[WARNING] 143/195256 (12) : Server session-webapp/tomcat1 is UP, reason: Layer4 check passed, check duration: 0ms. 1 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

1	[WARNING] 143/195256 (12) : Server session-webapp/tomcat1 is UP, reason: Layer4 check passed, check duration: 0ms. 1 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

On a maintenant un premier backend. Et effectivement, en allant sur le site, j’obtiens bien la page voulue

Je lance maintenant le deuxième:

[WARNING] 143/195615 (12) : Server session-webapp/tomcat2 is UP, reason: Layer4 check passed, check duration: 0ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

1	[WARNING] 143/195615 (12) : Server session-webapp/tomcat2 is UP, reason: Layer4 check passed, check duration: 0ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

Nous avons maintenant une infrastructure avec 2 serveur tomcat et un load balancer devant.

En lancant une commande de type :

while [ 1 -eq 1 ]; do wget "http://172.17.0.2/session-webapp/"; done

1	while [ 1 -eq 1 ]; do wget "http://172.17.0.2/session-webapp/"; done

On voit bien l’alternance des serveurs dans les logs et dans les stats.

Les sources de l’exemple sont disponible ici: git.

Veille technologique et autres

Archives par étiquette : session

Gestion de session avec un cluster redis – suite

load balancing haproxy sous docker

Partager :

Partager :