<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/12/2013 07:17 AM, Vladimir Shabanov wrote:
<blockquote
cite="mid:CAJpePQv+eiB828v1YxPG59TPLCcevrxgdU7apHg-xpPcfQAnRg@mail.gmail.com"
type="cite">
<div dir="ltr">2013/12/12 Adam Chlipala <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:adamc@csail.mit.edu"
target="_blank">adamc@csail.mit.edu</a>></span><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>
Interesting; so throwing at least one popular proxy in front doesn't
bring magic performance improvements. That's at least comforting from
the perspective of not challenging my mental model of how efficient the
Ur/Web HTTP binaries are.<br>
</blockquote>
<div><br>
</div>
<div>I think nginx helped my benchmark only because of it fixed
non-working keep-alive. Since nginx uses the same Ur/Web's HTTP
interface there shouldn't be any improvements on a local machine. On a
faraway machine it could help by reducing network latency by not making
new connection for each request.</div>
</div>
</div>
</div>
</blockquote>
<br>
But would you expect that latency improvement now that keepalive is
available?<br>
<br>
<blockquote
cite="mid:CAJpePQv+eiB828v1YxPG59TPLCcevrxgdU7apHg-xpPcfQAnRg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">One more thing -- in postgres (and maybe
other backends) there is a read only transaction mode (BEGIN READ
ONLY). As far as I understand ur/web already knows whether transaction
is read only or not. Setting this mode could improve the speed of query
handling. Maybe not much but who knows.</div>
</div>
</div>
</blockquote>
<br>
The compiler can do conservative program analysis that usually guesses
correctly about whether a transaction will write to the database. In
fact, that guess was already being calculated to use in XSRF
protection, so I've taken your suggestion and used it to start
transactions as read-only where it looks safe. I don't see a
performance difference on these particular benchmarks running in
Postgres 8.4, but the real comparison uses Postgres 9.1, whose manual
does suggest setting READ ONLY as a useful optimization for
SERIALIZABLE transactions (which Ur/Web uses).<br>
<br>
Thanks for the idea!<br>
</body>
</html>