Hi Aakash, Lukas We have recently deployed our app using the same caching technique (great article Aakash), and its working quite well. We have now included the optimisations pointed out by Lukas and will check the performance after this update.
Regards, Sheldon On Sunday, July 19, 2015 at 6:35:13 AM UTC+5:30, Aakash Japi wrote: > > Hey Lukas, > > About the correctness issue: so currently, in my production code, I have a > check that makes sure that if something is inside that SELECT_FROM and is > an instance of a table, it doesn't also have the word "select" or "join" in > it, which ensures that the only things extracted are actual table names (of > course, this assumes that none of our table/column names have the words > "select" or "join" in them, which currently they don't). I think this does > what you were talking about: resetting the scope if the current querypart > is a nested query. I also thought it was a bit excessive to add this check > to the post's example, but I can definitely add a note about it. > > Your performance improvements are noted. I'll go try them out this week > when I get back to work. > > As for the feedback, we're still in the process of fully deploying this > system right now, but I definitely can make a follow-up post about how we > deployed this architecture onto a production system, how it handled load, > how much it improved performance, etc. I think that would be a good thing > to see for anyone wanting to do something similar. > > Anyways, thanks for all the help! > > From, > Aakash > > > > > On Fri, Jul 17, 2015 at 12:20 AM, Lukas Eder <[email protected] > <javascript:>> wrote: > >> Hi Aakash, >> >> First of all: I think this is the first post on your blog, right? >> Excellent first-time post, and we're very flattered that you've written >> about jOOQ as your first post. >> I've already had a couple of friends point the post out to me in the >> meantime. I've also noticed that you've posted it to /r/programming. It is >> a difficult environment. Have you considered /r/java as well? But it's a >> challenging topic. People might not read to the end before giving >> feedback... >> >> Now for a bit of feedback from my side: >> >> *Methodology:* >> >> I really like the simplicity of the examples and how you build the >> article always pointing out that "in case of this or that added / removed >> complexity, a different route might be chosen". I think a new user will >> understand the purpose of your MockDataProvider implementation. So, >> definitely great kudos for your writing style! >> >> *Performance:* >> >> Perhaps, there are a couple of performance considerations to be made, as >> these SPI implementations really heavily influence the overall performance >> of your application (e.g visitEnd is really called for each and every >> QueryPart in each and every query that you're running). As always with such >> optimisations, measuring is important to see if the effect is significant: >> >> 1. in your MockDataProvider implementation, I'd delay generating the >> inlined SQL until it is really needed. The regular expression can match >> also on the SQL statement containing bind variables, i.e. the one from >> ctx.sql(). >> 2. in your visitStart() implementation, I suspect that you could abort >> execution early if the ctx.queryPart() instanceof Table check fails. >> This would save you from creating the Clause[] array and iterating through >> it. >> 3. the same is true for your visitEnd() implementation. >> >> While such optimisations are usually premature in normal environments, >> they're not in SPI implementations. I've tried to document this in the >> following blog post: >> >> http://blog.jooq.org/2015/02/05/top-10-easy-performance-optimisations-in-java >> >> It would certainly be interesting to point this out to the reader that >> they should be extra wary about performance within the VisitListener >> implementation. In fact, I'll add remarks to the Javadoc right now. >> >> *Correctness:* >> >> An interesting bit to mention would be the fact that your current >> visitEnd() implementation might not be entirely correct when you're in a >> derived table (although, the current example probably works for your >> specific use-case). You'll still be within the SELECT_FROM clause, but a >> new subselect has "started", and you should reset the nesting scope, >> because if you're in a subselect, you will also have to be inside the >> SELECT_FROM clause of that subselect, not only inside the one from the >> top-level select. Of course, that would be excessive for your examples, but >> it might be worth mentioning. Let me know if this makes sense. >> >> *Feedback:* >> >> What would be nice (but perhaps it's a little early for this) would be a >> section in the conclusion listing advantages and drawbacks of your >> approach. Perhaps, there are performance implications. Perhaps there were >> bugs or caveats in jOOQ or in redis, etc. You may be critical, of course :-) >> >> >> >> In any case, thanks again very much for this very useful article. We've >> linked it from jooq.org/community (you're lucky, the list is sorted >> alphabetically) and will keep posting it from our @JavaOOQ twitter account >> a couple of times. And of course, if you are interested in writing a >> follow-up post, I'll be very happy to assist you! >> >> Cheers, >> Lukas >> >> 2015-07-13 19:35 GMT+02:00 Lukas Eder <[email protected] <javascript:>>: >> >>> >>> >>> 2015-07-12 2:02 GMT+02:00 <[email protected] <javascript:>>: >>> >>>> Hey, >>>>> >>>>> >>>> So I ended up making that blog post, you can see it here: >>>> http://aakashjapi.com/caching-with-jooq-and-redis/ . Tell me what you >>>> think! Also ignore that earlier reply I made to this (that was send for >>>> review), I accidentally used my other email. >>>> >>> >>> Great news! I'll read through it in a bit and give you a reply by the >>> end of the week! >>> >>> Thanks a lot for providing all this insight. This is extremely useful >>> for us, and for the community. >>> >>> Cheers >>> Lukas >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "jOOQ User Group" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jooq-user/ayTAxqTXozw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
