InfoPath Dev

Hello

I am using InfoPath 2010 to develop form(s) that retrieve data from WCF web service, which, in turn, pulls data from SQL Database.  The connection settings to WCF web service functions are stored inside a data connection library, at the site collection level. To guarentee the basic performance, I haven't configured any of the data connections to "Automatically retrieve data when the form loads" - they get executed only when certain events are fired.  There is also some custom coding in C# which gets executed when data is retrieved from WCF web service for the first time.

Now, for a single user, the form loads in a second, without any hassles.  But, when we do Visual Studio driven load testing for 10 minutes without any think time and with following settings -   Max User Load - 200 with intial users = 20 and step up = 20 users, we get the following results
   Average Page Time (sec) = 31.7
   Pages/Sec = 5.69
   Avg Response Time (sec) = 12.5
   Requests/Second = 23

While the load test happens, CPU Utilization = 90% (with rigorous spikes), Memory Utilisation = 90%  on the front end.  Its a 3 server SharePoint 2010 farm with the front end and middle tier running on each of Windows Server 2008 R2 Enterprise - 4GB RAM - 4 CPU. 

What could be the reason for the high page time and CPU Utilization, when we do the load testing?  Is it because I am using data connection library?  Could the bottleneck be attributed to Form Services Settings in Central Administration?

Any help on this is appreciated.

Hi

We are using InfoPath 2010 Forms Services to render forms via the browser in SharePoint 2010 Environment. When we did Visual Studio-driven load testing on one of the forms, we observed high CPU spikes(close to 100% CPU Utilization) on all the cores on the SharePoint 2010 front end. To see if the rules, code-behind and references to data connection library (which, in turn, opens WCF service connections) were causing CPU Utilization, we did load-testing on a blank form that doesn't have any rules, code-behind and data connection library references and still, we observed very high CPU utilization on all the cores. Then, we created a form that just had an internal reference to a SharePoint 2010 List, and still, we observed very high utilization on all the cores.

So, the worry that we have is once we bring forms into a shared production environment, with high load and high CPU Utilization on all the 8 cores, it might bring the farm down.

Has anyone experienced issue regarding the above scenario?

Any help is appreciated as we are about to launch InfoPath forms live.

Hello,

Let me start off with saying I don't have a answer but this is what I'm doing.  I initially started with the same 2 tier SharePoint architecture with 1 additional sql server.  I saw similar results and became worried also.  Since we had a additional $3,000 in the budget and VMware license for 2 more hosts, I went to newegg and purchased a 2 socket 6 core =(12 CPU server) 48 gb Ram.  I finished building it  Friday (6\15\12) and installed ESXI, created the VMs and joined to vCenter.  Next I installed SharePoint and joined them to the farm (config wizard). Currently I'm  creating the cluster DNS entry and static ip for load balancing. 

 Maybe you're asking what does this mean?

I will have a three tier architecture with 3 frontend servers (3 CPU,  14 Gb Ram).

I will be able to boost my SQL backend with 1 more core and 5 more gb of RAM.(3 core 12 gb Ram)

I will boost Central Admin with 1 more core and 3 more Gb of Ram. (3 core 10 Gb Ram)

I read this article when I first noticed this issue and I'm assuming my solution should work. http://technet.microsoft.com/en-us/library/gg576954.aspx

I have 'how to guides' for most of this if you're interested and I'll post my initial tests in the coming days.

Sorry just remembered something that might help.

1. I had to change how my form loaded data. (Fiddler, SQL Profiler) This improved the page times IMMENSELY,  from 20+ seconds to 2 seconds or instantaneous.  The 'trick' is the submit.

2. Adjusted the Info Forms settings in Central Admin.  Increased most of the settings.

3. Worked with the Qdabra team on any other possibilities their expertise was invaluable...