6

We're experiencing extremely long deployment times even when deploying single classes using the force.com IDE plugin to eclipse. The deployment takes up to 1 hour yet running all unit tests from the web GUI takes a few minutes.

During deployment the eclipse.exe process uses 25% CPU but we don't know what it's doing. We enabled a debug log in the Web GUI for our user but nothing was logged during deployment.

How can we speed things up?

How can we profile what is going on?

UPDATE: I deployed a class by editing it directly on the production server in eclipse. The save takes forever again but I noticed in the web GUI that the class is deployed and the deployment (under Setup -> Deploy -> Monitor Deployments) is complete. So basically eclipse hangs for 1 hour after deployment for no apparent reason and nothing helpful in the logs.

Possible solution: wait till deployment is finished and kill eclipse!

Improve this question
7
  • 4
    My first reaction is basically "get used to it" since long deployment times are a reality in the SFDC world. That said, 25% CPU throughout deployment seems odd to me. Have you tried deploying using the Force.com Migration Tool (aka Ant)?
    – jkraybill
    Jan 22, 2013 at 3:31
  • Thanks, though I'm not quite ready to learn Ant unless this is the only thing which will help.
    – Marc
    Jan 22, 2013 at 6:55
  • It's worth a shot, and takes less than an hour to install and try your first deployment. The docs are pretty good. You don't even need to learn how to compose a package.xml (the basis for the retrieve/deploy instruction) because Eclipse creates these automatically based on what you select in "Project Contents".
    – jkraybill
    Jan 22, 2013 at 6:59
  • Yep, ant (from the commandline) deploys in 26 seconds! Now, I want to be able to deploy individual files from eclipse using ant so that I don't have to fumble around with XCOPY and package.xml stuf. Can you point me in the right direction @jkraybill?
    – Marc
    Jan 23, 2013 at 13:37
  • I don't use eclipse for deploys at all, so can't really point you in the right direction. What I do is I've got a small batch file that copies my dev environment credentials to build.properties, then does an "ant retrieveUnpackaged", then copies my target env credentials to build.properties and does and "ant deployUnpackaged". Meanwhile I keep my current changeset in a package.xml file and use that in my version control system. Not sure if that's what you're looking for, but it's fast and is minimal manual effort.
    – jkraybill
    Jan 24, 2013 at 4:03

7 Answers 7

Reset to default
3

When you deploy any Apex at all, even one class, all of the test methods in your org will run. Depending on how much Apex you have, how much test data you generate, this could take a long time.

To speed things up, there are some options you have such as reducing your bulk test batch sizes (for instance if you are testing 200 records, try reducing that to 100).

Improve this answer
5
  • As far as I know if you use a development environment a regular save, upload and deploy will not trigger all tests to be run.
    – user254875486
    Jan 21, 2013 at 18:59
  • @Lex - "developer edition" is special, same with sandboxes. You can edit Apex there so "save" is straightforward. There's a hidden feature to enable editing apex right on production but good luck convincing SF support. In normal circumstances deploys are the only way
    – eyescream
    Jan 21, 2013 at 20:16
  • @eyescream Really?! You can get sf to allow you to edit apex directly on prod w/o going through a deploy? Do you know what the black tab name is?
    – Greg Grinberg
    Jan 21, 2013 at 21:53
  • @Lex is correct, you can open your production org in eclipse and manually copy code into production classes. It is markedly faster but sometimes you need to deploy multiple objects at once and then you sit waiting.
    – Marc
    Jan 22, 2013 at 6:49
  • @Peter, while I do use SeeAllData my tests select only single rows (or very few). The thing is when I run all tests from the web GUI its done in a few minutes so the tests can be fast.
    – Marc
    Jan 22, 2013 at 6:50
3

I discovered recently that by lowering the log filter levels on your classes (after all testing has been done, of course) Eclipse deployments are noticeably faster. The effect is passed on to method calls, so only your test classes need to be changed.

enter image description here

I have not done any actual comparison on the difference, but when I did that my deployments went from getting 3-4 600 second time-out prompts down to 0-1; roughly 40 min to ~6.

My theory, for what it's worth, is 1) reduced writing to the Debug Log will process faster and 2) more importantly, a smaller Debug Log means much less data has to be sent back and formatted in Eclipse. This note seems to support the idea a bit.

Improve this answer
1
  • I would follow this idea through if my deployments via Ant were also taking a long time. But using Ant I can deploy to PROD with tests in 20s. I am convinced the force.com plugin is misbehaving and polling too long. Could be because I am using Eclipse 4 (Juno) and JDK 1.7 which ain't supported...
    – Marc
    Jan 29, 2013 at 7:37
2

