Lighttpd et l'expiration des images

WRInaute impliqué
Bonjour,

J'utilise Lighttpd.
J'aimerais que mes images/js et css soit conservés en cache pendant 24h .

Dans /etc/lighttpd/lighttpd.conf j'ai fait ceci :

Code:
$HTTP["url"] =~ "\.(jpg|gif|png|css|js)$" {
     expire.url = ( "" => "access 24 hours" )
}

Et j'ai décommenté la ligne : "mod_expire",

puis restart Lighttpd .

Maintenant lorsque je regarde ma page avec islow je remarque que les images n'ont pas été mis en cache et qu'elles sont rechargé a chaque fois que je fait F5 .

QUelqu'un peut m'aider à comprendre le problème svp ?
 
WRInaute impliqué
J'ai trouvé !

Donc pour ceux que ca interesse si quelqu'un tombe sur ce post , il faut activé le mod expire AVANT le mod compress. ( donc dans la liste des mod de light expire est avant compress )
 
WRInaute passionné
Moi ce que j'aime ce sont les réponse lapidaires qui n'aident en rien à résoudre le problème du genre
peu de monde utilise lighttpd

JE l'utilise et j'en suis satisfait, et je ne semble pas être le seul

lighttpd powers several popular Web 2.0 sites like YouTube, wikipedia and meebo

Mais ces sites sont insignifiants :mrgreen:
 
WRInaute impliqué
tu vas me dire les entêtes du serveur peuvent être traffiquée néamoins :

Code:
--21:44:19--  http://fr.youtube.com/
           => `index.html'
Résolution de fr.youtube.com... 208.117.236.72
Connexion vers fr.youtube.com|208.117.236.72|:80...connecté.
requête HTTP transmise, en attente de la réponse...
  HTTP/1.1 200 OK
  Date: Sun, 28 Dec 2008 20:44:19 GMT
  Server: Apache
  X-Content-Type-Options: nosniff
  Set-Cookie: use_hitbox=72c46ff6cbcdb7c5585c36411b6b334edAEAAAAw; path=/; domai                                                                                        n=.youtube.com
  Set-Cookie: VISITOR_INFO1_LIVE=8ApdoLx8fH8; path=/; domain=.youtube.com; expir                                                                                        es=Tue, 25-Aug-2009 20:44:19 GMT
  Set-Cookie: PREF=f1=10000000&gl=FR&hl=fr; path=/; domain=.youtube.com; expires                                                                                        =Wed, 26-Dec-2018 20:44:19 GMT
  Set-Cookie: GEO=b81f05a5de43540e335a0c65aa71b315cwwAAAAyRlJYvy8OACPlV0k=; path                                                                                        =/; domain=.youtube.com; expires=Tue, 30-Dec-2008 20:44:19 GMT
  Expires: Tue, 27 Apr 1971 19:44:06 EST
  Cache-Control: no-cache
  Content-Length: 75765
  Keep-Alive: timeout=300
  Connection: Keep-Alive
  Content-Type: text/html; charset=utf-8
Longueur: 75 765 (74K) [text/html]

Code:
--21:45:19--  http://www.meebo.com/
           => `index.html'
Résolution de www.meebo.com... 208.81.191.110
Connexion vers www.meebo.com|208.81.191.110|:80...connecté.
requête HTTP transmise, en attente de la réponse...
  HTTP/1.0 200 OK
  Connection: keep-alive
  X-Powered-By: PHP/5.1.6
  Cache-Control: public,max-age=3600
  Content-Type: text/html;charset=utf-8
  Content-Language: en
  Content-Location: /index-en.html
  ETag: 65dd87bb
  Vary: Accept-Language,Cookie,User-Agent
  Content-Length: 17517
  Date: Sun, 28 Dec 2008 20:45:19 GMT
  Server: lighttpd/1.4.19
Longueur: 17 517 (17K) [text/html]

