tschersichtschersich MemberComments: 681 Received thanks: 86 Member since: October 2010 edited August 2012
Hallo,

Das Löschen der unterschiedlichen Caches war ja schon in 3.5.x ein Krampf. Gut, dass man die Caches einzeln löschen konnte. Schlecht, dass man eigentlich nie wußte, nach welcher Änderung welcher Cache gelöscht werden musste.

In der 4.0 geht der Krampf weiter:
- Jetzt 4 statt 3 Menüpunkte für Caches und eine zusätzliche Modalbox.
- Sind das teilweise Duplikate der Menüpunkte oder nicht?
- 6 Menüpunkte in der Modalbox und nur 5 Anzeigen, wie stark der Cache gefüllt ist
- die Benamsung der Anzeige oben und unten ist unterschiedlich
- der Config Cache läßt sich laut Anzeige bei mir gar nicht komplett löschen. Bei Euch?
- Mit dem SEO Cache habe ich gerade den größten Stress. Der will sich nicht löschen. Bei 3.5.x wollte er das.

Mannomannomann. Neben den berüchtigten magic_quotes ist der Cache ("Ich habe xy geändert. Geht nicht" "Hast du den yz-Cache geleert?" "Ach ja...") der größte Aufwandstreiber hier im Forum und im Backend von 3.5.x gewesen. Da hat sich anscheinend so gar nichts getan. Bei den magic_quotes übrigens auch nicht.

Dass es automatische Löschzyklen von Caches gibt, finde ich nicht so schlecht. Aber warum muss ich denn jedes Mal auf die Suche gehen, welchen Cache ich nach einer Änderung löschen muss? Habe ich eine Änderung im Backend gemacht und speichere sie, muss sich der RICHTIGE Cache eigentlich AUTOMATISCH löschen. Es ist doch komplett sinnlos, eine Änderung zu machen, die im Frontend nicht sofort angezogen wird.

Für stark frequentierte Sites könnte man ja die Automatik noch ausknispen oder schedulen, aber das geht mir jetzt seit Anbeginn von 3.5. echt auf die Nüsse.

Und bei Euch so?

Comments

  • mmb_infommb_info MemberComments: 138 Received thanks: 9 Member since: January 2012
    moin,

    ich hab nur grossen Stress mit dem Proxy hinter dem ich hänge! ;-)
    ich kann Caches im Backend löschen wie ich will, mal sehe ich die Änderungen sofort, mal erst später. Das hat mich graue Haare gekostet, weil ich immer denke ich würde nicht richtig konfigurieren. An den Änderungen an den iFrames hab ich einen ganzen tag gehangen, bis ich gemerkt habe das es nicht an mir lag sondern am servieren der alten Seite vom Proxy/Cache
    :wtf:
  • oviovi MemberComments: 129 Received thanks: 24 Member since: August 2011
    Das mit dem Cache sehe ich ähnlich. Ich halte die gesamte Caching Architektur (und ich rede hier nicht vom vorgeschalteten HTTP Cache) sowieso für fragwürdig für so ein System, aber das würde jetzt zu weit führen...
    Darüber hinaus macht es aus meiner Sicht keinen Sinn bei jedem Frontendrequest zu überprüfen, ob z.B. die SEO Urls neu generiert werden müssen. Hier macht es doch Sinn das ganze Neubefüllen des Caches backendseitig automatisch zu steuern, oder optional das ganze über einen Cronjob laufen zu lassen. Das hat meiner Meinung nach im Frontendrequest so gar nichts verloren. Dann kann man auch auf diese Krücke mit dem hardcodierten Limit von 1000 Artikel SEO URLs pro Request verzichten. Ganz davon zu schweigen, dass sich der Cache zwischenzeitlich in einem invaliden Zustand befindet und dadurch ggf. andere Requests blockiert oder sogar im schlimmsten Fall bei genügend Traffic ein Cache Stampede auslösen kann.
    Dazu muss ich aber fairerweise anmerken, dass ich mir diesen und andere Punkte in der neuen Version noch nicht angeschaut habe. Ich bin mir auch noch nicht sicher, ob ich das tun werde, da ich mittlerweile davon überzeugt bin, dass ich einfach ganz andere Anforderungen habe, als sie so eine Standardsoftware abbilden könnte.
Sign In or Register to comment.