Do you have lots of unit tests that have many DML statements? Do you have lots of System.runAs() or maybe often create new Users as part of test data setup?

Poor man's profiler would be to periodically refresh the Setup -> Monitor Deployments tab and observe the counter "N out of M tests (X errors)".

Try to perform same deployment but via changeset. It won't appear in "monitor deployments" but it will be in the "inbound changesets". If it will be noticeably faster - you have both a temporary workaround and a hint that something is wrong with your Eclipse... Maybe try allowing it to use more memory? http://wiki.developerforce.com/page/Force.com_IDE_FAQ#How_do_I_solve_out_of_memory_issues.3F

I like Migration Tool because it can write down to log file the actual results of the polling server for status update. Eclipse is stupid and will just increment some counter in the dialog for you, Migration Tool will also return back with name of the class currently being run. My point is that if it will be showing same class across 10 minutes - you know which test you should optimize ;)

I think similar kind of polling with more details is offered if you deploy via Workbench.

Improve this answer
2
  • My unit tests are not excessive in terms of DML. At least AFAIK. But how could I tell for sure - there is no log during deployment :-( Is there a chance that the IDE is getting into a loop and re-running the same tests?
    – Marc
    Jan 22, 2013 at 19:05
  • I've not yet heard of workbench, must look into that though the wiki page doesn't mention unit tests.
    – Marc
    Jan 22, 2013 at 19:06
2

Yeah, I have faced the same issue. Following is my experience,

  1. If you deploy from a Sandbox to the Production, I really suggest Change Set but not Eclipse, as Salesforce will handle everything for you after you submit the Change Set.

  2. Do not enable (SeeAllData=true) in your Test class, you have to always make test data in your Test class.

    The reason is once you use real data for test it will usually take a long time.

    And the most important is when the real data changed, it may cause your Test class failed. Then you can barely do anything. Since even before you can delete a Apex class in Production, Salesforce will force you to pass all Test class first. If you can't pass the Test, you have to revise the data to meet the Test class, and if you are in a large org. it will take a long time.

Isolation of Test Data from Organization Data in Unit Tests http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_testing_data_access.htm

Improve this answer
1
  • Thanks, I think I'll go back to change sets for now before I advance to Ant "programming" with the migration tool.
    – Marc
    Jan 22, 2013 at 7:04
1

I had a similar issue to this. I used a similar approach to what eyescream suggests, using Migration Tool as this highlighted one test class in particular that was taking 20 minutes to complete when doing deployments. It took a long time to uncover that fact though because running the class on its own in Production would have it complete within 30 seconds. So the issue was specific to deployments.

Support's suggestion was that two of the test classes were blocking one another over access to the same data. It was hard to tell at first if this was the case as the code was dense and I hadn't originally written it. But I can say that switching off access to real data (SeeAllData=false) and having each test class set up its own independent test data fixed the problem.

Hope that helps.

Improve this answer
2
  • I'll know in a few days but it sounds like this is the right track. Strange though that running all tests from the web gui is fast though. If your theory is correct then it is a serious flaw in the force.com IDE!!
    – Marc
    Jan 22, 2013 at 19:08
  • I can't recall the specifics now. But Support said there was one situation where the test are run sequentially (web GUI?), and another where they're run in parallel (deployment). I'm not sure if you can have a Full Sandbox kick off tests the same way as Live does. That might then give a true "practice deployment". I was deploying changes then running tests manually, which apparently ran the tests in a different way to the auto-run in live!
    – Ray
    Jan 23, 2013 at 10:45
1

The Ant Migration Tool seemed to work for me too. See my cross post here and my blog describing how to set up the tool as a Force.com IDE user here.

Improve this answer
0

To Speed up your Eclipse I found an article that helped me alot.

Basically it says to start several Force.com-Projects in your Eclipse with only the files you actually need to work on.

Me for example I work on a Customer Portal and only need some Visualforce Pages and Apex Classes so I only select the actual Pages/Classes i work on and not the whole org and my Eclipse speeded up alot with Saving/Deploying/Refreshing

So from now on I have several project related Force.com-Projects in my Eclipse instead of one per org/Sandbox

Article

http://www.tgerm.com/2010/03/fast-save-refresh-force-ide-eclipse.html

Hope that will help some of you guys.

Regards

pwittke

Improve this answer
2
  • I followed this advice too some time back. Subjectively I would say it maaaay have helped the time it takes to save classes but it certainly doesn't help deployment woes.
    – Marc
    Jan 22, 2013 at 19:03
  • well it helped me alot for saving and refreshing I didn't really tried the deploy function via eclipse yet, but I guessed it might help speeding up as well.
    – pwittke
    Jan 24, 2013 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .