Il y a déjà 2 bonnes réponses, mais le problème peut-être le plus important de la vie réelle n'est pas encore mentionné.
Tout d'abord, l'OP pourrait vouloir lire les 2 réponses précédentes et ce petit billet de blog pour comprendre ce que sont les Keepalives. (L'auteur n'élabore pas sur la partie sur TCPI / IP qui devient "plus rapide" plus la connexion est longue. Il est vrai que les connexions plus durables bénéficient de la mise à l'échelle de la fenêtre IP , mais l'effet n'est significatif que si les fichiers sont grand, ou le produit à retard de bande passante est anormalement grand.)
Le gros argument contre HTTP Keepalive lors de l'utilisation d'Apache est qu'il bloque les processus Apache. C'est-à-dire qu'un client utilisant keepalives empêchera «son» processus Apache de servir tout autre client, jusqu'à ce que le client ferme la connexion ou que le délai soit atteint. Dans le même laps de temps, cette instance Apache aurait pu servir de nombreuses autres connexions.
Maintenant, une configuration Apache très courante est le Prefork MPM et un interpréteur PHP / Perl / Python, et le code d'application dans le langage mentionné. Dans ce cas, chaque processus Apache est "lourd" dans le sens où il occupe plusieurs mégaoctets de RAM (Apache lié à l'interpréteur et au code d'application). Ceci, ainsi que le blocage de chaque instance Apache keepalive'd, est inefficace.
Une solution de contournement courante consiste à utiliser 2 serveurs Apache (à la fois sur le même serveur physique ou sur 2 serveurs, selon les besoins) avec différentes configurations:
un "lourd" avec mod_php (ou n'importe quel langage de programmation utilisé) pour le contenu dynamique, avec keepalives désactivé .
un "léger" avec un ensemble minimal de modules, pour servir du contenu statique (image, css, js, etc.), avec keepalives activé .
Vous pouvez ensuite étendre cette séparation du contenu dynamique et statique si nécessaire , par exemple en:
en utilisant un serveur événementiel pour le contenu statique, tel que nginx .
utiliser un CDN pour le contenu statique (pourrait faire tout le contenu statique qui vous est destiné)
implémentation de la mise en cache de contenu statique et / ou dynamique
Une autre approche pour éviter de bloquer Apache est d'utiliser un équilibreur de charge avec une gestion de connexion plus intelligente, comme Perlbal .
Ces réponses sont-elles toujours d'actualité 8 ans plus tard?
TheStoryCoder
Oui, toujours d'actualité si vous utilisez le préfork MPM. Notez qu'Apache httpd 2.4 (par exemple dans RHEL7) utilise KeepAlive On par défaut (mais ne le répertorie pas explicitement dans sa configuration - au moins dans RHEL7).
Cameron Kerr
5
Les Keepalives peuvent être bons dans certains cas, ils peuvent être très mauvais dans d'autres. Ils réduisent le temps et les efforts de configuration d'une nouvelle connexion, mais ils bloquent les ressources du serveur pendant la durée du délai d'expiration Keepalive. Exemples:
Pages avec de nombreux petits objets, clients sur modem - keepalive devrait être activé.
Pages avec quelques gros objets - keepalive ne sera pas un avantage.
Serveur avec un nombre très élevé de visiteurs uniques - keepalive doit être désactivé (sinon, les sockets et les threads resteront en mémoire en attendant le délai de keepalive et ne serviront pas de nouveaux clients).
Comme vous pouvez le voir, KeepAliveTimeout jouera également un rôle important dans l'optimisation des performances de votre serveur.
Examinez votre modèle d'utilisation et décidez par vous-même.
De cette façon, une seule connexion TCP sera réutilisée par le navigateur pour envoyer plusieurs requêtes. Habituellement, un site Web comporte de nombreux composants (page HTML, code javascript, images). Tant que ces ressources sont dans le même domaine et peuvent donc être servies par le même serveur, une connexion KeepAlive améliore considérablement les performances puisque le navigateur n'aura pas à établir une nouvelle connexion TCP.
Un navigateur ouvre généralement environ 3 connexions parallèles à un domaine. Supposons donc que votre site comporte 18 objets. Le navigateur ouvrirait 3 connexions et téléchargerait 6 objets dans chaque connexion - en utilisant le mode KeepAlive. Sans KeepAlive, il faudrait ouvrir 18 connexions TCP, ce qui est très lent.
La plupart ou tous les navigateurs modernes sont conformes à HTTP / 1.1, cela devrait donc fonctionner.
Certains proxys HTTP comme Squid ne sont pas compatibles HTTP / 1.1, mais ils demandent quand même l'utilisation d'une connexion KeepAlive.
Ce n'est que du côté client, alors que je suppose que l'utilisation des ressources côté serveur est également importante.
Morgan Cheng
L'utilisation des ressources côté serveur est plus importante que la latence perçue par l'utilisateur?
Yves Junqueira
1
Je crois également qu'il faut activer KeepAlive, mais le délai par défaut d'Apache de 15 secondes est beaucoup trop généreux car il maintient les processus bloqués trop longtemps. Je règle généralement le délai d'attente à environ 2 secondes, ce qui entraîne l'utilisation de KeepAlive pendant environ une charge de page.
Les Keepalives peuvent être bons dans certains cas, ils peuvent être très mauvais dans d'autres. Ils réduisent le temps et les efforts de configuration d'une nouvelle connexion, mais ils bloquent les ressources du serveur pendant la durée du délai d'expiration Keepalive. Exemples:
Comme vous pouvez le voir, KeepAliveTimeout jouera également un rôle important dans l'optimisation des performances de votre serveur.
Examinez votre modèle d'utilisation et décidez par vous-même.
la source
Vous devez absolument utiliser KeepAlive On.
Voir:
http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
De cette façon, une seule connexion TCP sera réutilisée par le navigateur pour envoyer plusieurs requêtes. Habituellement, un site Web comporte de nombreux composants (page HTML, code javascript, images). Tant que ces ressources sont dans le même domaine et peuvent donc être servies par le même serveur, une connexion KeepAlive améliore considérablement les performances puisque le navigateur n'aura pas à établir une nouvelle connexion TCP.
Un navigateur ouvre généralement environ 3 connexions parallèles à un domaine. Supposons donc que votre site comporte 18 objets. Le navigateur ouvrirait 3 connexions et téléchargerait 6 objets dans chaque connexion - en utilisant le mode KeepAlive. Sans KeepAlive, il faudrait ouvrir 18 connexions TCP, ce qui est très lent.
La plupart ou tous les navigateurs modernes sont conformes à HTTP / 1.1, cela devrait donc fonctionner.
Certains proxys HTTP comme Squid ne sont pas compatibles HTTP / 1.1, mais ils demandent quand même l'utilisation d'une connexion KeepAlive.
la source