[MarkLogic Dev General] Number of threads for ML app

Danny Sinang d.sinang at gmail.com
Wed Aug 22 08:56:27 PDT 2012


Hi Mike,

Thanks. We're working on tuning our queries.

Regards,
Danny

On Wed, Aug 22, 2012 at 11:50 AM, Michael Blakeley <mike at blakeley.com>wrote:

> No, I am saying that your workload should guide you to the correct number
> of threads. CPU is not part of this process: the variable is thread count,
> and the metrics are throughput and response times.
>
> But for real-world performance, tuning the thread count will only help if
> there is no clear resource limitation already. In this case you already
> know that CPU is at or close to capacity. So why even look at thread
> counts? Probably response times and throughput are suffering already.
> Certainly you have little or no headroom for growth.
>
> So forget about thread count for now. Focus on profiling and tuning the
> queries, and also thinking about how to add more capacity to meet expected
> growth.
>
> -- Mike
>
> On 22 Aug 2012, at 08:15 , Danny Sinang wrote:
>
> > Hi Mike,
> >
> > So in our case, you saying we should set the number of threads to 64 ?
> >
> > As it is, with threads set to 32, we're seeing CPU usage hit 3,000%
> during peak periods.
> >
> > I'm concerned that setting the number of threads beyond the number of
> cores will cause the server to hit the max 3,200% and stay there because of
> all the other waiting threads. Is this a valid concern ?
> >
> >
> > Regards,
> > Danny
> >
> > On Wed, Aug 22, 2012 at 10:43 AM, Michael Blakeley <mike at blakeley.com>
> wrote:
> > Your workload should guide you to the correct number of threads. I would
> start with 2x cores, because of network latency.
> >
> > You may also want to consider a load balancer and/or reverse-proxy in
> front of MarkLogic. The benefits from operational flexibility should be
> clear. But in the case where you need to handle large numbers of requests
> from distant, high-latency clients, this gives you a cheap place to buffer
> them up. If your clients are few and well-connected, this is less of an
> issue. But the operational flexibility is still useful.
> >
> > -- Mike
> >
> > On 22 Aug 2012, at 04:33 , Danny Sinang wrote:
> >
> > > Hi,
> > >
> > > Our ML server is hosted by a machine with 16 cores with
> hypterthreading so it looks like it has 32 cores total.
> > >
> > > Our main ML app is configured to use 32 threads with a backlog of 256
> . Should we stick to this setting or can we bump up the number of threads
> to handle more requests simultaneously ?
> > >
> > > My colleague thinks we should match the number of ML threads to the
> number of threads accepted by the application servers call ML services. I,
> however, think we can't and shouldn't go beyond 32 because that's the
> actual number of cores our machine has.
> > >
> > > Would appreciate any advice on this matter.
> > >
> > > Regards,
> > > Danny
> > > _______________________________________________
> > > General mailing list
> > > General at developer.marklogic.com
> > > http://developer.marklogic.com/mailman/listinfo/general
> >
> > _______________________________________________
> > General mailing list
> > General at developer.marklogic.com
> > http://developer.marklogic.com/mailman/listinfo/general
> >
> > _______________________________________________
> > General mailing list
> > General at developer.marklogic.com
> > http://developer.marklogic.com/mailman/listinfo/general
>
> _______________________________________________
> General mailing list
> General at developer.marklogic.com
> http://developer.marklogic.com/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://developer.marklogic.com/pipermail/general/attachments/20120822/5f2d6699/attachment.html 


More information about the General mailing list