[erlang-questions] [HEADS UP] Emysql driver

[Pablo Polvorin]

Hello,  might be interesting to the emysql users,  just published a
first post on some optimizations we have been doing to it
http://blog.process-one.net/optimizing-erlang-applications-emysql/

It is focused on queries returning large result sets, that was our
original problem.     There are more things done but not yet had time
to complete a writting about it.  Note this isn't on oficial emysql
repo,  Jesper did try to include some of the changes, but at that time
he found some problems (thanks!),  solved now on our repo HEAD.



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



-- 
Pablo Polvorin
ProcessOne