Discussion :

[petitours]

Bonjour

j'ai installé une application JAVA (Axelor ERP), ma première appli java, sur un VPS sous Debian 9.

Ça fonctionne mais c'est extrêmement lent, à la limite de l'utilisable et ma question est de savoir si c'est normal (serveur trop léger) ou si j'ai pu me planter sur la configuration du serveur.

Le truc tourne avec
http://mirror.ibcp.fr/pub/apache/tom...-8.5.32.tar.gz
PostgresQL 10
OpenJDK8

Le serveur est un VPS SSD1 de chez OVH (1vcore, 2Go de RAM et 20Go SSD) https://www.ovh.com/fr/vps/vps-ssd.xml

Merci par avance pour votre avis et le cas échéant vos conseils

[tchize_]

Ben déjà faudrait te connecter sur ton serveur en console et regarder un peu ce qui se passe dedans. Ensuite voir quels sont les pré-requis de cette application et la charge que tu compte lui donner.

Mais c'est sur qu'un seul coeur c'est un peu chaud pour une appli web, elle va pas paralléliser des masses là dessus

[petitours]

Bonsoir avec la commande top je voyais le CPU entre 1.3 et 60% et la RAM à 45%

mais j'ai trouvé moyen de lancer une grosse tache de chargement de plugin et si la ram est monté à 49%, le CPU a plafonné à 100% pendant 15-20minutes pour un truc qui prend 2s quand je fais tourner l'appli sur mon pc...
Il semblerait que le CPU soit trés trés faible sur ces VPS. Je trouve ca étonnant vu que l'on arrive à faire tourner des wordpress archi lourdingues sur les hebergements web premier prix bas de gamme.

[tchize_]

C'est surtout que les perfs sur un VPS un thread, il ne suffit pas de prendre les perfs sur un CPU 16 threads et de faire fois 16 sur le temps de calcul. Si tu veux vraiment comparer le VPS avec ta machine, va falloir mettre un place une machine virtuelle openstack dedans, lui attribuer un seul coeur et mettre tout là dedans.
Ensuite comparer un wordpress qui tourne sur une archi mutualisée avec des dixaines de coeurs à disposition et l'appli vachement plus balaise que tu essaie de faire tourner sur un pauvre coeur... comment dire, ce n'est pas informatif.

Ton appli elle a un serveur SQL (postgres) qui a besoin de CPU, un OS qui a besoin de CPU pour sa maintenance et le réseau, ton tomcat qui par défaut démarre 200 threads HTTP (avec un seul coeur qui inclu la db, tu peux descendre ça à 10 thread http tu saura pas gérer plus) et probablement l'apache en front end pour le port 80.

Comme je l'ai dit,voir quels sont les pré-requis de cette application. Mais vu la complexité d'un ERP, je ne pense pas que les auteurs aie jamais prévu de faire tourner ça sur des machines aussi faibles.

