Stress test/benchmaking rapide d’un serveur web avec Siege.

Publié le par admin

Siege est un petit outil permettant de réaliser des stress test rapide (ainsi qu’un benchmarking)  et non qualitatifs de serveurs web.

J’utilise Siege actuellement pour benchmaker mon RaspberryPI Zero avec Raspbian Jessie /Apache.

Pour installer Siege sous Debian/Ubuntu


apt-get install siege

 

Lancer le test :


siege -d10 -c30 -r1000 -v http://lderpib1.local/i2.html

 

  • -d : délais en seconde entre chaque appel de page (par utilisateur)
  • -c : nombre d’utilisateurs (thread) attaquant le serveur web
  • -r : nombre de répétitions. Vous pouvez indiquer un nombre énorme. Un simple ctl+c stoppe le test et vous génère le rapport de benchmark.
  • -v : affiche en console les temps de chaque transaction.

HTTP/1.1 200   0.86 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.52 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.16 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.61 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.61 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.61 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.44 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.17 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.21 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.47 secs:   12360 bytes ==> GET  /i2.html
HTTP/1.1 200   0.50 secs:   12360 bytes ==> GET  /i2.html

Pour l’RL j’ai généré une page web statique remplie aléatoirement.

Une fois le test effectué (ou interrompus par ctl+c)


Transactions:                2378 hits
Availability:              100.00 %
Elapsed time:              468.79 secs
Data transferred:           28.03 MB
Response time:                0.91 secs
Transaction rate:            5.07 trans/sec
Throughput:                0.06 MB/sec
Concurrency:                4.62
Successful transactions:        2378
Failed transactions:               0
Longest transaction:            2.54
Shortest transaction:            0.16

PS : Pour quelques chose de plus fin je passe par JMetter et un site web statique de 1000 pages  générées  par un outils de ma composition.

Chaque page possède :

  • un nombre  aléatoire d’image et de paragraphes
  • chaque paragraphe est composé d’un nombre aléatoire (borne min/max paramétrable) de mots et chaque mot un nombre aléatoire de lettres (borne min/max paramétrable)

PHP/CURL et TimeOut

Publié le par admin

Comment éviter les problèmes de TimeOut lors de l’exécution d’un appel CURL en PHP.

2 paramètres sont à prendre en compte :

  • Le temps pour établir la connexion avec le serveur
  • Le temps de la connexion (une fois celle-ci établie)

L’API CURL PHP répond à ce problème :

  • CURLOPT_CONNECTTIMEOUT     The number of seconds to wait while trying to connect. Use 0 to wait indefinitely.
  • CURLOPT_TIMEOUT – The maximum number of seconds to allow cURL functions to execute.
$ch = curl_init();
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT ,5); 
curl_setopt($ch, CURLOPT_TIMEOUT, 400); //timeout in seconds
$response = curl_exec($ch);
curl_close($ch)

Il ne faut oublier aussi de surcharger la valeur de temps d’exécution maxima du script PHP incluant ce code, sinon ce dernier stoppera le script avant la fin du de la connexion.


set_time_limit(0);// to infinity for example

PS : n’oubliez pas d’installer CURL et son Wrapper PHP.
Exemple Debian/Ubuntu


apt-get update && apt-get dist-upgrade
apt-get install curl php5-curl

 

Connexion distante SSH par clef (sans mot de passe)

Publié le par admin

Le but

Ne plus avoir à saisir de mot de passe pour se connecter en SSH.

Dans mon cas (article suivant) j’ai besoin d’installer mes repo Git sur un serveur distant et d’y accéder par SSH

Les éléments fournis sont viables sur un environnement Debian et affiliés (Ubuntu/Mint…)

 

Installation des clients/serveurs SSH

Situons les choses : nous désirons que notre machine Malorean (c’est le nom de mon laptop :p ) – via le compte lde – puisse se connecter en SSH à la machine puppet1  ( mon serveur Debian de test).

En root (ou avec les droit associés (Sudo ou su selon votre distrib)

Sur le client (malorean)

apt-get update
apt-get install openssh-client

 

Sur le serveur (puppet1)

apt-get update
apt-get install openssh-server

Création et publication des clefs

Création du jeux de clef privée/publique

Sur la machine cliente (Malorean)

ssh-keygen -t dsa -b 1024

Tapez entrer pour donner le nom par défaut id_dsa au couple de clef privée/publique
Si vous saisissez une passphare sil faudra la saisir à chaque connexion, si vous désiez une connexion « automatique » ne saisissez rien (certes la sécurité est moindre), pour ma part pas de passphrase.

C’est fini

Your identification has been saved in /home/lde/.ssh/id_dsa.
Your public key has been saved in /home/lde/.ssh/id_dsa.pub.
The key fingerprint is:
f3:88:cc:dc:7f:9a:79:f4:3c:10:d9:33:3f:d7:4c:6d lde@malorean3
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|              o .|
|            o + E|
|           S . B.|
|       + o + o .=|
|       = o .. + o|
|          . oo + |
|            =+ . |
+-----------------+

Ne me demandez pas à quoi sert ce random art image je n’en ai pas la moindre idée.

Un ls -lha ~/.ssh  pour vérifier que les fichiers sont bien la

-rw------- 1 lde lde 668 oct. 2 18:07 id_dsa
-rw-r--r-- 1 lde lde 603 oct. 2 18:07 id_dsa.pub

Publication de la clef publique

A présent il faut ajouter à un couple user/serveur  (dans notre cas lde@puppet1) la clef publique du Client (Malorean dans mon cas).
Attention Malorean et Puppet1 dans mon exemple possèdent le même nom de user lde (étant du coté client et serveur j’ai utilisé le même nom de user) , mais il pourraient évidement êtres différents.

ssh-copy-id -i ~/.ssh/id_dsa.pub lde@puppet1

Saisissez le mot de passe du serveur distant et c’est bon.

Now try logging into the machine, with "ssh 'lde@puppet1'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting

Attention : à ne pas envoyer votre clef privée (la id_dsa) qui doit rester secrète.
Pas très grave si le serveur distant est géré par vous (et encore, il faut éviter ce type de bourdes) mais dangereux si le serveur distant est géré par un tiers.
Ce derniers pourrait alors tenter de se connecter à votre serveur distant.

Pour certaines tâches délicates : fermez votre bureau, éteignez le téléphone et prenez votre temps : ça vous évitera des erreurs graves pour la sécurité de vos sysèmes.

Testons

ssh lde@puppet1

Si vous n’avez pas saisis de passphrase vous devez être connecté

Sinon entrez la passphrase demandé et vous devriez être connecté.