-
1. Re: Publishing extracts is slow (performance issues)
Yuriy FalFeb 14, 2016 7:47 AM (in response to Jon Cantrell)
Hi Jon,
It is considered to check for the following things:
1) Check if your TS disk subsystem would be fast enough.
It is wise to have a RAID-10 of SAS-6 / SAS-12 HDDs,
or even use server-grade SSDs if you can afford it.
Typically, you may have IOPS at above 1000.
2) Consider having dedicated node(s) in your TS cluster
for Data Engine process(es) together with API Server process --
and may be Data Server / Cache Server / Backgrounder ones as well.
The main reason for this is to exclude a concurrency for node cores
between VizQL-heavy transactions and Data Engine-heavy ones.
3) One last thought, and it is very hypothetical:
Since each copy of an extract is uploaded and published to TS
via Alteryx-initiated REST API call (series of calls, actually,
if you uploading a file larger than 64MB) one could test a possibility
to publish the "same" extract to TS (overwriting the one already there)
in a somewhat "overlapping" mode -- starting the next upload/publish task
in another Alteryx flow before the current one is finished.
This would create a "que" of upload/publish REST API transactions,
and if Tableau Server has enough muscles to sustain such a workload,
those transcations could be initiated with as short time-lapse as needed (say 10 minutes).
But of course, this should be carefully tested
on a non-production Tableau Server instance
before even thinking about "go-to-production".
Hope this could help a bit.
Yours,
Yuri
-
2. Re: Publishing extracts is slow (performance issues)
Jeff StraussFeb 14, 2016 10:09 AM (in response to Yuriy Fal)
How do I check disk configuration? I believe we have RAID-10, but I do not know if it's SAS-6 or SAS-12 or something else nor do I even know what this means, can you help?
-
3. Re: Publishing extracts is slow (performance issues)
Yuriy FalFeb 14, 2016 11:33 AM (in response to Jeff Strauss)
1 of 1 people found this helpfulHi Jeffrey,
These are questions to ask your HW systems engineer.
Please ask about your physical server(s) vendor model,
general HW config/ RAID config (if any) / HDD model(s).
SAS-6 or SAS-12 meant Serial Attached SCSI interface (6Gbit/s or 12Gbit/s).
If you have RDP access to your TS node(s), you may want
to look at Windows Storage Manager and Device Manager
for info about storage configuration & disk drives / volumes.
It doesn't tell much if you're running TS on a virtual machine, though.
Yours,
Yuri
-
4. Re: Publishing extracts is slow (performance issues)
Jon Cantrell Feb 15, 2016 7:00 AM (in response to Yuriy Fal)Thank you for the suggestions. I have passed them on to my server admin to see if he can implement some or all of the changes to improve performance.
-Jon
-
5. Re: Publishing extracts is slow (performance issues)
Jeff StraussFeb 15, 2016 7:12 AM (in response to Yuriy Fal)
-
6. Re: Publishing extracts is slow (performance issues)
Yuriy FalFeb 15, 2016 7:33 AM (in response to Jeff Strauss)
Hi Jeffrey,
I don't see anything to optimize further here.
Yours,
Yuri
PS The question that thrills me here in this topic
is about which part of the whole publish transaction
is a bottleneck -- whether it an upload or a publish itself.
-
7. Re: Publishing extracts is slow (performance issues)
John Kuo Feb 16, 2016 9:27 AM (in response to Jon Cantrell)I wonder if your VM (I'm assuming you are using VM's) is tuned correctly. Check out attached document.
Best,
John
-
8. Re: Publishing extracts is slow (performance issues)
Eric Axelrod Feb 16, 2016 10:19 AM (in response to John Kuo)When I see this behavior it's almost always related to poor network
performance between Tableau Desktop & Server.
Are Desktop & Server on the same local network in the same datacenter? Or
are you using Desktop on your local machine and publishing to a remote
server?
The best test to isolate network issues is to (temporally) install Tableau
Desktop on the same machine as the server and retest. If that results in a
huge performance variance then it's probably the upload speed of your
network.
Eric Axelrod
President & Chief Architect
DIGR
www.digr.io