[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: squid und debian-Packages



Hallo Marc,

Marc Haber <mh+debian-user-german@zugschlus.de> (Fr 02 Jan 2009 16:46:57 CET):
> Moin,
> 
> ich möchte gerne ein Netz, das seinen Webzugang eh schon per squid
> bekommt, über diesen Squid mit Updates für lenny (und andere Debians)
> versorgen, ohne die Anbindung zu belasten.
> 
> Das stelle ich mir so vor, dass eine Package, die einmal
> heruntergeladen wurde, für einige Tage im Squid-Cache bleibt und
> weitere Downloads unterbleiben. Das funktioniert leider nicht so wie
> gedacht, schon nach einigen Minuten erzeugt ein System, das eine
> schonmal heruntergeladene Package noch einmal laden möchte, einen MISS
> im Squid und der Squid rödelt die Package nochmal durch die
> Außenanbindung.

Du müsstest dem Squid wahrscheinlich auch sagen, daß die maximale
Object-Size deutlich größer als die voreingestellte ist.

maximum_object_size ..

> Ich muss laso den squid irgendwie dazu bringen, Dateien, deren Name
> auf .deb endet, weitgehend von ihrer Größe für 48 Stunden im Cache zu
> behalten. So wie ich das verstanden habe, krieg ich das in der
> squid.conf mit einem refresh_pattern für die regexp .*\.deb$
> eingestellt. Nur leider verstehe ich noch nicht so ganz, wie die
> anderen Parameter "min", "percent" und "max" eingestellt werden
> müssen.
> 
> Ich hab jetzt erstmal
> refresh_pattern \.deb$          1440    20%     10080

refresh_pattern \.deb$          1440    20%     10080

Für mein Verständnis (abgeleitet aus dem Kommentar bei refresh_pattern)
Wenn das Objekt im Cache liegt, hat es ein last-modified-Datum
(normalerweise in der Vergangenheit) und *kann* ein expires-Datum
(normalerweise in der Zukunft) haben. Gibt es auch kein last-modified,
dann wird wohl der Augenblick des ersten Downloads als last-modified
angesehen.

Wird ein Objekt verlangt, dann macht der Squid einen HEAD-Request auf
das verlangte Objekt, um "last-modified" und "expires" zu erfahren.
(Könnte sich ja inzwischen geändert haben.)

Wird nun ein Objekt verlangt und es hat kein expires-Datum (wird wohl
bei den Paketen so sein), dann gilt es als frisch, wenn es noch nicht
älter als 1440 Minuten (min) ist.  Ist es bereits älter als diese Zeit,
dann gilt es trotzdem als frisch, wenn nicht mehr als 20% Zeit seit der
letzten Modifikation vergangen sind. Wenn das Ding also beim Holen schon
10 Tage alt war, dann wird auch noch am 11. und 12. Tag davon
ausgegangen, daß es frisch ist. Dieser Algorithmus ist aber durch auf 7
Tage gedeckelt, würde also in unserem Beispiel gar nicht funktionieren,
da ein 10 Tage altes Objekt in jedem Fall neu geholt werden würde.

Andererseits - gemünzt auf Deinen Anwendungsfall und das Problem, daß
schon nach wenigen Stunden ein erneutes Holen beginnt, vermute ich, daß
das Objekt gar nicht im Cache ist - entweder wegen der
maximum_object_size oder aber wegen der cache_replacement_policy, weil
Dein cache_dir vielleicht fast voll ist.


    Viele Grüße aus Dresden
    Heiko
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann HS12-RIPE -----------------------------------------
 gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
 gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B -

Attachment: signature.asc
Description: Digital signature


Reply to: