<div dir="ltr">Thoroughly enjoyed. Looking forward to the next.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 9:16 PM, OvermindDL1 <span dir="ltr"><<a href="mailto:overminddl1@gmail.com" target="_blank">overminddl1@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I love these kind of articles on just how bug fixes and optimizations are done.  Look forward to the next.</p>
<div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Aug 27, 2013 10:27 AM, "Pablo Polvorin" <<a href="mailto:pablo.polvorin@process-one.net" target="_blank">pablo.polvorin@process-one.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello,  might be interesting to the emysql users,  just published a<br>
first post on some optimizations we have been doing to it<br>
<a href="http://blog.process-one.net/optimizing-erlang-applications-emysql/" target="_blank">http://blog.process-one.net/optimizing-erlang-applications-emysql/</a><br>
<br>
It is focused on queries returning large result sets, that was our<br>
original problem.     There are more things done but not yet had time<br>
to complete a writting about it.  Note this isn't on oficial emysql<br>
repo,  Jesper did try to include some of the changes, but at that time<br>
he found some problems (thanks!),  solved now on our repo HEAD.<br>
<br>
<br>
<br>
On 5 July 2013 14:03, Garrett Smith <<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>> wrote:<br>
> On Fri, Jul 5, 2013 at 10:43 AM, Jesper Louis Andersen<br>
> <<a href="mailto:jesper.louis.andersen@erlang-solutions.com" target="_blank">jesper.louis.andersen@erlang-solutions.com</a>> wrote:<br>
>> On Fri, Jul 5, 2013 at 4:27 PM, Garrett Smith <<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>> wrote:<br>
>>><br>
>>><br>
>>> At first glance, it looks like I'd be losing the connect timeout<br>
>>> enhancements from here:<br>
>>><br>
>>> <a href="https://github.com/gar1t/Emysql" target="_blank">https://github.com/gar1t/Emysql</a><br>
>>><br>
>><br>
>> Yes, we are currently missing those changes in the code base. I only took<br>
>> branches which were updated fairly recently on github, and yours were<br>
>> overlooked for some reason.<br>
>><br>
>> I like most of the changes you have in there and most of them definitely<br>
>> should be part of the full release. I also agree that your functional change<br>
>> to the gen_tcp:recv timeout is something we want to fix. The only slight<br>
>> worry is that it may be a too big behavioral change for some people. The<br>
>> other changes are changes I want as well, so i'll probably pull them unless<br>
>> you want to prepare a PR yourself.<br>
><br>
> I'll have to look again, but the intent was that default behavior is unchanged.<br>
><br>
>> I guess the initial reason for having the TCP timeout was to catch slow<br>
>> queries and get rid of them quickly, rather than waiting around. This makes<br>
>> a lot of sense in an environment where you have a large amount of small<br>
>> queries and are not allowed to wait around. But for larger queries and<br>
>> procedure calls, this is definitely not what one wants.<br>
><br>
> A default timeout other than infinity strikes me as a very bad idea.<br>
> There are many reasons, but to your point in particular, a client<br>
> close during a transaction will trigger a rollback, which can have<br>
> profoundly negative effects on the system performance -- in many cases<br>
> much worse then just waiting for the query to finish.<br>
><br>
> Not that this should influence the library feature set, but I tend to<br>
> deal with problematic long-running queries as an out-of-band problem.<br>
> E.g. a separate monitor that looks for problem connections and kills<br>
> them (could be a sys admin in the simplest case).<br>
><br>
>> The whole decoder loop looks weird as well. It should be possible to make it<br>
>> smarter than what is it currently, but this is a future change.<br>
>><br>
>> Just drop me a note if you want to push it yourself or I should get to work.<br>
>> But it won't be this weekend, so I'll only be able to look at this Monday at<br>
>> the earliest, perhaps late Sunday.<br>
><br>
> I can tackle this -- but it likely won't be within days :)<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
<br>
--<br>
Pablo Polvorin<br>
ProcessOne<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>