Re: Varnish and mp3 streaming on demand
In message <49945b51.90...@progis.de>, Andreas Fassl writes:
>Hi, especially the caching is very important for us, because we want to
>keep traffic away from the mp3 repository server.
>So you recommend:
>Client requests streaming on demand mp3
>- lighthttpd does streaming and requests from
>- varnish as reverse proxy/cache from
>- mp3 repository
For your information:
One of the changes I'm working on right now is to move vcl_fetch{}
up to after receiving the headers from the backend, but before
dealing with the backend.
This is necessary to be able to decide, per object, if it should be
stored in temporary (malloc) or persistent (disk) storage.
With some extra work, this will allow pass to become streaming.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish and mp3 streaming on demand
Hi, especially the caching is very important for us, because we want to
keep traffic away from the mp3 repository server.
So you recommend:
Client requests streaming on demand mp3
- lighthttpd does streaming and requests from
- varnish as reverse proxy/cache from
- mp3 repository
Best regards
Andreas
Ole Laursen schrieb:
Andreas Fassl writes:
after reading the docs it looks like I need an apache server to serve
the cached mp3 content for streaming on demand.
Any experience in configuration of this setup?
No, but I have set up a site with videos streamed with a Flash widget. We let
the video files pass through the cache unaltered with something like
if (req.url ~ "^/media/content") {
pass;
}
and send the request to a lighttpd backend. Lighttpd is easy to setup to serve
static files, modest in resource usage for this task and scales very well. The
disk cache in the operating system makes sure the files are in memory - it's
just a matter of having enough RAM to keep the requested data in memory. For
this reason, I don't think there's any point in using Varnish's cache in this
kind of setup.
Ole
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
On Feb 12, 2009, at 3:34 AM, Poul-Henning Kamp wrote: > Well, if people in general think our defaults should be that way, we > can change them, our defaults are whatever the consensus can agree on. I'm with the OP. Regardless of the finer details of the RFC, if I'm a web developer and I set the "Cache-Control:" header to "private" or "no-cache," I would expect it not to be cached by any midstream proxy, regardless of who controls it. This would be especially true if I worked for a larger organization, where some folks in another country, despite receiving a paycheck signed by the same person as me, may control a proxy layer I'm not even aware of. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish and mp3 streaming on demand
Ole Laursen writes: > just a matter of having enough RAM to keep the requested data in memory. For > this reason, I don't think there's any point in using Varnish's cache in this > kind of setup. In other words, unless you need some other feature of Varnish, you might as well route the requests directly to lighttpd. In my case, we had one server only so Varnish was convenient for multiplexing port 80 in addition to caching the dynamic HTML parts from an Apache web app. Ole ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish and mp3 streaming on demand
Andreas Fassl writes:
> after reading the docs it looks like I need an apache server to serve
> the cached mp3 content for streaming on demand.
> Any experience in configuration of this setup?
No, but I have set up a site with videos streamed with a Flash widget. We let
the video files pass through the cache unaltered with something like
if (req.url ~ "^/media/content") {
pass;
}
and send the request to a lighttpd backend. Lighttpd is easy to setup to serve
static files, modest in resource usage for this task and scales very well. The
disk cache in the operating system makes sure the files are in memory - it's
just a matter of having enough RAM to keep the requested data in memory. For
this reason, I don't think there's any point in using Varnish's cache in this
kind of setup.
Ole
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: running varnish-2.0.2 on Sun
]] Rob Ayres | Does anyone have an idea what has caused this? Not really, no. I'm going to get a buildbot slave going on Solaris so we'll hopefully be able to avoid such bugs in the future. If you have found a solution, patches are more than welcome. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: ESI include: src, alt, onerror weirdness
]] Florian Gilcher | So, I am beginning to wonder on how esi:include is implemented in | varnish or what I am doing wrong. Because - granted - the ESI | specification could be interpreted to include the element without | giving much thought on what the returned entity actually represents. | Then this would be the correct behaviour, as the backend is obviously | responding. We don't support onerror, nor alt at the moment. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
Poul-Henning Kamp writes: > If you look *really* carefully through the RFC2616, you will find one > reference to server side caches -- which they forgot to remove. I get your point (the RFC doesn't apply to Varnish). It wasn't my intention to slam Varnish for standards violation, though, sorry if it came across like that. > Well, if people in general think our defaults should be that way, we > can change them, our defaults are whatever the consensus can agree on. Cool! That'd make one particular webserver owner's job a bit easier, and I suspect many others too. :) Pros: - safer - principle of least surprise - easier management (configure this caching aspect once: in the web app) Cons - ? I guess I should open an issue about it? Ole ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
In message , Ole Laursen writes: >Poul-Henning Kamp writes: > >> We don't consider varnish a "shared cache" in the RFC2616 sense of >> the concept, because the varnish instance is fully under the control >> of the servers administrator, and should therefore be considered >> part of the server. > >As I read that part of the RFC, shared simply means shared between more than >one >user, the key part here is that it's used to signal that it's "intended for >only >one user and not a valid response for requests by other users". If you look *really* carefully through the RFC2616, you will find one reference to server side caches -- which they forgot to remove. In the end, the standards group realized, that a cache under the control of the web-server owner, is just a web-server that picks up its contents with HTTP. The reasons why client-side caches have to be so paranoid and fail back to "don't cache if confused", is that they have no knowledge or ownership of the content. A webserver owner, even if he uses Varnish as his webserver, has knowledge and ownership, and configuring things correctly is his job. >When it comes to cookies, Varnish is as default verging on the side of safety >in >by-passing the cache. > >Why wouldn't you do the same to private? Principle of least surprise? Well, if people in general think our defaults should be that way, we can change them, our defaults are whatever the consensus can agree on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
Poul-Henning Kamp writes: > We don't consider varnish a "shared cache" in the RFC2616 sense of > the concept, because the varnish instance is fully under the control > of the servers administrator, and should therefore be considered > part of the server. As I read that part of the RFC, shared simply means shared between more than one user, the key part here is that it's used to signal that it's "intended for only one user and not a valid response for requests by other users". > The fine point here is that you *know* why your headers are the way > the are, and can implement the policy you desire in your VCL, > whereas a "hostile" shared cache can only look at the headers > and do as told, not knowing the underlying reason. Yes, all well, but that's an argument for being able to configure it (which is cool), not really an argument for or against what the default behaviour is. When it comes to cookies, Varnish is as default verging on the side of safety in by-passing the cache. Why wouldn't you do the same to private? Principle of least surprise? Ole ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
In message , Ole Laursen writes: >Poul-Henning Kamp writes: >I looked up private here > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > >and it says > >Indicates that all or part of the response message is intended >for a single user and MUST NOT be cached by a shared cache. We don't consider varnish a "shared cache" in the RFC2616 sense of the concept, because the varnish instance is fully under the control of the servers administrator, and should therefore be considered part of the server. The fine point here is that you *know* why your headers are the way the are, and can implement the policy you desire in your VCL, whereas a "hostile" shared cache can only look at the headers and do as told, not knowing the underlying reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
Poul-Henning Kamp writes: > In message , Ole Laursen writes: > > >Why doesn't Varnish respect Cache-Control: private and Cache-Control: > >no-cache > >out of the box? > > Because we see those as headers you want non-friendly caches to act on, > whereas we consider Varnish a friendly cache, under your control. OK, I didn't expect that reply. :-) Is it because some backends send out no-cache and private even when they don't mean it? Otherwise I don't get it. If they do mean it, returning the same object is not safe, e.g. in my case it meant that if someone from Germany had visited the URL, all Danes would be redirected to the euro-as-currency page until Varnish let the object go. I looked up private here http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and it says Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users I'm not saying that Varnish should follow this just because it's in the standard, but I think it should follow it (as default) unless we know that most backends use private the wrong way. Ole ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Default behaviour with regards to Cache-Control
In message , Ole Laursen writes: >Why doesn't Varnish respect Cache-Control: private and Cache-Control: no-cache >out of the box? Because we see those as headers you want non-friendly caches to act on, whereas we consider Varnish a friendly cache, under your control. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
