OVH Community, votre nouvel espace communautaire.

[Suggestion] Golang sur les mutu ?


ovhweb
13/07/2016, 22h40
Je me suis mal exprimé concernant php-pm. Il n'est pas vraiment comparable à php-fpm, en fait php-pm est écrit en PHP et tourne avec php-cli (interpréteur php en console), ce n'est donc pas un moteur d'exécution de PHP.

php-pm utilise la lib reactphp permettant de faire du PHP asynchrone et s'intercale avec la gestion de requêtes http des frameworks courants, en particulier Symfony. Ca ne fonctionne donc pas avec n'importe quelle appli PHP, loin de là, mais uniquement avec les app modernes basées sur Symfony/Laravel, et aussi Drupal et Zend en expérimental. Wordpress ne fonctionnera jamais avec php-pm par exemple. Cependant, avec le standardisation des frameworks (cf. php-fig et la standardisation de la gestion http avec la PSR-7), il en supportera certainement plus à l'avenir (mais toujours pas Wordpress, car le moteur n'est basé sur aucun framework moderne, il n'est même pas du tout orienté objet... ).

Le fonctionnement est bien expliqué par son créateur ici :
http://marcjschmidt.de/blog/2014/02/...rformance.html

adudouit
13/07/2016, 17h13
Citation Envoyé par ovhweb
à chaque requête toute l'appli est réexécutée à partir de zéro
Même remarque pour les autres langages, c'est ce qui s'appelle "CGI", où le serveur web va transmettre la requête à un moteur externe ; les mod_$LANGAGE d'Apache fonctionnent aussi en CGI, mais le moteur de rendu est intégré au serveur web.

Citation Envoyé par ovhweb
[...] stocke ensuite le résultat en "byte code", qu'il peut exécuter directement
Citation Envoyé par ovhweb
php-pm [...] dont le principe est [...] faire résider l'application PHP en mémoire
Pour ce point, j'ai du mal à saisir la différence avec une mise en cache en mémoire, du moment que le cache n'est pas vidé.

J'ai pris un peu de temps pour regarder ce projet, et je ne suis pas vraiment convaincu par leurs annonces sur leurs performances par rapport à PHP-FPM.
PHP-FPM, en plus de proposer et gérer un cache, est conçu pour être utilisé en "FastCGI". Son fonctionnement consiste à garder un pool de workers disponibles pour leur attribuer une requête entrante (-> équilibrage de charge), et ils se partagent un (OP)cache commun.
Personnellement, j'ai l'impression qu'ils ont omis cette capacité lors de leurs tests et qu'ils n'en ont utilisé que le cache, d'où cette comparaison en faveur de leur solution, mais à relativiser (1 VS 20)...

Le moteur uWSGI proposera aussi un tel fonctionnement, pour d'autres langages ; il est principalement conçu pour exécuter du Python, mais il serait compatible Perl, Ruby, PHP, ... Mais plus Golang (ce qui n'est pas vraiment choquant puisque ce langage n'est pas à interpréter...).

ovhweb
13/07/2016, 11h24
En effet, le principe des applis web en python (que ce soit django, flask ou autre), mais aussi Go et autres (.NET... ), est de résider en mémoire. En gros on lance l'appli sous forme de démon qui écoute sur un port personnalisé (à définir par chaque appli), ensuite le serveur web ne fait "que" reverse proxy pour transmettre les requêtes http d'un vhost sur le port local où écoute l'appli.

Alors qu'avec PHP, l'appli vit et meurt avec la requête http : à chaque requête toute l'appli est réexécutée à partir de zéro, ce qui est bien sûr une perte de temps considérable. Les caches de code tel qu'opcache améliorent les perf en évitant au moteur PHP d'interpréter le code source à chaque fois; en gros il ne le fait qu'à chaque modif des sources et stocke ensuite le résultat en "byte code", qu'il peut exécuter directement les fois suivantes. Les seules choses qui sont persistentes entre chaque requête sont les sessions, les caches utilisateur, etc. Que ce soit avec le mod_php d'apache ou php-fpm (fastcgi), c'est le même principe.