Code:
--21:45:45--  http://fr.wikipedia.org/wiki/Pagina_principale
           => `Pagina_principale'
Résolution de fr.wikipedia.org... 91.198.174.2
Connexion vers fr.wikipedia.org|91.198.174.2|:80...connecté.
requête HTTP transmise, en attente de la réponse...
  HTTP/1.0 200 OK
  Date: Sun, 28 Dec 2008 20:20:59 GMT
  Server: Apache
  X-Powered-By: PHP/5.2.4-2ubuntu5wm1
  Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
  Content-Language: fr
  Vary: Accept-Encoding,Cookie
  X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=frwikiToken;string-contains=frwikiLoggedOut;string-contains=frwiki_session;string-contains=centralauth_Token;string-contains=centralauth_Session;string-contains=centralauth_LoggedOut
  Last-Modified: Sat, 27 Dec 2008 06:57:27 GMT
  Content-Length: 47590
  Content-Type: text/html; charset=utf-8
  X-Cache: MISS from sq21.wikimedia.org
  X-Cache-Lookup: HIT from sq21.wikimedia.org:3128
  Age: 1485
  X-Cache: HIT from knsq3.knams.wikimedia.org
  X-Cache-Lookup: HIT from knsq3.knams.wikimedia.org:3128
  X-Cache: MISS from knsq28.knams.wikimedia.org
  X-Cache-Lookup: MISS from knsq28.knams.wikimedia.org:80
  Via: 1.0 sq21.wikimedia.org:3128 (squid/2.6.STABLE21), 1.0 knsq3.knams.wikimedia.org:3128 (squid/2.6.STABLE21), 1.0 knsq28.knams.wikimedia.org:80 (squid/2.6.STABLE21)
  Connection: keep-alive
Longueur: 47 590 (46K) [text/html]

1 sur 3 :D
 
WRInaute occasionnel
Çà veut absolument rien dire mais c'est pas grave :roll: ils peuvent avoir une architecture bien plus complexe derrière

Sinon en gros sites on pourrait citer mininova.org
 
WRInaute impliqué
oué et encore faut il connaitre la proportion de requête traité ds leur archi, nan la preuve est là, lighty tout le monde en parle depuis quatre ans, mais ça prend pas
overalld.gif


source netcraft web server survey
 
WRInaute impliqué
julienr a dit:
oué et encore faut il connaitre la proportion de requête traité ds leur archi, nan la preuve est là, lighty tout le monde en parle depuis quatre ans, mais ça prend pas
overalld.gif


source netcraft web server survey

Que représente la valeur en ordonné ?

Bah ce n'est pas trop une preuve,

Lighty je l'ai testé et je l'ai adopté car très économe en terme de ressources et très rapide pour délivrer des fichiers.
Bon après son but n'est pas de concurrencer Apache, mais bien de le complémenter et Apache délègue les tâches les plus simples et répétitives à lighttpd.
De par sa nature, lighttpd n'est pas complet et c'est très bien comme ça, il n'est pas jusitifié de l'utiliser pour des petits sites bien que ce soit possible. C'est pourquoi il y a bcp moins de howto et de docs à son sujet sur le web.

Donc il s'adresse à des gens non-débutants et qui gèrent de gros sites.
 
WRInaute passionné
Et puis, il n'y a rien de mieux pour faire un serveur de streaming vidéos ou un serveur d'images :wink:

Quand au fait qu'il ne puisse pas concurrencer Apache, je n'en sais rien, je sais suelemnt qu'il est plus rapide et moins gourmand en ressources et qu'il me donne entière satisfaction depuis plus d'un an.

Maintenant, si quelqu'un connait un serveur HTTP qui tient 160 req/sec sur une machine à 19 Euros/mois je suis preneur :mrgreen:
 
WRInaute impliqué
fandecine a dit:
Maintenant, si quelqu'un connait un serveur HTTP qui tient 160 req/sec sur une machine à 19 Euros/mois je suis preneur :mrgreen:

bah sur un serveur à 14 avec 5 euros de licence windows IIS7 :-D
 
WRInaute passionné
Je parle d'un serveur de streaming vidéo les enfants (taille moyenne 5Mo c'est obtenus en divisant le tarfic/sec par le nombre de requête soit 801Mo/sec en pointe) :wink:

D'ailleurs, je ne connaît pas la limite puisque c'est le chiffre maximum que j'ai atteint. :oops:

Un petit match Apache/lighttpd http://www.howtoforge.com/benchmark-apa ... tpd-images

PS: e-kiwi, j'ai pas de site qui bastonnent à 1000 req/sec :cry: mais j'y travaille :mrgreen:
 
WRInaute passionné
julienr a dit:
d'accord et vlc server vs lighty pour du streaming, tu as une idée ?

tu veux parler de VLS ? Absolument aucune :cry:

En fait, j'ai decouvert lighttpd il y a un an lorsque je cherchais une solution open source pour monter un serveur de streaming vidéos. J'ai testé et comme c'était satisfaisant j'a adopté. Je ne diffuse que des vidéos en .FLV. Ensuite j'ai utilisé lighttpd pour servir les images, puis pour l'admin de mes sites (avec PHP en FCGI) et comme je suis satisfait, je continue de l'utiliser. A ce propos j'utilise la version 1.5 non encore considérée stable mais qui fonctionne sans problème.

Mais je continu à utiliser Apache pour servir uniquement des pages web (tout ce qui est statique est déporté sur un serveur Lighttpd) avec un PHP léger (trés peu d'option et de librairies liées à la compilation)
 
WRInaute passionné
fandecine a dit:
Je parle d'un serveur de streaming vidéo les enfants (taille moyenne 5Mo c'est obtenus en divisant le tarfic/sec par le nombre de requête soit 801Mo/sec en pointe) :wink:

800Mbit/s je suppose, non ?

<troll>Et puis de toutes façons, NginX c'est mieux.</troll>
 
WRInaute passionné
:oops: c'est même pas ça, c'est 81Mo/sec (et puis c'est par le tarfic mais le trafic) J'ai des rumathismes dans les doigts :wink:

ngix est surement trés bien, boa aussi, mais maintenant que je maitrise bien lighttp je vais attendre d'avoir un nouveau besoin pour faire d'autres expèriences :D
 
Nouveau WRInaute
julienr a dit:
oué et encore faut il connaitre la proportion de requête traité ds leur archi, nan la preuve est là, lighty tout le monde en parle depuis quatre ans, mais ça prend pas
overalld.gif


source netcraft web server survey

ton graphe il est super joli, mais il représente rien du tout !
lamajorité des hebergeurs mutualisés fonctionne sous apache (ex o_^_h) donc rien que ca, ca fait des dizaines de milliers de sites hebergé sur apache.

Comme tu le sais peut être, un gros site web c'est pas 1 serveur. Ce sont des centaines de serveurs voir des milliers (facebook 10.000 serveurs par exemple) dans ce tas de serveur tu as les frontaux, les serveur de contenus statique, les serveurs proxy-cache, les reverse, etc. Apache est probablement bon dans une des ces fonctions et lighttpd est bon dans d'autres.

Perso, ca fait des années que je tourne avec lighttpd et le plus gros site dont je m'occupe n'a jamais été à la peine lors de pointes à 100.000 visiteurs quotidiens et ils se portent trés bien avec ses 60.000 visiteurs quotidiens habituel.
 
WRInaute impliqué
1- c'est pas spécialement mon graphe => netcraft
2- c'est juste pour donner la tendance d'utilisation => lighty ne prend pas et pour cause (chez un hébergeur mutualisé ne pas pouvoir proposer l'équivalent d'un .htaccess au client c pas envisageable)
3- 100.000 / 60.000 ne veux rien dire non plus => dépend du matériel et du code
 
WRInaute passionné
Il faut quand même reconnaître qu'en serveurs frontaux on retrouve souvent des reverse proxy dis "rapides", cad NginX / Lighty, et que dans ce cas on a aucune trace des éventuels nodes Apache qui font tourner le dynamique.

En tous cas perso même sur du mutualisé j'utilise NginX, ne serait ce que pour gérer le KeepAlive et ne transmettre que des requêtes complètes à Apache afin de limiter l'empreinte mémoire.
 
Discussions similaires
Haut