Hi Leif,

The first thing to do is to find out why it's slow.

As others have said, you must have enough processes in the pool. That's easy to check, so I'll assume that's fine.

You can use the browser development tools to find out about the calls, so you can see which call is slow and how much data it's returning.

Next, use the global variables Constrain_Tests_Count and Constrain_Found_Count to find out if you are processing unnecessarily much data. You can hook into CallAction in the WebApp, zero the variables, forward send, and then check the variables. If Constrain_Tests_Count is large (more than ~100), or there is a difference between them (more than ~10), then you are using inefficient indices or constrains.

Something we found was than our ValidateSession took a lot of time due to many checks, and it runs on every WebApp call. So we just do the checks the first time it's called and then cache the result in a per-session record instead. The first call is more expensive, but from then they are cheap.

And the last thing we noticed is that the link between the web server and DB server must be fast. We had a router between them, which slowed things down, so we split the web server into 2. One external in the DMZ running just IIS with Application Request Routing, and one internal in the LAN which runs the WebApp and is on the same switched 10G network as the DB server. You can also use SPLF for this.

Good luck! =)