TM1 Client over WAN

[paulsimon]

Dear all

I am working at a client who has a remote operation in another country. They have installed TM1 on several PCs there, and are connecting to a TM1 Server in the UK. The connection has a latency of 24ms for the round trip time.

Server Version 9.1.4.
Client Version 9.1.3 U1

Response times are 3-10 times slower than those in the UK.

1) Does anyone else have experience of a similar configuration?

1a) Is this sort of slow down typical with this sort of latency?

1b) What is the practical maximum latency for the fat client TM1? The Cognos documentation gives a minimum requirement of 100ms, but it appears that the pratical minimum is far lower than that.

We are also getting periods of extremely poor response, where, eg it can take 3 minutes to login, despite there being nothing that significant being run on the TM1 Server, and despite people in the UK being able to login in minutes.

2) Does anyone have any idea as to what might be causing this variability? Network Sniffer tests have not revealed anything significant, but they have not been run at the time that the network has been exceptionally slow.

3) Does anyone have any tips to improve performance using the client? We are already using DBRWs.

If there is no other way to improve performance using the standard client, the alternatives seem to be:

A) Screen Remoting
B) TM1 Web
C) Other Front End

My preference based on previous experience would be Screen Remoting. However, most of my previous experience has been with Citrix. The IT dept here prefer Terminal Services.

4) Does anyone has experience in setting up Terminal Services with TM1? What the limits in terms of numbers of users per server?

TM1 Web would require a re-write of existing spreadsheets and a change of habits as many existing spreadsheets are multi-sheet.

The issue with other front ends such as Cockpit is the cost, and the move away from the familiar Excel front-end which would encounter a lot of resistance.

Any advice/opinion would be appreciated.

Regards


Paul Simon

[David Usherwood]

Paul, I can't offer serious expertise on this (I'd probably be asking you ) but yes, the TM1 Excel addin does seem to do Wans very poorly. Of the options you have been offered Terminal Services sounds the best. Citrix is better, but WTS is really Citrix Lite. Get the ITers to say how many Excel users they will support and the TM1 connectivity won't add much overhead (assuming the TS box is close to the TM1 server box).

I've certainly seen some tests suggesting that TM1Web is not all that light over slow links (lots of generated DHTML).

