Hello,

I have been seeing very slow performance in connecting to a OLAP server from
a client on a different machine. Originally I was connecting from a ASP.NET
page, but I have it localized to a simple test app which creates a OLEDB
connection using MSOLAP.2 provider to a remote database. If I simply create
the connection, open it and close it, it takes 15 seconds. If I put this is
a loop, each interation takes 15 seconds so it is not a .Net Jit delay.

In my normal application after the 15 second connection delay I can issue a
MDX query and the results are returned in 10's of ms. So the connection is
being established but it takes a very long time.

If I use the same application on the OLAP server and connect locally, it
connects in ms. Everything is running SP3a. My query string has just the
provider specification and the Data Source defined. No other options set.

This connection delay is making my application unusable, does anyone know
what is going on? Or how I could futher diagnose it?

Other details. AS 2000, SP3a. All machines running Windows 2003, no SP.
Client machine just has AS Client components. Reproducible on two different
client machines.

Help?

Thanks in advance,
Mark

What is the time needed to lookup your NT credentials on the NT domain?
Try this experiment. Create a virtual directory (configured to use NTLM) on
the web server. Then in the folder create a simple readme.htm file which
just says hello. Then put an ACL on it so that only your NT account can read
it. Look at it from a remote client machine in an account with no access
(confirm that you get an error); look at it from the same client machine in
an account with access (confirm that you get the "hello" message). Now.. how
long did it take for the rendering of the Hello html page? That will tell
you how long it took to get your NT credentials.

Analysis Services has to do the same thing. It has to impersonate you on a
thread. That impersonation needs to do a lookup of your NT credentials. One
of the delays which you are mentioning could be from the validation of those
credentials :-(

Just a thought. From your description that is the first place I'd look.
--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Mark" <Mark (AT) discussions (DOT) microsoft.com> wrote

Thanks for the suggestion. I figured out the problem.

Turns out AS does a Reverse Domain Name lookup during the client connection.
The DNS server on the network didn't have this reverse lookup zone
configured. Once this zone was configured and PTR records were add for the
machines, the connection time dropped to 15ms, from 15 seconds.

Unfortunately the only place I found mention of AS doing Reverse lookups was
in an unrelated KB article (828280) on using Kerberos with AS. It was
mentioned as a Note in the body of the article. Maybe this should be made
more clear, it would have saved me lots of time...

Thanks for the reply...
Mark




"Dave Wickert [MSFT]" wrote: