Mark,
The fact that you don't see an authentication dialog or you're not doing anything in your application doesn't necessarily mean that there's no authentication occurring. IE on the local intranet will automatically authenticate and do 'pass through' security for you if the appropriate settings are set.
If you're unsure, fire up Fiddler and look for the authentication tokens in the HTTP headers. If they are there you're authenticating dialog or no.
My guess this has nothing to do with the VFP COM object, but is a network authentication issue. Most likely the same slowness will occur on pages that don't use the VFP COM component. Another issue to consider is data access and how the Web Server is getting to its data if its not local. That too can be very slow in a domain environment as security lookups occur.
As with any performance tuning it's crucial to isolate the problem by creating a simplified test page that you can experiment with and see which part of the Web request is actually slow: Is it the infrastructure for authentication, is it the COM invokation, is it the data access.
Guessing by what you said about local vs. domain accounts the likely issue is the domain lookup and if it is there's no good workaround short of duplicating accounts to the server so they appear as local accounts.
+++ Rick ---
>I am using a domain security. In fact, I dont do any authentication at all. Users have a shortcut on their desktops and when they click on it they get to company's web site. They are not prompt to login.
>My architecture is like this:
>I have a web based client which connects to a web server via a classic asp page. This page creates a VFP object based on an exe and that object does all the business processing.
>
>>There are any number of things that can account for this.
>>
>>What is the security being used on this server? Are you using domain or AD security? If so then that might very well account for the perf problem as users have to authenticate against the domain.
>>
>>This should be visible with plain pages as well as pages that call your VFP component.
>>
>>If your VFP component runs in COM+ you'll have additional overhead for authentication as COM+ will likely revalidate the security of the account before switching to the account that COM+ is configured under. End result you get hte security hit twice.
>>
>>All that said, Auth related performance should only occur on first hits. After that there's should only be security tokens exchanged.
>>
>>Recommendation: Doing domain based security in Web applications is a good way to kill performance and not recommended. Consider creating custom login based scheme instead especially when it is applied to the core site functionality. In any Web app I build I often use Windows Auth but only for administrative features. Any application level security is much better served by a data based and cookie driven login system.
>>
>>+++ Rick ---
>>
>>>I know that is not directly and even indirectly related to VFP but still some who develop webs mignt know.
>>>I have a failry simple web application. It consists of an asp page that calls VFP component for all business porcessing and returning data back to the Browser. everything fine, except of performance. When me or another user who is a local admin on the web server box uses an app. it works very fast, btu for all other users it works 10 times slower. I have narrowed it down to a fact that it takes much longer for IIS to call a VFP component.
>>>I am using 2003 Server R2.
>>>
>>>Hope for any idea.