Comme toute application si tu descend trop bas les ressources à disposition (ou si l'appli commence à consommer trop), tu va avoir des phénomène de cascades qui vont se mettre en place et t'aura un temps de réponse exponentiel. Genre ici, le tomcat a besoin de CPU pour gérer les pauvres bytes qu'il a peu recevoir en quelques ms de la DB pendant que la DB fout rien parce qu'elle attends ce même CPU, tu va avoir un effet de cascade sur le context switching. Ce serait intéressant de voir quand t'es à 50~60% de CPU, si le temps restant est de l'idle ou du temps passé en noyaux.

Pour ça faudrait voir l'output du top (les %st %sys %hi %lo ansi que les load average)

Après, ma première suggestion serait de déporter ta DB en dehors de cette VM, histoire que les deux process ne passent pas le temps à s'ettendre mutuellement.

[petitours]

Bonjour

Je m’étonnais de ça par rapport à un wordpress sur un mutualisé par ce que dans mon esprit un site comme wordpress a une appli PHP qui interagie avec une base de donnée, comme ici java interagie avec une base de donnée.
Un ERP n'est pas complexe, le métier géré par un ERP peut l’être mais de base, et à fortiori si l'ERP ne contient pas de donnée, il n'y a qu'un menu, des listes de contacts, des listes de produits... les choses plus complexes en compta par exemple sont complexes uniquement d'un point de vue comptable et juridique, dans tout ce que j'ai testé j'ai appelé aucun de ces traitements complexes alors que j'ai des sites wordpress archis surchargés de plugin inutiles qui s'en sortent pas mal malgré tout.
Donc un besoin assez similaire en terme de fonctionnement interne à mes yeux avec des traitements et surcharges plutôt coté wordpress.

Je découvre qu'un mutualisé est multi thread là où le VPS ne l'est pas. bref je suis à coté de la plaque mais pour ma défense, quand on ne sait pas on calibre le niveau de puissance avec le budget.

Ce que je constate surtout c'est qu’héberger une application php est incomparativement plus simple et moins couteux qu'autre chose (java par exemple). Je comprends mieux pourquoi php est si répandu. Je pourrais critiquer php que je n'ai jamais réussi à adopter mais ce constat m’amène plutôt à constater sa supériorité sur ce point de l'hébergement, qu'il serait formidable d'appliquer également à du JAVA par exemple.

[tchize_]

Oui, mais que tu le veuille ou non, l'architecture, c'est complètement différent. Comme dit, déjà, ici, ta db est pas mutualisée, tu la fait tourner dans ton VPS (à l'opposé de ce qui se fait en général sur du PHP). Regarde déjà le prix d'un instance minime mysql chez ovh, c'est 4 fois le prix du VPS entrée de gamme. Ensuite, en mutualisé web (php, python, etc) en dehors des requêtes, rien ne tourne en mémoire. C'est un avantage mais aussi une limitation. Enfin, tu n'a pas de garantie qu'un salopio avec du code PHP super gourmand tourne sur le même noeud que toi et ralentisse ton site web, avec le VPS t'as la garantie que le core t'es dédié. Du coup tu le paie aussi quand tu ne l'utilise pas.

Je comprends ta frustration, mais si tu chercher a héberger quelque page avec un peu de DB, c'est pas java l'outil dont tu as besoin.

[petitours]

Je comprends l'explication et la différence mais ca ne fait que renforcer mon interrogation
A quoi sert un VPS comme ça ?

On a un CPU peu puissant, incapable de gérer n'importe quoi d'un peu dynamique avec un peu de traitement d'un coté et un peu de bdd de l'autre
et qui ne serait adapté qu'à quelque chose qui tournerait en charge la plus lissée possible, tout le contraire de ce qui se passe dans la vraie vie pour une petite application qui fera rien la grande majorité du temps.

[tchize_]

ça peux servir:

- comme noeud dans une architecture type docker ou micro service
- comme porte d'entrée pour arriver sur une architecture protégée (jump host, serveur vpn)
- comme un proxy http
- pour des webservice rest simple (CRUD sur une base de données à l'extérieure du vps, front end pour un service de backup)
- comme serveur de logs (avec un storage attaché)
- comme relai dans un architecture de routage privé
- comme serveur web simple
Bref, tout ce qui ne nécessite pas de multi threading à donf mais plus de servir de relai. Ou alternativement quand on veux déployer un architecture fortement distribuée et redondante faite de plein de petits noeuds.

Ou encore pour du prototypage parce que ça coute pas cher

[fr1man]

Bonjour.
J’avais un serveur chez Online, équivalent de l’entree de gamme des dedibox avec moins de Ram et moins de disque. Ça fonctionnait très convenablement avec une application java utilisant playframework, un mysql, un nginx tout ça avec 2 go de ram. Bien sûr, il ne faut pas espérer avoir beaucoup d’utilisateurs en simultané. Ma conclusion est donc qu’on peut faire du Java sur de petites configurations si on ne charge pas trop la machine, en utilisateurs.