Interesting. So you're saying that you need 30k rps to the DB, and the request rate to the front end of Varnish is much higher? If the Varnish front end is "only" getting 30k rps, then perhaps there's something you can do to improve the cacheability of objects. Otherwise, that's impressive even by my standards.<div>

<br></div><div>You're sure your DB can keep up in a useful way with 30k rps? That's not the real bottleneck, is it? I've made that mistake myself, so I feel compelled to ask. :) If so, also quite impressive that your DB can keep up.</div>

<div><div><br></div><div>Have you tried implementing this sort of middleware in node.js? Sounds like you've used node.js a lot, but not for this particular problem if I understand correctly. Perhaps it would be worth the experiment.<div>

<br></div><div><div>Here's a great read of WSGI servers with surprising performance differences. Tornado looks okay, but there is better. <a href="http://nichol.as/benchmark-of-python-web-servers">http://nichol.as/benchmark-of-python-web-servers</a><br>

<div><br></div><div>It sounds like the middleware is really trivial, and compared to the entry bar for adapting Varnish, probably worth trying several WSGI servers and/or node.js if need be.</div><div><br></div><div>I am indeed intrigued by connecting directly to the DB, but you can probably see my skepticism between the lines here in bright orange. :) Seems like a much more flexible approach to use middleware, worth a bit of extra hardware...on the other hand, maybe not worth it if the cost difference really is 10x.</div>

<div><br></div><div>- Leif</div><div><br><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 8:26 AM, 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>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>







<p>As implied by email protocols, the information in this message is not confidential.  Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated.  As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card.  Further, nothing in this message is legally binding without cryptographic evidence of its integrity.</p>


<p><a href="http://bilbo.hobbiton.org/wiki/Eat_My_Sig" target="_blank">http://bilbo.hobbiton.org/wiki/Eat_My_Sig</a></p>
</div></div></div></div></div>