cancel
Showing results for 
Search instead for 
Did you mean: 
Data Engineering
Join discussions on data engineering best practices, architectures, and optimization strategies within the Databricks Community. Exchange insights and solutions with fellow data engineers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Slow first time run, jar based jobs

User16783852686
Databricks Employee
Databricks Employee

When running a jar-based job, I've noticed that the 1st run always takes the extra time to complete the job and consecutive runs take less time to finish the job. This behavior is reproducible on an interactive cluster. What's causing this? Is this expected?

1 ACCEPTED SOLUTION

Accepted Solutions

DD_Sharma
New Contributor III

Hi @Brad Barker​ , In the 1st run of the jar-based job when the 1st job/task starts executor fetches the jar/library from driver to executor. Which will take some time but in the 2nd run or any consecutive runs, there will be no fetch operation so all consecutive runs will take less time to finish the job compared to the 1st run. This is expected behavior. 

Overall there might be other reasons for job slowness like slow network, large library, more input data. But in an ideal scenario, the 1st run (after the cluster is started) ships the libraries to executors with the first task, and we may see a couple of seconds/minutes of slowness (based on the number & size of the libraries).

View solution in original post

4 REPLIES 4

User16763506586
Contributor

Hi @Brad Barker​ 

Does the jar job has dependencies ?. Can you elaborate what does this jar job does ?.

-werners-
Esteemed Contributor III

maybe the loading of the jar takes some time? When you rerun it, it might already be present.

Just thinking out loud here.

DD_Sharma
New Contributor III

Hi @Brad Barker​ , In the 1st run of the jar-based job when the 1st job/task starts executor fetches the jar/library from driver to executor. Which will take some time but in the 2nd run or any consecutive runs, there will be no fetch operation so all consecutive runs will take less time to finish the job compared to the 1st run. This is expected behavior. 

Overall there might be other reasons for job slowness like slow network, large library, more input data. But in an ideal scenario, the 1st run (after the cluster is started) ships the libraries to executors with the first task, and we may see a couple of seconds/minutes of slowness (based on the number & size of the libraries).

User16783852686
Databricks Employee
Databricks Employee

@Sandeep Katta​ , this is a fat jar that does read-transform-write. @DD Sharma​  response matches

@Werner Stinckens​  & I intuition that there was efficiency on the second job due to jar already being loaded. I would not have noticed this had job run time not been small. There is follow on opportunity here on how to make library installs faster, but this answers my question.

Connect with Databricks Users in Your Area

Join a Regional User Group to connect with local Databricks users. Events will be happening in your city, and you won’t want to miss the chance to attend and share knowledge.

If there isn’t a group near you, start one and help create a community that brings people together.

Request a New Group