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
New Contributor II
New Contributor II

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

5 REPLIES 5

Kaniz
Community Manager
Community Manager

Hi @ Brad! My name is Kaniz, and I'm the technical moderator here. Great to meet you, and thanks for your question! Let's see if your peers in the community have an answer to your question first. Or else I will follow up with my team and get back to you soon. Thanks.

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
New Contributor II
New Contributor II

@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.

Join 100K+ Data Experts: Register Now & Grow with Us!

Excited to expand your horizons with us? Click here to Register and begin your journey to success!

Already a member? Login and join your local regional user group! If there isn’t one near you, fill out this form and we’ll create one for you to join!