[erlang-questions] [HEADS UP] Emysql driver

[Aaron France]

Thoroughly enjoyed. Looking forward to the next.


On Tue, Aug 27, 2013 at 9:16 PM, OvermindDL1 <overminddl1@REDACTED> wrote:

> I love these kind of articles on just how bug fixes and optimizations are
> done.  Look forward to the next.
> On Aug 27, 2013 10:27 AM, "Pablo Polvorin" <pablo.polvorin@REDACTED>
> wrote:
>
>> 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
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130827/4bfeb2d0/attachment.htm>