I’m assuming that servlet.integration represents the loading and launching of an apex program (VF, Controllers and all) into a java servlet runner. It appears to take a long time for the first apex url for my app to show up, replacing the servlet.integration url. Is that because the servlet runner has refreshed its heap/memory in between invocations? The behavior feels similar to running a servlet in an app server where the 1st invocation takes awhile, but subsequent uses of the servlet’s functional are very fast to respond.
Also, is there any aspect of an apex application that would cause for a long period of loading, such as the mere size of the app or complexity of code?
Through the API you can check if your apex classes have compiled bytecode stored in the database via the ApexClass’s isValid flag. If this is false there is no available bytecode for the class and the first time it’s referenced it will need to be compiled before it begins executing. This can take upwards of 15 seconds for highly complex classes and their dependent classes (although that’s an extreme case, I’d say 5 seconds is much more likely). The exact mechanics of when the compiled bytecode is removed have varied over time, and are an implementation detail salesforce doesn’t disclose, so depending on what you’re doing in your org this could potentially be happening quite often during development and testing.
Beyond that visualforce pages are served from a seperate domain which operates with a unique and lower-priviledged sessionId. The first time in a session your invoke a visualforce page a seperate redirect will need to be done to generate a session and set the relevant cookies for the visualforce domain, this can also contribute to a delay here.
Beyond that the exact mechanics of servlet.integration are a mystery, and I’m not sure what it does that couldn’t be accomplished by iframing the /apex/namespace__page URL instead of using a separate servlet. I’d wager that legacy reasons are in play for it’s continued existence.