On 05/13/2013 08:11 PM, Dean Yu wrote:
the hypothesis is that you save on the latency of
round trip calls for loading a single class at a time by sending many
classes up front. The only way this would be true is if the amount of
latency you add by increasing the size of the original payload is less
than the sum of the latency for each round trip call that is saved.
Right, but I hope this is satisfied by most of the payloads being small enough
to fit into one transport packet even considering prefetch.
The proposed patch is a little tricky. My original work on the branch, which seemed to provide some benefit, only dealt with class prefetch: before the master sends a
class file to the slave, it scans the bytecode for class constants referring to to related classes (dependencies, inner classes, etc.), determines which class loader
would be used for those if the code ever asked for them to be loaded, and bundles all this up in the response so that the slave can quickly load a series of classes
without making a new round trip.
We also wanted to deliver entire JAR files, both to try to push as much actual data in a single burst as possible, and to allow the slave to cache JAR files after an
agent restart. The tricky part is that the slave does not know which JAR file it is supposed to consult for a given class name, since the remoting layer models an
arbitrary class loader hierarchy (or graph!) rather than a “flat classpath”. So the master still needs to inform the slave of the code source for each proposed class
load. It can however avoid a round trip per class loader by using the original prefetch heuristic to predict what classes might soon be loaded as well.
The result would be that when first setting up a slave (or after updating Jenkins and/or plugins) you would get some big packets full of JAR content being pushed down the
pipe at full speed, which does not need to wait for the slave to respond and so can be relatively efficient if the transport itself is (and Kohsuke did some fixes here in
1.509). Then when taking a slave online, or starting to use some complex plugins for the first time in a given slave connection, the class loading will require some
round-trip communication to inform the slave of where to load everything from (even though it already has the bytecode on disk); but most of these little packets will
include information about several classes rather than just one, so we reduce the overall latency.
Another option initially considered, but not implemented in the branch, was to avoid all of the round-trip activity by having the master send a serializable proxy which
would effect the same class loading logic as exists on the master. For example, a model for the loader of a Jenkins plugin would refer to the models of the Jenkins core
and any plugin dependencies, with some additional fields for options such as plugin-first class loading. This could be very efficient but for it to work requires that
every ClassLoader in the master which loads anything serialized to the slave also supply a proxy, meaning more code in Jenkins core to troubleshoot and maintain.
The above is my interpretation of what the branch currently does, so Kohsuke
please correct me if I have got it wrong!
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
