1 of 1 people found this helpful
There is a lot to consider here. First, server performance will (almost) always be less than Desktop performance. I'm not saying it will be a lot less, but some difference is to be expected. When looking at and rendering views in Tableau Desktop, a local connection to the data is created and used. When the views are rendered in Tableau Server, the data source itself may be contacted to retrieve the data. This means that views in Tableau Desktop will almost always be faster than in Tableau Server.
There are some options that can speed the process of rendering views on Tableau Server.
The first is to use an extract when possible. This allows the data for the dashboard to be accessed faster than retrieving from the data source itself whenever the requested data is not already in the cache.
The second is adjusting the cache in Tableau Server. Adjusting the Tableau Server cache settings will also help optimize system resource utilization. When an up-to-the-second live connection is not required using a longer cache timeout will allow you to receive the benefits of an extract without losing the security you desire. Information for configuring the Tableau Server cache settings can be found at the following link:
The third option is ensuring that there is the right number of VizQL processes for the number of users. A best practice is one VizQL process per one hundred users. When there are multiple VizQL processes, requests for data are sent to all processes in a round-robin format by the Tableau Server load balancer. Each VizQL process has its own cache governed by the cache settings set in option one above. This means that if there are three VizQL processes every third request will reach the same VizQL process and use the cached data on the process. Requests sent to the other two processes will need to go to the data source and create a new cache for that process.
All of this will have a big impact on performance. My guess is that there are too many processes running, using valuable resources.
It seems that you have several different types of connections in use, some of which are extracts (if I read the post correctly). I also see that there are Backgrounder processes on every node int he cluster. Depending on when the refresh processes are running, they could also lead to some performance degradation as Backgrounder is a very resource intensive process.
This is all just some baseline information. Without some more details, like machine specs and number of users, I can only be general.
I hope this helps a little...
Thanks Robert for suggestions .
This environment setup on windows server 2008 R2 ,we have 1 primary gateway server with 4 workers. Primary server having 4 cores and 16 GB of RAM and worker servers having 4 cores and 32 GB RAM each I have around 2500 users and if I have to say concurrent users then it would be around less then 80.
Regarding cache thing I have tried this but it was not working even users are getting stale data and they hate it .
I'm not familiar with a multi-worker environment so I don't know. If it were me, I would be contacting our account rep. for advice.
For 2500 workers and only 80-100 concurrent users, you could very likely reduce the number of VizQL processes from the 8 current to 4 or even 2 and likely be OK. You can also certainly reduce the Application server processes to 2.
In regards to the number of Backgrounder processes and their location in the cluster, that is another area to look at regarding performance. Often isolating Backgrounder processes to their own worker server can help performance.
Please understand that these suggestions are with no knowledge of the complexity of the workbooks in use, and incomplete environmental knowledge, and these factors would likely change any configuration recommendations.
Other factors that should be considered are network topography, geographic distribution of users, browser versions, and the type of connection. Your account rep may have some additional resources they can point you to, but I hope this helps as well.
First, begin with the classic best test for troubleshooting issues of type "There's a difference between Desktop and Server Performance":
- Log into Windows on the Tableau Server machine as the Tableau Server service account (AKA the "Run As User")
- Install Desktop on the Tableau Server machine
- Test in Desktop
- Open up browser
- Test in Server
The above test is great for eliminating many variables at once. Server and Desktop are similar at their core, and eliminating the network, the hardware, and the user can go a long way towards finding the culprit. You can run performance recordings in both Desktop and Server in order to identify the difference in performance (if indeed one is found in this test).
- Desktop - http://onlinehelp.tableausoftware.com/current/pro/online/mac/en-us/perf_record_create_desktop.html
- Server - http://onlinehelp.tableausoftware.com/current/server/en-us/perf_record_create_server.htm
As Rob says, Server will generally be a little slower than Desktop simply because of the additional layers and potential for intermachine traffic on a distributed system, but it generally should be on the order of seconds (or much less), and not a multiple of the Desktop figure.
In the event that you have very busy backgrounders, I'm a fan of getting them onto their own machine. Extract refreshes, as non-userfacing tasks, can afford to be laggy. Vizqlserver processes, on the other hand, cannot. Having them on the same machine means that extract refreshes can affect user views, which is something that can be avoided. That being said, I'd like to reiterate that this is mainly a concern if you have a lot of background tasks (I don't know this) and you're low on the core side (4 cores is less than I'd like to see for the 64-bit version in a worker that has a fairly full complement of server processes, as yours do).
In any case, start with the Desktop-on-Server test above. It may be revealing.
Thanks Rick for your reply
I did that test and I found that
For same workbook
Tableau desktop on my machine took approx 13 Secs
Tableau desktop on server machine took 24 Secs.
Tableau server approx 39 sec
Regarding configuration changes I tried below configuration as well but I found that performance is same as previous 39 secs for rendering .
Wow, quick work, Sunil!
- A 13-24 second diff between Desktop on one machine and Desktop on another sounds highly suspect to me.
- A 24-39 second diff between Desktop-on-Server and Server-in-browser is also suspicious.
Assuming that the above results are pretty consistent, there may be more than one factor in play here.
- Run Desktop performance recordings on both Desktop clients (make sure they're running the EXACT Desktop version and workbook file). Perform the exact same set of steps on each that will reveal the timing discrepancy. Look for differences in the performance recording to indicate where the problem lies. My bets are on rendering time, as I'm assuming query result timings will be similar.
- Run performance recording in Desktop on Server, and on Server. Again, make sure that everything is the same, republishing if needed to guarantee. If possible, run the same version of Desktop and Server (again, the guts are similar). Look for differences in the perf recordings. I'm won't guess where the diff here will be. (Maybe rendering again...?)
- Try Server with ?:render=false in the URL to see if that changes the browser timings. See About Client-Side Rendering for more info.
Perform all tests as per Rick's advices & comp, and in the end open a trouble ticket with Tableau support team. Upload all the recordings, give them clear explanations for each measurement and also point them to this thread.
Perf. recording file contains a lot of low level details and the support team could better execute a forensic analysis.
The 9.x.x version will came with a shared coherent cache for all Vizql processes, so the rendering time for the same viz but different client will be dramatically improved.
If the Backgrounder processes put too much load on the server one option is to "externalize" the duty to a 3rd party tool.
One thing that looks wrong to me is the configuration of the servers as shown in the before and after images. Seems like a bunch of changes at once. What were the times with the original server setup? Maybe just drop one vizql process instead of two? Have a backgrounder together with the data engine?
Sometimes a small change can make a big difference. As a real-life example, we went from 4 cores to 8 and increased our RAM and HDD space. Processes were still backing up and taking a long time. By simply increasing our backgrounders from 2 to 3 gave a substantial performance boost to our heavy extract environment.
I discussed with my management and IT team along with server architecture .we are going to perform a test tonight with some hardware upgrade , I will have 4 cores and 16 GB RAM on primary(Its just a gateway) and then upgraded each worker will have 8 cores instead of 4 and 64 GB RAM instead of 32 GB and we will try to our old configuration ,if will not work then I would try other configuration(dedicated backgrounder /vizql ...etc ) ,I will update here when I will get the performance result .Hoping for the best !!
I would caution you about the original configuration. Tableau Server does not work int he same way as a lot of other tools in that adding more processes is not always a great way to resolve a rendering time issue. If your users are often looking at the same information, more processes can actually slow the rendering.
Adding more cores and RAM though is always a good bet. More resources for the rendering actions.
Additionally, while there are third party tools that can create TDE files, having the Backgrounder processes on their own dedicated machine (as you did above) accomplishes the same result with less complexity and fewer points of failure.
Looking forward to hearing your results!
Tableau Server v8 1 ELB Support
Thanks for your reply again .
its just a test though ,our IT team ran a performance test on window server box and found that the processor consumption/utilization was more then 80% on different time frame . So just to check if adding more power to workers will help anything .If old configuration will not work with powerful machine too then for sure I will make changes on configuration on same powerful machine to try my luck with performance .