<div dir="ltr">My kneejerk reaction is somewhat the same. Varnish is HTTP, and should stay HTTP only.<div><br></div><div>It would be the best solution to have an HTTP to your RDBMS layer. Call it middleware if you will, or maybe in interface.</div>
<div><br></div><div>You don't really need logic for the situation you outlined, if Varnish can do the caching, all you need to do is set your HTTP-to-RDBMS layer as backend. Then it's just the standard hit/miss stuff from Varnish point of view.</div>
<div><br></div><div>If you can't write anything yourself that's fast enough to do that (in any language), it's not going to be any faster if it's part of Varnish. So last ditch effort, write something that's multithreaded or async in C to handle it.</div>
<div><br></div><div>If that is fast enough, and there's a really good reason to integrate it with Varnish we can always revisit putting it into Varnish. :)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jul 30, 2013 at 3:26 PM, Marcin Krol <span dir="ltr"><<a href="mailto:mrkafk@gmail.com" target="_blank">mrkafk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
<br>
</div>P.S. What I want to do is precisely avoiding modifying response<br>
bodies: JSONIFy/format in the backend handler, handing over typical<br>
HTTP objects to varnish in "Fetch from backend" operation:<br>
<br>
<a href="https://www.varnish-software.com/static/book/_images/vcl.png" target="_blank">https://www.varnish-software.com/static/book/_images/vcl.png</a><br>
<div class="im"><br>
<br>
<br>
<br>
W dniu 7/30/2013 14:46, Leif Pedersen pisze:<br>
</div><div class="im">> Hi,<br>
><br>
> I'm not a varnish dev but I've been working with varnish and DBs<br>
> for a long time.<br>
><br>
> My knee jerk is that you'll end up with more application logic in<br>
> vcl than vcl is suitable for. Vcl can't loop or touch response<br>
> bodies (without vmods). It'd be kind of neat to skip middleware and<br>
> plug varnish straight into the db, but I wouldn't guess it to be<br>
> worth the effort.<br>
><br>
> I'd instead write a mini web server using uwsgi or CherryPy to act<br>
> as middleware. These tools have great memory footprints and<br>
> performance.<br>
><br>
> - Leif<br>
><br>
> On 2013-07-30 6:30 AM, "Marcin Krol" <<a href="mailto:mrkafk@gmail.com">mrkafk@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:mrkafk@gmail.com">mrkafk@gmail.com</a>>> wrote:<br>
><br>
> Hello,<br>
><br>
> This is a peculiar topic that I think goes beyond typical use of<br>
> varnish so I post it here.<br>
><br>
> At my company we have a need peculiar sort of infrastructural<br>
> subsystem:<br>
><br>
</div>> - HTTP requests are done to find if smth is cached - RDBMS (mysql,<br>
> oracle) backends - Other subsystems as backends<br>
<div class="im">><br>
> Clients use unified protocol based on (simple) http requests to<br>
> get their data. (it's for this reason that we do not use caches<br>
> built into rdbms directly, as well as we do not want to do tight<br>
> coupling of a particular client to a particular rdbms or<br>
> subsystem)<br>
><br>
><br>
> Either we write the whole thing ourselves or we use smth else like<br>
> varnish.<br>
><br>
><br>
> I like the thought of using varnish, although I'm not sure if it<br>
> this is not shoehorning it into such role. However, when it comes<br>
> to caching, load balancing, failover and cached HTTP results<br>
> serving it's ideal in such role.<br>
><br>
> The only problem is backend. Essentially, what we need is e.g. for<br>
> mysql backend:<br>
><br>
> on cache miss:<br>
><br>
</div>> - connect to mysql<br>
<div class="im">><br>
> - run the query we received in GET/POST/whatever<br>
><br>
> - JSONIFy result (query results are not big in our application,<br>
> limited size of the result is a tolerable limitation for us)<br>
><br>
> - cache result, return it<br>
><br>
><br>
> on cache hit:<br>
><br>
> - retrieve from cache, return it<br>
><br>
><br>
> (and so on for other backends)<br>
><br>
><br>
> Is this feasible? Is it even sane? Should I use smth else maybe?<br>
><br>
> Essentially, what we need are pluggable, modular backends.<br>
> (obviously we can handle writing the part that transforms<br>
> particular backend response into HTTP response, the snag is how to<br>
> plug this correctly into backend usable by varnish)<br>
><br>
> I was thinking about using VMODs but none of the modules available<br>
> seem to meddle with backends themselves somehow.<br>
><br>
><br>
> Thanks! MK<br>
><br>
><br>
</div><div class="im">> _______________________________________________ varnish-dev mailing<br>
> list <a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
</div>> <mailto:<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a>><br>
> <a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
<div class="im">><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.20 (MingW32)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQEcBAEBAgAGBQJR978LAAoJEFMgHzhQQ7hOugUH/2WLtSaYO+/iLlyX/moGNBqR<br>
HTa0E1W+43vIVIeq9OLzKmmxzJm2075Erq952B9/UIVnxNDZ4jo+whOk8foo1K0Q<br>
h4A8XloKrMG1BSNnYqCsdop202YIIPI1AxX8V30slx1btjttdVedAQxwlGZ1j6NC<br>
S43z5EqJ0dKjOAv1JVTLkeAkCWJCXmYj0xIiPYNCcRQ9uR8QCA1Nm+cL3MDuzcIS<br>
TQuEW/wihy4bfNeKe5H7+GutARGHHtiJXzvzgiGFLcto0IasTUroTKN05MTuIjEE<br>
e4t7n4MfLxwninEWitF23UjCQUvoq05cZMihxMD1XjSPtG+qsK+BmyTHUqTab98=<br>
=bT0L<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
<br>
</div></div></blockquote></div><br></div>