nicht angemeldet
Wie Du schon sagst, es kann effektiver sein. Gegen einen dezidierten Cache (z.B. Varnish) wirst Du aber mit einem selbstgebautem niemals anstinken können.
varnish ist durchaus in vielen Fällen eine gute Idee. Allerdings kann ich immer dann gegen ihn "anstinken" wenn sein Einsatz nicht möglich oder nicht geboten ist. Und das trifft deutlich öfter zu als "niemals":
Zunächst einmal stellt sich die Frage ob man einen "dezidierten" (Du meinst wahrscheinlich "dedizierten") Cache, sei es nun squid, varnish oder ein anderer(*) überhaupt betreiben kann oder will. Viele können es nicht. Denn die Mehrheit der Websites wird auf Servern betrieben, auf denen der "Webmaster" keinesfalls Root-Rechte hat und der Hoster betreibt keinen Reverse-Proxy. Bleibt also, dass man sich als "Webmaster" bzw. Programmierer erstmal selbst darum kümmert, dass die Webseite so schnell wie möglich ausgeliefert wird. Das macht dann einen Reverse-Proxy in sehr vielen Fällen obsolet.
Selbst bei statischem Content kann sich das lohnen!
Wenn das WIRKLICH notwendig wird sollte man sich gleich Gedanken um eine Lastverteilung machen. Genau ein varnish vor genau einem http-Server bringt da gar nichts. Und dann muss man im Jahr 2017 auch noch über https nachdenken. Ob der varnisch sich hinter einem nginx noch lohnt? Ich weiß es nicht und habe sogar Zweifel.
*) Wenn ein Reverse-Proxy gebraucht wird, so wird wahrscheinlich ein reiner Reverse-Proxy (hier also varnish) Vorteile bieteten, denn bei Software gilt im Prinzip: wenn sie weniger kann, dann kann sie das wenige sicherer und schneller. Insofern hast Du mit dem "dedizierten Cache" prinzipiell recht. Freilich kommt es noch darauf an, wie der betrachtete Cache arbeitet und ob er alle benötigten Futures bietet (z.B. Ressourcenunterscheidung anhand von Cookies/Sessions und Post-Daten?)
Matthias Apsel