Hi Sean and Aseem,

thanks both. A simple thing which sped things up greatly was simply to load
our sql (for one record effectively) directly and then convert to a
dataframe, rather than using Spark to load it. Sounds stupid, but this took
us from > 5 seconds to ~1 second on a very small instance.

Aseem: can you explain your solution a bit more? I'm not sure I understand
it. At the moment we load our models from S3
(RandomForestClassificationModel.load(..) ) and then store that in an
object property so that it persists across requests - this is in Scala. Is
this essentially what you mean?

On 12 October 2016 at 10:52, Aseem Bansal <asmbans...@gmail.com> wrote:

> Hi
> Faced a similar issue. Our solution was to load the model, cache it after
> converting it to a model from mllib and then use that instead of ml model.
> On Tue, Oct 11, 2016 at 10:22 PM, Sean Owen <so...@cloudera.com> wrote:
>> I don't believe it will ever scale to spin up a whole distributed job to
>> serve one request. You can look possibly at the bits in mllib-local. You
>> might do well to export as something like PMML either with Spark's export
>> or JPMML and then load it into a web container and score it, without Spark
>> (possibly also with JPMML, OpenScoring)
>> On Tue, Oct 11, 2016, 17:53 Nicolas Long <nicolasl...@gmail.com> wrote:
>>> Hi all,
>>> so I have a model which has been stored in S3. And I have a Scala webapp
>>> which for certain requests loads the model and transforms submitted data
>>> against it.
>>> I'm not sure how to run this quickly on a single instance though. At the
>>> moment Spark is being bundled up with the web app in an uberjar (sbt
>>> assembly).
>>> But the process is quite slow. I'm aiming for responses < 1 sec so that
>>> the webapp can respond quickly to requests. When I look the Spark UI I see:
>>> Summary Metrics for 1 Completed Tasks
>>> Metric    Min    25th percentile    Median    75th percentile    Max
>>> Duration    94 ms    94 ms    94 ms    94 ms    94 ms
>>> Scheduler Delay    0 ms    0 ms    0 ms    0 ms    0 ms
>>> Task Deserialization Time    3 s    3 s    3 s    3 s    3 s
>>> GC Time    2 s    2 s    2 s    2 s    2 s
>>> Result Serialization Time    0 ms    0 ms    0 ms    0 ms    0 ms
>>> Getting Result Time    0 ms    0 ms    0 ms    0 ms    0 ms
>>> Peak Execution Memory    0.0 B    0.0 B    0.0 B    0.0 B    0.0 B
>>> I don't really understand why deserialization and GC should take so long
>>> when the models are already loaded. Is this evidence I am doing something
>>> wrong? And where can I get a better understanding on how Spark works under
>>> the hood here, and how best to do a standalone/bundled jar deployment?
>>> Thanks!
>>> Nic

Reply via email to