serveur Web d'applications hautes performances en C / C ++
Existe-t-il un serveur Web hautes performances (idéalement événementiel et open source) en C ou C++?
J'aimerais pouvoir l'utiliser en ce qu'il appelle une méthode/fonction dans mon application avec une classe/structure de demande HTTP remplie, puis je peux lui renvoyer une classe/structure de réponse HTTP remplie.
S'il n'est pas open source, j'aurais besoin d'un support intégré pour les connexions à longue interrogation, la persistance, etc. — sinon, je pense que je peux ajouter ces choses moi-même.
Si vous ne connaissez aucun de ces serveurs disponibles, recommanderiez-vous d'écrire mon propre serveur Web pour répondre à la tâche? Il ne peut pas être basé sur un fichier et doit être écrit en C/C++ hautes performances.
Edit: je pense à quelque chose comme le Ruby Mongrel pour C, si cela aide.
J'avais les mêmes exigences pour mon travail, j'ai donc évalué un certain nombre de solutions: mangouste, libmicrohttpd, libevent. Et je pensais aussi à écrire des modules nginx. Voici le résumé de mes découvertes:
nginx
J'adore ce serveur et je l'utilise beaucoup. Ses performances et son utilisation des ressources sont bien meilleures que celles d'Apache, que j'utilise également mais que je prévois de migrer vers nginx.
- Très bonne performance accordable. Fonctionnalité riche. Portabilité.
- L'API du module n'est pas documentée et semble être très détaillée. Voir ceci module nginx hello world comme exemple.
- Nginx n'utilise pas de threads mais utilise plusieurs processus. Cela rend l'écriture des modules plus difficile, il faut apprendre l'API nginx pour la mémoire partagée, etc.
mangouste
- Tout le code du serveur est dans un seul fichier mongoose.c (environ 130 Ko), sans dépendances. C'est bon.
- Un thread par connexion, donc si vous avez besoin de simultanéité, vous devez configurer beaucoup de threads, c'est-à-dire. élevé RAM utilisation. Pas trop bon.
- Les performances sont bonnes, mais pas exceptionnelles.
- L'API est simple mais vous devez composer vous-même tous les en-têtes HTTP de réponse, c'est-à-dire. apprendre le protocole HTTP en détail.
libmicrohttpd
- Projet officiel GNU.
- L'API verbeuse me semble gênante, bien que beaucoup plus simple que d'écrire des modules nginx.
- Bonnes performances en mode keep-alive (lien vers mes benchmarks ci-dessous), pas si bonnes sans keep-alive.
libevent
La bibliothèque Libevent a un serveur Web intégré appelé evhttp.
- Il est basé sur des événements, utilise libevent pour cela.
- API facile. Construit automatiquement les en-têtes HTTP.
- Officiellement monofil. C'est un inconvénient majeur. J'ai trouvé n hack , ce qui fait que plusieurs instances d'evhttp s'exécutent simultanément en acceptant des connexions à partir du même socket. Je ne sais pas si tout est sûr et robuste.
- Les performances de evhttp à un seul thread sont étonnamment médiocres. Le hack multi-thread fonctionne mieux, mais n'est toujours pas bon.
G-WAN
projet G-WAN n'est pas open source, mais je voudrais en dire quelques mots.
- Très bonnes performances, faible utilisation de la mémoire, exécutable de 150 Ko.
- Déploiement de servlet très pratique: il suffit de copier le fichier .c dans le répertoire csp et le serveur en cours d'exécution le compile automatiquement. Des modifications de code ont également été compilées à la volée.
- API simple. Bien que contraint à certains égards. Fonctionnalité riche (json, magasin de valeurs-clés, etc.).
- Instable. J'ai eu des erreurs de segmentation sur des fichiers statiques. Se bloque sur certains exemples de scripts. (Expérimenté sur une installation propre. Jamais mélangé de fichiers de versions différentes).
Binaire 32 bits uniquement(Plus maintenant).
Comme vous pouvez le voir, aucune des alternatives existantes ne m'a pleinement satisfait. J'ai donc développé mon propre serveur, qui est ...
NXWEB
Points forts de la fonctionnalité:
- Très bonne performance; voir les repères sur la page du projet
- Peut servir des dizaines de milliers de demandes simultanées
- Petite empreinte mémoire
- Modèle multithread conçu pour évoluer
- Base de code exceptionnellement légère
- API simple
- Gestion décente du protocole HTTP
- Connexions permanentes
- Prise en charge SSL (via GNUTLS)
- Proxy HTTP (avec pool de connexion permanent)
- Prise en charge des fichiers non bloquants (avec cache de mémoire de petits fichiers configurable; service de fichiers pré-encodés gzip)
- Conception modulaire pour les développeurs
- Peut être exécuté en tant que démon; se relance en cas d'erreur
- Open source
Limites:
Dépend de la bibliothèque libev(Plus maintenant)- Testé uniquement sur Linux
Je suggère d'écrire un exécutable FastCGI qui peut être utilisé avec de nombreux serveurs Web hautes performances (même ceux à source fermée).
Je vais suggérer la même chose que Axel Gneiting - mais j'ai fourni une réponse avec mes raisons pour adopter cette approche:
1) HTTP n'est pas un protocole trivial - écrire votre propre serveur ou modifier une solution standard est une tâche très complexe - beaucoup plus complexe que d'utiliser les API disponibles pour implémenter un moteur de traitement séparé
2) L'utilisation d'un serveur Web grand public (non modifié) devrait vous fournir plus de fonctionnalités que vous n'en avez besoin (vous avez donc de plus en plus d'espace).
3) L'utilisation d'un serveur Web grand public (non modifié) signifie généralement qu'il a été beaucoup plus largement testé et documenté qu'un système homebrew.
4) .. et il est plus probable qu'il soit sûr et stable.
5) En utilisant fastCGI, vous pouvez utiliser toutes sortes de langages pour développer votre traitement back-end en - y compris C++ et C. Il y a boîtes à outils standard disponibles pour faciliter cela.
6) en variante, de nombreux serveurs Web prennent en charge l'exécution de moteurs d'interprétation en cours (par exemple, mod_php, mod_Perl). Je déconseille cependant d'exécuter votre propre code natif en tant que module.
Il ne peut pas être basé sur un fichier.
Eh? Qu'est-ce que ça veut dire?
mangouste: un fichier. Simple et facile à utiliser. pas un asycn io mais parfait pour des applications intégrées et particulières.
gwan. excellent. pas de plantage. configuration ultra bien planifiée. très intelligent et facile pour le développement c/c ++ en d'autres termes, api sensible très propre par rapport à nginx. fournit un fil par noyau. ou tout ce que vous spécifiez. un excellent choix. plus grand inconvénient (peut-être que je manque dans ce domaine): ne peut pas passer par le code.
libevent: le thread unique n'est pas un inconvénient sur une machine monocœur. après tout, son point est une entrée/sortie asynchrone. possède des multithreads pour d'autres cœurs.
nginx: aucune expérience personnelle. gagner du terrain sur un serveur inégal. (API terriblement confuse)
boost asio: une bibliothèque c ++ pour asynchio (asio). impressionnant. a besoin d'une api conviviale de niveau supérieur pour les simpletons comme moi. et d'autres qui proviennent de php, Java, javascript, node.js et d'autres langages Web.
bouteille python: génial 1 fichier lib (framework/système) qui facilite la construction des applications web python. a/est un serveur httpd intégré, comme libevent et node.js
node.js: serveur asyncio javascript. une excellente sélection. malheureusement, il faut programmer en javascript qui devient fastidieux. alors qu'il y a quelque chose à dire pour faire le travail; il y a aussi quelque chose à dire pour s'amuser pendant le processus. j'espère que personne ne propose node.php
Je suis un passionné nginx utilisateur; nginx est écrit en C; nginx semble pouvoir fonctionner pour vous. Si vous voulez la meilleure vitesse de nginx, je ferais un module nginx. Voici modules tiers que vous pouvez examiner pour avoir une idée de ce dont il a besoin.
En ce qui concerne l'exigence d'interrogation longue, vous voudrez peut-être jeter un œil aux modules http Push.