[erlang-questions] [HEADS UP] Emysql driver

[OvermindDL1]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130827/f6e8a17b/attachment.htm>