A noter que c'est en train de changer avec l'arrivée d'un nouveau moteur : php-pm (pour PHP Process Manager), dont le principe est justement de faire comme les autres technos : faire résider l'application PHP en mémoire. Le gain en perf est donc énorme, surtout avec les gros frameworks (ZF, SF... ) puisqu'on ne bootstrape plus toute l'appli à chaque requête. La techno n'est pas encore prête pour la prod, mais c'est clairement l'avenir.

adudouit
13/07/2016, 10h33
Citation Envoyé par ovhweb
Pourra-t-on un jour héberger des applis web en Go sur les offres mutualisées ?
Go étant un langage orienté performance (compilé, [...])
J'allais répondre, de mémoire, que le principe de Go est d'être compilé pour n'être réduit qu'aux appels systèmes (ou syscalls), lorsque j'ai vu que vous le mentionnez aussi. Ce devrait donc être comme pour le support des binaires développés à partir du C, il suffirait de le déposer quelque part dans vos dossiers, d'y ajouter les droits en exécution, et hop ! Le tour est joué, non ? Mais c'est peut-être un peu naïf...
Pour les spécifications des images, l'image stable est explicitement alignée sur la version Jessie de la distribution Debian, alors que l'image legacy est un système bâtard rafistolé à droite à gauche. Mais bon, cette information servirait plus pour un binaire dynamique ; alors que pour du Go, c'est comme compiler du C en un binaire statique. Bref.

Pour ce qui est de uWSGI, nous comptons le proposer sous forme d'un moteur alternatif au moteur FPM pour PHP. Cela rendrait disponibles d'autres langages avec une espèce de "persistence en mémoire" (i.e., un cache sur le code, principalement, à l'instar de l'OPcache de PHP) plutôt qu'une utilisation en CGI où tout est rechargé/recompilé à chaque requête.
Il y aura, normalement dans le courant de l'été, une phase d'essai pour cette solution, pour évaluer le modèle retenu et les choix techniques, et avoir des retours. Sans rentrer dans le détail, ils arriveront lors des tests, les requêtes passeront toujours par le serveur Apache, et l'identification d'une application WSGI se fera à travers le .htaccess (en l'occurence, dans l'état actuel, cela ressemble à ça : UWSGI_CHDIR, UWSGI_FILE, SCRIPT_NAME). Et les retours sur cette utilisation seront les bienvenus, développer un site/application web est un métier à part entière, qui n'est pas le notre, et pour lequel nous n'avons pas une "bonne vision des choses" (avec des gros guillemets).

kingkurt
12/07/2016, 13h13
Citation Envoyé par Ludo.H
Bonjour,

Non aucun délais pour le moment.
Nous sommes toujours qu'en phase de test/discussion sur l'intégration de l'outils

Cut,

Et pour le http/2 ? Ca semble très interresant en terme de performance/vitesse

Ludo.H
12/07/2016, 13h06
Bonjour,

Non aucun délais pour le moment.
Nous sommes toujours qu'en phase de test/discussion sur l'intégration de l'outils

Cdt,

ovhweb
12/07/2016, 11h21
Ah je ne connaissais pas, voilà qui semble très intéressant en effet

Question délicate, mais... une idée du délai ?

Merci

Ludo.H
12/07/2016, 10h14
Bonjour,

Nous étudions la possibilité de déployé un moteur UWSGI, afin de pouvoir mettre n'importe quel framework derrière (symfony, django, flask, Go, etc...)
Il pourrait aussi apporter certaines évolution comme http/2 etc...

Cdt,

ovhweb
11/07/2016, 23h50
Bonjour,

Pourra-t-on un jour héberger des applis web en Go sur les offres mutualisées ?

Go étant un langage orienté performance (compilé, minimaliste, programmation concurrente), il consomme nettement moins de ressources que les moteurs interprétés classiques que sont PHP, python, ruby... Cela me semble donc tout à fait adapté aux contraintes d'une architecture mutualisée.

Qu'en pense la team ?

Et les clients, y en a-t-il d'autres qui souhaiteraient pouvoir faire du go ?

Merci pour vos avis