Lexpage déménage. Si vous lisez ceci, c'est que vous avez déjà pris connaissance du changement (via le bandeau rouge sur l'adresse classique) ou que le changement a déjà été opéré auprès de vos DNS.

Comme indiqué dans ce fameux bandeau rouge (que vous avez peut-être raté), il n'est pas nécessaire de changer vos favoris, le changement se fera (ou a été fait) automatiquement. Il faut juste un peu de patience - 24 à 48h - pour que les DNS soient propagées.

Le nouveau petit nid douillet du Lexpage devrait rendre ce dernier un poil plus rapide, mais surtout supprimer les problèmes de latence que l'on rencontrait précédemment, ainsi que les soucis de "page à moitié chargée" qu'OVH nous imposait depuis quelques jours. Une fois que la migration sera complètement achevée, en fonction de la charge que cela représente sur le serveur, on verra pour ajouter deux-trois petites choses.

Au niveau technique, on est maintenant sur un petit VPS 1 coeur/1go de ram. C'est Nginx qui est en frontal et qui dispatche auprès de Gunicorn les appels à Django. La partie PHP (Piwik, essentiellement) est gérée par PHP-FPM d'une main de maître. Pendant ce temps, la base de données tourne sur MariaDB au lieu de MySQL, avec de l'InnoDB (en réalité, XtraDB) au lieu de MyISAM. Que du mieux, donc

Les accès au serveur sont bien protégés. Le firewall bloque systématiquement tout, et seuls quelques ports sont ouverts pour faire fonctionner le site (à savoir, le port 80, SSH et Bind9). Il y a une limite de connexions par IP, assez sévère pour SSH et un peu plus souple pour le 80 (10 ou 15 par 10 ou 15 secondes, je ne sais plus). A priori, c'est suffisant pour charger le site de façon confortable (même si vous avez un vieux navigateur qui se moque du keep-alive) mais si vous rencontrez des soucis, n'hésitez pas à en parler ici

GuybrushInnoDB (en réalité, XtraDB) au lieu de MyISAM. Que du mieux, donc

Y'a un bug !

Ça marche pas !

T'as un temps de génération de la page de 150 à 250ms, quand sous le mutualisé, tu étais à 1700-2000 minimum quand je regardait (voire 15-20 secondes, mais là c'était quand ça pait !). C'est trop rapide !

Niveau charge du serveur, t'en es où ? Parce que vu de l'extérieur, ça dépote !

C'est clairement plus rapide, oui Lors de mes tests, juste avec Piwik, il y avait un facteur 5 déjà !

Concernant la charge, c'est très léger. Selon le monitoring OVH, je ne dépasse pas les 2% de moyenne lors des accès au site. En terme de mémoire, hors buffer/cache, je suis à 280mo consommé. Avec le buffer/cache, ça tourne entre 400 et 650mo.

Avec quelques détails :
MariaDB - 111mo
Python/Gunicorn - 35mo
Bind9 - 25mo
php-fpm : 18mo
...
Nginx - 3mo

À quoi te sert bind9 dans ta configuration ? Ta zone DNS n'est pas gérée par OVH via ses services ?

Et y'a eu une alerte de sécurité pour fail2ban il y a quelques jours (debian-security). À priori ça ne te concerne pas vu que la faille concerne l'analyse de postfix, mais y'a un nouveau binaire pour debian depuis la fin de semaine dernière.

Tu as testé une mise en surcharge du site ? Je fais ça rarement mais dans ton cas ça aurai pu être intéressant pour tester la limite. Bon, maintenant que c'est public, c'est moins intéressant, mais ... :) De mémoire, c'était la commande "ab", qui fait partie d'apache (mais suffit de ne pas lancer le service apache). Et puis là, avec fail2ban actif, le benchmark va moins bien marcher ! ;)

Alors, dans l'ordre :
- Bind9 vient préconfiguré par OVH, je ne sais pas trop pourquoi, et je ne m'y connais pas assez pour aller désactiver/supprimer ce truc. Je vais essayer de récolter des infos et voir si je peux effectivement désactiver ce service, puisqu'en effet, c'est OVH qui gère la zone DNS. [Edité : bind9 retiré]
- Pour fail2ban, je ne l'utilise pas, vu la mémoire consommée par rapport à ce qu'il apporte...
- Pour la mise en surcharge, j'ai fait quelques tests "à la main", mais rien de comparable. Je vais me renseigner sur ab, mais vu que je n'utilise pas Apache... [Edité : ok, ab c'est générique ^^]

Je vais voir tout ça (Plutôt que de jouer à Creeper world 3 )

Alors, dans l'ordre :

- tu as l'avatar de yaug ! :) C'est ... dérangeant ... bug ou feature ?
- l'url de ton avatar est un .upload, je suppose que ça fait partie de ton appli. Par contre, ce .upload est servi par nginx en autre chose qu'une image :

[~]@Pom
tchou? curl -I www.lexpage.net/static/images/avatars/Guybrush.upload
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Mon, 21 Jul 2014 10:47:44 GMT
Content-Type: application/octet-stream
Content-Length: 3990
Last-Modified: Mon, 14 Jul 2014 19:25:22 GMT
Connection: keep-alive
Accept-Ranges: bytes

Et en restant dans le curl, un accès direct sur ton IP ne renvoie absolument rien :

[~]@Pom
tchou? curl 37.59.98.74
curl: (52) Empty reply from server

Bug ou feature ?


Si tu n'utilise pas fail2ban, tu gère comment tes restrictions ssh et http de connexions max par x secondes que tu as annoncé ?

re-edit : et girl a l'avatar www.lexpage.net/static/i…

Dans l'ordre :
- C'est normal, j'avais fait un test pour l'upload et j'avais repris l'avatar de Yaug. Pour l'instant, c'est le mien qui est encore visible tant que les DNS ne sont pas propagées. Je suppose que c'est déjà le cas chez toi (ou que tu as changé ton fichier host). Je vais modifier mon avatar en conséquence

[Edité : corrigé.]

- Je vais regarder pourquoi Nginx ne renvoie pas ça comme une image. Vu que tout se trouve dans le même répertoire, j'imagine qu'il ne doit pas être trop difficile de forcer le type... Par contre, idéalement, il faudrait que je convertisse les avatars en .png par ex. Je vais voir aussi du coté de PIL ce que je peux faire pour que ça soit un peu mieux géré.

[Edité : via PIL, ça va être "potentiellement risqué" si j'en crois la doc. Il faudrait que je passe à Pillow, plus safe, mais je n'ai pas le temps de faire ça maintenant. Du coté de Nginx, je n'ai malheureusement rien pour forcer un header (générique "image", par ex). Je peux juste ajouter un entête, mais ça fait 2 entêtes de content-type, pas sûr que ça soit mieux Je continue de chercher, notamment y a un module (mais je l'ai pas compilé avec Nginx ) qui permet ça...) C'est "marrant" parce que Nginx renvoie un Application/octet-stream, alors qu'Apache renvoyait un text/plain ^^]