I use TM1 over WTS quite a bit myself to link into our own network, using Hamachi (http://en.wikipedia.org/wiki/Hamachi). The owners are trying to turn into into a revenue stream (fair enough) but it still works. But that's a single user over ADSL - not really the situation you describe.

And....
What's Cockpit?

[mattgoff]

Performance over WAN is pretty much unusable unless you have a fast network and the clients are relatively close to the server. If you do some searching (possibly in the archive from the old server) you'll see a lot of info-- someone even did some packet analysis.

We have servers in San Francisco, London, Paris, Beijing, Singapore, Taipei, and Sydney. I can deal with connecting directly (from London) to the Paris server, but I use remote desktop for the rest. Our NYC team complains about performance to the SF server. We experimented with Citrix but did not deploy it for budgetary reasons; instead we use TM1 Web for basic users and RDP for power users.

Don't even get me started on replicating between all of these servers. Fragile at best....

Matt

[paulsimon]

David

Cockpit is the front end from CubeWare. I have only seem a demo, but it looked pretty good. It is a true report builder rather than just a cube browser, and it does allow data entry.

Regards

Paul

[paulsimon]

Matt

We've done some packet analysis too. It proved that for bigger spreadsheets that there is a lot of data going to and from the server. Generally as much going to as going from. I guess is that is because the spreadsheet needs to send over the layout and all fields need to get translated from name to internal id on the server.

I was hoping that someone had some guidelines as to what is considered a WAN. It appears that even at a latency of only 24ms that performance is not so good, and the issue is not so much the average time, but the variability.

Our other users are in Italy, further than Paris, but not as far as the other countries you mentioned. (San Francisco, London, Paris, Beijing, Singapore, Taipei, and Sydney)

My experience with TM1 Web has not been good. Issues over formatting, the need to design for TM1 Web, and as David points out, it is not that thin. I do know other people who have reasonable solutions with it, but I don't think it would be appropriate here.

I agree with you over replication.

I would prefer a web enabled application building solution like Cockpit, however, the users want something Excel based.

Regards


Paul Simon

[mattgoff]

It's a slow week, so I (finally) installed Wireshark and started taking a look at this. I'm running TM1 9.1.4 x64 Server (remote) and TM1 9.1.4 x86 Perspectives (local). I ran these numbers while at home and connected over 8Mbit DSL and VPN, so that increased latencies a bit. Our concentrator is in the same data center as the TM1 server. For now, I'm just looking at Perspectives and cube viewer performance.

Opening my main P&L cube required 2,567 packets and 400 kB (r/t). Payloads were small: the average packet size was only 156 bytes (66% under 160B). I'm not really sure why the client->server bytes spiked at the end. It was one four-packet set totalling 4,394 bytes.

bytes and packets per second

shark.gif (27.67 KiB) Viewed 8529 times

From this, it's obvious why my WAN performance is so bad. Normal latencies were 40-60 ms so 50 ms * 1,300 packets = 65s, very close to the 71s Wireshark recorded. Everything appears to be sent one packet at a time with app-layer acks, so that many packets are emphasizing latency.

For comparison, I opened my currency cube which was easier to get details. The cube has five dimensions. The default view has two of them in the "page" area, two as row headers, one as column headers. So, here's what needs to be sent when the cube is opened:

Page Header Dim 1: 2 element names
Page Header Dim 2: 13 element names
Row Header Dim 1: 34 element names (only 8 displayed as result of zero suppress)
Row Header Dim 2: 13 element names
Column Header: 62 element names (only 13 displayed as a result of subset)
Data: 1,224 cells (visible, zero suppress rows active)
Other: formatting data, list of views, zero suppress flags

This required 1,080 packets and over 170 kB (r/t).

Next step is to reconfig my dev server to disable SSL and see if anything is human-readable in the packet payloads.

Matt

[paulsimon]

Matt

Thanks for your efforts. It seems that you are confirming what we found, namely that TM1 Client-Server communication generates a lot of packets. You mentioned that you had a lot of small packets. On our 54000 cell monster view we found that about the first 30 packets were quite small at around 150-200 bytes. However, after that the rest were 900-1300 bytes which is using most of the packet size. I think the default of Ethernet is around 1400. At first we thought that TM1 might have been running as a DBR even though the sliced View had DBRW. It was only when we looked further down the output that we noticed the larger packets. Our calculations showed, that for the amount of data sent, it was working out at around 12 bytes per cell, which is in line with what I understand TM1 requires to store a cell in memory.

Regards

Paul Simon

[Steve Vincent]

Some input from what i've seen here;

Latency seems to have little to do with it, it is the packets sent / received that slows it all down. Distance isn't the issue either, we have our server based in one location and a lot of users 25 miles away on the same LAN (don't ask how thats set up because i haven't a clue!). They have no issues with speed at all, but other users just 8 miles from the server will take up to 2/3 mins just to log on to TM1, unless they use Citrix in which case they are just as good as a local connection. They are not on the LAN, but some odd remote connection. Just ask Garry Cook how frustrating that link is

Excel files will magnify those issues 100 fold, no matter how well written they maybe. I've seen a file that took 15/20s to do a complete refresh and save as locally, yet take 20 mins on a remote connection. If a user was creating 50+ files (quite common) then say bye bye PC for the day. Over Citrix it was no different to the local times. I even had one poor user accidentally take the server down trying to refresh a spreadsheet on a remote site without using Citrix. Wasn't his fault, no one had told him how to but the timing couldn't have been worse and we even had our Finance Director asking for his name for someone to blame

Rule is anything outside the LAN the server is hosted on should always use terminal services of some type. Doesn't matter on location or anything else, just the config of the network.