Tune Varnish for pipe only operations

[Brain Stormer]

Well, the back-end servers are some how breaking the HTTP protocol in some
way, also it is HTTP/0.9 only, it just not well support by HAPROXY unless
running it in binary proxying which won't give me the capability of doing
the initial security checks and restrictions over the negotiation packets,
Varnish was the only proxy tolerating all the protocol issues and still
working!

So what you say, is Varnish cannot be tuned for doing such job efficiently ?



Thanks,
MS


On Tue, Dec 6, 2011 at 10:09 AM, Simon Lyall <simon at darkmere.gen.nz> wrote:

>
> I think varnish might not be the right tool for you, perhaps haproxy might
> better suit your needs.
>
>
> On Tue, 6 Dec 2011, Brain Stormer wrote:
>
>> I am currently having Varnish deployed as a front-end proxy for a number
>> of
>> back-end servers (media streaming).
>>
>> The back-end servers only communicate with HTTP in the initialization and
>> then complete the session with binary streams. So basically, I do some
>> checks at the `vcl_recv` then if everything is okay I `pipe` them to the
>> back-ends.
>>
>> Currently, I have absolutely NO use from Varnish capabilities of caching.
>>
>> I am currently facing CPU overhead at the `varnishd` process, I have tuned
>> lots of parts in Varnish, So...
>>
>> My question now is, How to tune Varnish to give full attention performance
>> wise to piped requests, putting into mind that all sessions keeps up for
>> hours long.
>>
>> Another question is, Do I still have to define a caching store ? I read on
>> some online resources that caching store is still needed for storage
>> regarding Varnish threads.
>>
>> Awaiting your enlightening !
>>
>>
>>
>> Thanks,
>> MS
>>
>>
>>
> --
> Simon Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
> "To stay awake all night adds a day to your life" - Stilgar | eMT.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20111206/767b19bf/attachment-0003.html>