4 Replies Latest reply on Jan 17, 2017 8:55 AM by David Spezia

    sqlproxy - published datasources

    Jeff Strauss

      Russell Christopher  Toby Erkson Matt Coles  Glen Robinson


      version 10.1.3 - (but we think this question applies to earlier releases too)


      We're seeking any and all advice on published extract datasources along with the internals of authentication from corresponding workbooks.  Does valid authentication of published datasources matter at all in terms of rendering times?  The testing we've done seems a bit inconclusive, but we do have many workbooks that seem to render longer with published datasources (14 seconds) and when converting to local embedded extracts (6 seconds), they run a fare bit faster.


      Upon opening some of the workbooks, we see sometimes invalid users (no longer working here and their id has been deleted from Tableau Server) and blank users (with prompt upon publishing).  These appear to also correspond to values in the db repository table data_connections.


      And we do see errors within the windows event viewer.  If it is a problem, do you have any ideas of how to fix?


        • 1. Re: sqlproxy - published datasources
          Russell Christopher

          Not deep on DataServer, but I have pretty much (always) found that an embedded data source will go faster than a Data Server equivalent - which in general makes sense (You're proxying your questions and answers through "yet another" layer in the app). I've also seen where the speed difference is much greater than the "small overheard" you'd be more likely to expect.


          David Spezia might have some deeper insights into the "why" on this, but I just generally take it on faith to use embedded data sources when it "absolutely, positively has to get there overnight".


          As far as the message you're seeing, doesn't look like it's part of the problem and you probably can ignore it. Here are some notes from someone else who reported this:


          worked with a sr. tech lead to review the issue and we have found that the "401 No Tableau Server User Found" error messages that appear in the Data Server and Event Viewer Application logs are benign. We were able to reproduce this behavior by opening a workbook in Tableau Desktop that contained a published data source. When the workbook is opened without first signing into Tableau Server, the 401 error is generated since the user has not been authenticated and thus the message "no Tableau Server user found". Once the user has signed into Tableau Server, the connection to the data source is successful.

          1 of 1 people found this helpful
          • 2. Re: sqlproxy - published datasources
            Toby Erkson

            No clue.  What Russell explains does make [logical] sense.

            • 3. Re: sqlproxy - published datasources
              Jeff Strauss

              yep.  It makes logical sense, though management may come down hard on me as we've set published datasources as a go-forward strategy and if rendering time is going to pay the price, then they're not going to be too happy!


              In terms of the error, we don't get it all the time.  And while I agree that it seem benign, I'm going to play with the REST API (on our dev environment) to see if I can update the internal connections and see if this helps at all.  If not, at least I get some more exposure into the REST API

              • 4. Re: sqlproxy - published datasources
                David Spezia

                Russell Christopher thank you for the incentive to reply.


                First rule of using Data Server with Tableau Desktop is to have Tableau Desktop and Tableau Server on the same subversion.  For Tableau Server 10.1.3 use Tableau Desktop 10.1.3 for best results.


                Using the new Auto Sign-In feature since 9.3 has been great for helping users be more connected (yes, the pun was intentional) in this paradigm.


                Second, the Data Server is a great enterprise feature in Tableau Server.  I support the use of Data Server for SSOT (Single Source of Truth) scenarios and extract centralization.


                Read from here with Caution:

                Usage of the Data Server does have a performance tax.  In most use cases it is negligible and is worth the tax for the efficiencies of SSOT and data extract centralization.  However, in some cases the tax can be cumbersome.


                The Data Server essentially speaks a universal proxy syntax which is then converted to the native syntax and executed by the protocol service.  Essentially VizQL speaks Chinese to the Data Server and the Data Server converts that to English to speak to the Database, the subtleties of language are always lost in translation.


                In extreme cases I have seen VizQL with the Data Server make a 644 line SQL Proxy statement that translated into a 6 line SELECT statement to the Database.  In this case the performance solution was to move to an embedded data source and a blank workbook with the data source embedded for web authoring as a central data source.

                2 of 2 people found this helpful