11

I'm slightly concerned that this question is might not fit here but, as you will read, I have a lot of time on my hands...

Around release-time, Salesforce performance tends to plummet and right (in the midst of Winter 17 rollout), it's really dreadful again.

My normal development is using Sublime/MavensMate, but the connection to Sandboxes is so slow that it keeps timing out. So, I've fallen back to using Developer Console, but that is sometimes so slow that I have to fall back to the text edit function for classes in the setup pages.

And when I say slow, I mean up to 10 minutes to do one save of my code.

The only workaround I have is to work on a different pod (having trouble on cs22 at the moment). But that means making a new sandbox just for this, or delaying one project and switching to something else which happens to be on an unaffected pod.

Is there anything that can help to deal with these issues? Are some development tools more tolerant of the slowness? Is creating new sandboxes viable? Do SF support ever help with this? Is there anywhere where we can see the actual performance of SF. The "Trust" site always says everything's fine.

Improve this question
4
  • Second that! I experienced extreme slowness yesterday as well. Sent package for deployment yesterday before lunch, when i got back it was still deploying. So had to switch to dev console. Trust website was saying all pods are fine. Today deployments seem much faster though.
    – Pavlonator
    Oct 28, 2016 at 15:45
  • I've been resorting to the Developer Console as well when this happens, fwiw.
    – Adrian Larson ♦
    Oct 28, 2016 at 15:49
  • You can count a third here who has the same issues with slowdowns. This is commonplace in the developer world. Sandboxes and DE Orgs have the LOWEST priority in a Pod and SF does that for good reasons. It's most important that they provide services to their customers and not disrupt their processes. I've experienced 20 minute saves at times in the last week. For me, in Central Time, it always got worse in the afternoon on the pod I was working on through Wednesday. Other than using the console and doing the copy paste or sync with your IDE, I don't know of a good solution.
    – crmprogdev
    Oct 28, 2016 at 15:56
  • Good to know i'm not the only one doing way more in the developer console than i'd like.
    – Kasper
    Oct 28, 2016 at 15:57

1 Answer 1

Reset to default
5

I think you've already touched on some of the strategies for handling a slow Apex code deployment. I'll merge in some more here:

  1. Try making the same changes via the Developer Console.
    Why? The developer console uses the REST version of the Tooling API to deploy code changes via ApexClassMember.
  2. Try having MavensMate compile via the Tooling API as well using "mm_compile_with_tooling_api" : true
  3. Refresh the Metadata Container in MavensMate -> Utilities > Refresh Metadata Container
  4. Check you have the latest version of MavensMate
  5. Try using the Force.com Migration Tool to do the deployments via the Metadata API.
    This would indicate if the deployment speed is directly from the Metadata API or something else that is occurring with MavensMate.
  6. Try making the same changes using the classic Salesforce Setup UI for editing classes.
    It uses it's own method of saving changes via /setup/build/editApexClass.apex and is surprising robust compared to the other APIs. I have classes that can only be updated by this method. Both the Tooling API and Metadata API can't compile them, even though they run fine.
  7. Check how much you are actually deploying. Are you deploying a single apex class, or a range of dependencies as well?
  8. Hang out for the promised Salesforce DX CLI tooling to deploy the Apex classes to a fresh scratch org straight from source.
  9. The General Problem Source Make your own bespoke tooling using the API's that suites your workflow. I've gone down this path. I use third party provided IDEs to edit Apex, but then handle the deployment to Salesforce myself. I like the control and knowing exactly what is going on. There are probably many arguments to be made as to why you shouldn't be building your own tooling. If something starts to go slow in the process I can tell exactly where it is occurring.

See also:

Improve this answer
3
  • 1
    Thanks Daniel... My main frustration is in saving code rather than deploying (for deployments, I use the Gearset tool). Things seem to be running faster this week, but I'll definitely try using the tooling api for MM next time things go slow. I tried the beta of MM, but had a bunch of problems, so I gave up and went back to the latest stable, v0.0.10. This whole area makes it really hard to settle on a development tool/flow. PS That's one of my favourite XKCDs ever, but we're a small consultancy so we need the salt right now :)
    – Aidan
    Nov 2, 2016 at 8:47
  • @Aidan The Metadata API and Tooling API's are also used for saving code to Salesforce in addition to deploying to different orgs. You could save all files locally and then "save"/deploy them using force.com migration tool or direct API calls.
    – Daniel Ballinger
    Nov 2, 2016 at 19:21
  • Thanks, Daniel. I understand that possibility, but it's definitely not my style. I like to get frequent feedback from the "compiler". I guess that saving it all locally then deploying counts another strategy for dealing with the system being slow. Fewer saves to the cloud mean less waiting. Probably lots of syntactic errors, but I could always try being careful.
    – Aidan
    Nov 3, 2016 at 7:45

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.