JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   On Github   Forums 
February 25, 2020, 07:16:41 AM *
Welcome,
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: Parallel Tasks on Large no of computations  (Read 2003 times)

karthik_426

  • JPPF Padawan
  • *
  • Posts: 3
Parallel Tasks on Large no of computations
« on: October 03, 2013, 12:32:43 PM »

Hi,

We have a use-case to go for parallel distributed computing to gain performance improvement. For which we are looking at JPPF.

Our use-case is to do large no of computations in parallel - for which the code to process is spread across multiple files.

We understand the concept of a JPPFTask and implementing the run() method of the same. Our understanding is that all serialization that happens for the execution during the communication between the client and the server and nodes happens a fresh for every new task and hence if the task is spread on large no of files then then the communication itself eats up good time.

Is this a correct understanding of the same ?


Appreciate any response on this.

Thanks,
Karthik
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2258
    • JPPF Web site
Re: Parallel Tasks on Large no of computations
« Reply #1 on: October 04, 2013, 07:43:20 AM »

Hello,

Yes, your understanding is correct, serialization and deserialization do occur for every task. Thus, when the tasks have a large amount of data, there can be a significant overhead due to serialization.
However, JPPF offers several ways to mitigate this overhead. For instance, if the tasks share the same input data, it is possible to send the common data separately within a data provider. It is also possible to download the data directly from the client, during the task execution, so you can arrange to only do it once for each node. If you could provide more details on your tasks and what they do, we'll be happy to assist in minimizing the cost of input data transfer.

I hope this helps.

Sincerely,
-Laurent
Logged

karthik_426

  • JPPF Padawan
  • *
  • Posts: 3
Re: Parallel Tasks on Large no of computations
« Reply #2 on: October 04, 2013, 03:48:47 PM »

Hi Laurent,

Thanks for the reply. So our issue is not the data being sent to the task for the execution but the no of files on which the task is spread out. Here is our use-case: A job consists of multiple tasks where in each task needs to typically need run over 15-20 different files of code to execute. Many clients can create jobs. We are considering our use-case to be bottle-necked in two aspects wrt JPPF:
1) Communication overhead at the start of task execution
2) Chances of OOM at Node as multiple copies of classes will be kept at the node specific to the client requesting for task. (This is what I understand from the documentation of class loaders and how they work)



Thanks,
Karthik
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2258
    • JPPF Web site
Re: Parallel Tasks on Large no of computations
« Reply #3 on: October 05, 2013, 06:13:29 AM »

Hi Karthik,

Indeed, there is an overhead due to class loading, at least the first time a task is executed. Generally, this overhead is pretty small, unless your tasks require thousands of classes to execute.

To mitigate this overhead, JPPF has a number of built-in optimizations, among which the most significant are:
  • batching of class loading requests in the node: when multiple threads (i.e. tasks) run in parallel in a node, the node will group the emitted class loading requests from all the thread over short periods of time (sub-millisecond), thus reducing the network overhead and removing duplicate requests in the process
  • class loader cache in the node: the node maintains a fixed-size cache of class loaders, where each class loader is dedicated to a specific client identified by its uuid. When the cache size limit is reached, the least recently used class loader is evicted from the cache and its classes are unloaded. This also addresses the OOME (PermGen) potential issue: since the cache size is configurable, you have the possibility to specify a good compromise between class loading overhead and permgen footprint
  • cache of classes bytecode in the server: the results (bytecode) of all class loading requests from the node are stored in a soft reference cache in the server. This reduces a lot of the round trips between server and clients, as the server will always lookup into this cache first, before forwarding a class loading request to the appropriate client. Additionally, using soft references for this cache guarantees that it will not trigger a heap space exhaustion in the server.

Despite these optimizations, there are scenarios where the class loading overhead remains significant. This generally happens when the number of classes to load is large, or when the network communication is slow. Several options are available to mitigate these: it is always possible to add your classes and libraries to the nodes' or server's classpath, which eliminates a lot of class loading round trips, at the cost of less flexibility and additional deployment effort whenever your code changes. It is also possible to transport your jar files along with the job and dynamically reset the class loader classpath in the node before the tasks are executed. This also has an overhead, but it it much smaller because all the classes are then sent to the node in a single request. Please take a look at our extending class loading sample, which shows a sophisticated way of doing this - you can also make it much simpler if you don't need all the replicated library repository management.

I hope this clarifies.

-Laurent
Logged

karthik_426

  • JPPF Padawan
  • *
  • Posts: 3
Re: Parallel Tasks on Large no of computations
« Reply #4 on: October 05, 2013, 11:03:45 AM »

Hi Laurent,

Thanks for the detailed explanation. One last question I have is wrt to having the classes and libraries pre-loaded on nodes and servers. So according to the documentation classes loaded are specific to clients. So how would pre-loading work keeping the classes loaded specific for clients ? If you can point me to any such example that would be great.

Appreciate your help on this.


Thanks,
Karthik
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2258
    • JPPF Web site
Re: Parallel Tasks on Large no of computations
« Reply #5 on: October 08, 2013, 08:00:46 AM »

Hi Khartik,

I 'm assuming that by "pre-loading" you mean having the classes in the node's classpath. In this case, these classes are not specifc to a client anymore, because they are loaded by the node's application class loader instead of a JPPF class loader. So this does incur a loss of flexibility in exchange for faster class loading.

-Laurent
Logged
Pages: [1]   Go Up
 
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at SourceForge.net. Fast, secure and Free Open Source software downloads