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.

| improve this answer | |
  • Thank you for sharing your insight. It's amazing how little info is posted on the web about salesforce servlet.integration and how it factors into overall performance. Plenty of talks/videos on tuning VF pages for small view state and all that, but what I'm seeing is that it pales relative to the servlet load. Won't abandon that apex/VF tuning, but it helps to get a sense of the total performance picture. – Kspar Sep 20 '13 at 4:55
  • True, but since most of what I mentioned is outside the developer's control I can see why they haven't discussed in more detail. This also allows them to change it in the future as servlet.integration is now an implementation detail rather than a documented API. – ca_peterson Sep 20 '13 at 16:21
  • Understood. But I've definitely caught a few folks I'm working for off-guard with the isValid flag insight as related to ready-to-go compiled bytecode. – Kspar Sep 22 '13 at 2:36
  • @ca_peterson I am seeing a lot of problems with vf pages hanging and not fully redirecting getting stuck at the url: {CustomORG}my.salesforce.com/servlet/servlet.Integration?scontrolCaching=1&lid={ID}&eid={ID}&ic=1&linkToken={TOKEN} It seems like this could be related to jQuery noConflict or too much includeScript in the Head, but it seems impossible to troubleshoot as only the 1st load every once in a while causes the hang. Any new known issues around this? there was one closed around Static Resources not serving Zipped assets the first try. thanks – JimBtek Oct 10 '18 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.