[Edit (2) : ça balance du Content-Type: image maintenant... Je ne pense pas que ça soit une bonne idée de balancer un Mime générique, mais ce sera déjà mieux que les 2 autres... en attendant d'avoir un mécanisme pour renvoyer le bon type, indépendamment de l'extension, ou de forcer le type lors de la sauvegarde des avatars]

- Pour l'ip, c'est "normal" : Nginx ne répond que sur les adresses prévues, à savoir lexpage.net (redirect vers www), www.lexpage.net et vps.lexpage.net (ainsi que d'autres adresses mais qui ne sont pas liées directement au site). Je vais ajouter l'ip du serveur dans la liste, et gérer une redirection vers www.

[Edité : fait.]

- Pour Fail2Ban, je le "remplace" via iptables (compteur de connexion par IP, et vérification du compteur lors d'une nouvelle connexion).
- Pour les avatars manquants, je pense que j'ai oublié de copier les anciens Je fais ça de suite

[Edit : fait]

50 requêtes simultanées, en keep-alive avec 100 requêtes à traiter
ab -kc 50 -n 100 http://vps.lexpage.net

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       25   54  30.0     62     111
Processing:   350 5430 2217.3   6962    7332
Waiting:      316 5395 2218.8   6930    7295
Total:        412 5484 2204.3   6988    7358

Percentage of the requests served within a certain time (ms)
  50%   6988
  66%   7064
  75%   7148
  80%   7197
  90%   7276
  95%   7327
  98%   7345
  99%   7358
 100%   7358 (longest request)

ab -kc 5 -n 100 http://vps.lexpage.net

Notez que ça fait monter le CPU à 100% (forcément), mais la ram reste stable.

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       25   26   1.7     26      36
Processing:   334  691  80.3    696     899
Waiting:      302  657  79.3    660     867
Total:        360  718  80.1    722     931

Percentage of the requests served within a certain time (ms)
  50%    722
  66%    744
  75%    756
  80%    768
  90%    799
  95%    838
  98%    919
  99%    931
 100%    931 (longest request)

Et le test de base, pas forcément intéressant, mais pour la comparaison :
ab -kc 1 -n 100 http://vps.lexpage.net/

(CPU entre 10 et 50%)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       25   26   1.2     26      32
Processing:   183  199  18.3    194     294
Waiting:      152  164  17.4    159     262
Total:        209  225  18.2    220     320

Percentage of the requests served within a certain time (ms)
  50%    220
  66%    224
  75%    227
  80%    231
  90%    244
  95%    269
  98%    297
  99%    320
 100%    320 (longest request)

Pour servir via l'IP, perso, je te conseillerai plutôt de faire un nouveau vhost, qui réponde uniquement "Allez sur lexpage.net", voire avec une redirection js.
Oui, ça peut paraitre crade une redirection js, je l'assume, mais 99% du traffic que tu chopera via l'IP seront des bots, et une bonne partie de ceux-là seront des bad bots. Les rares humains sauront cliquer (ou auront un js qui les redirigera, et shuis même pas certain que ce soit une bonne idée). Les "bons" bots de crawling verront qu'il y a pas de contenu et un lien vers www.lexpage . Les mauvais, ce sont ceux qui tenteront /phpmyadmin, /admin, /wp-admin, et tous les liens possibles et connus de failles possibles, avec des mélanges de GET et de POST : ceux-là, il vaut mieux qu'ils se choppent une 404 minimaliste (juste le header 404) qui va te coûter très peu de ressource plutôt que la 404 dynamique de la vraie lexpage.

Ton blocage par IP : ah ouais, du coup tu fais pas dans la dentelle, là : 15 connexions par 15 secondes pour une IP sur le http, ça peut arriver ultra vite, surtout dans le cas de réseaux d'entreprises. Le filtre http de fail2ban, tu déclare des "alertes" (genre tout accès à /admin/), et seulement là il analyse voir le nombre de connexions, et bannit en conséquence pendant 10 minutes. Ce qui protège (un peu) contre les attaques en bruteforce.


EDIT :
50 connexions simultanées, il est un brin à la ramasse (et encore), mais ça reste très honnête vu le coût mensuel. En toute sincérité, c'était la puissance de cette offre qui me faisait le plus peur, et ça semble très honnête pour du 2€/mois !