Usergrid query.  In that case you definitely shouldn't have slowness.
That query is a direct range scan, then multiget of entities.   What
consistency level and replication factor are you running?


On Mon Feb 09 2015 at 10:58:58 AM John D. Ament <[email protected]>
wrote:

> Sorry I wasn't sure if you meant the underlying cassandra query or the
> usergrid query.
>
> The usergrid query is simply
>
> /{org}/{app}/{collection}
>
> With param: ql=order%20by%20created%20asc
>
> John
>
>
> On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <[email protected]> wrote:
>
>> Hey John,
>>   As Dave said.  I'm assuming you're running version 1.0 right?  Version
>> 1.0 has a much slower query engine than UG 2.0.  In UG 1.0, we don't have
>> term scoring, cardinality stats etc.  Therefore, the more complex the query
>> you input, the slower the results, since it requires iteration of the
>> candidate term sets to perform the union/intersection with the terms
>> provided.  We've fixed this in 2.0 by just using ES, which leverages the
>> speed and optimizations that have been built into Lucene.
>>
>>
>>
>>
>> On Mon Feb 09 2015 at 7:03:17 AM Dave <[email protected]> wrote:
>>
>>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <[email protected]>
>>> wrote:
>>>
>>>> So wanted to give more info to see if there's any recommendation
>>>> (otherwise I'll start bugging the cassandra ML)
>>>>
>>>> Our use case is something like two apps involved.  One app writes to a
>>>> custom collection in usergrid (actually both do this), and we've let it
>>>> grow to 12k entities in that collection.
>>>>
>>>> Now, second app comes in and starts reading those messages to see what
>>>> to do next.  Queries for the collection are using 60 as a limit (a
>>>> performance limit on the eventual receiver).  We read the message, do some
>>>> work, and then delete that entity from the collection.
>>>>
>>>> This to me isn't a lot of data, others may disagree though.  Anyways,
>>>> we have a 3 node cassandra cluster where we're seeing Usergrid respond
>>>> pretty fast, but ends up waiting on Cassandra for most of the time (3+
>>>> seconds per query).
>>>>
>>>> This is what each server is running:
>>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>>> -XX:StringTableSize=1000003
>>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>>>> -XX:SurvivorRatio=8
>>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>>> -XX:+UseCMSInitiatingOccupancyOnly
>>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>>
>>>> Any thoughts are very much appreciated.
>>>>
>>>
>>>
>>> It might be helpful if you can share the actual queries you are making.
>>>
>>> - Dave
>>>
>>>
>>

Reply via email to