Also, our DBAs were wondering if there's any recommended values for concurrent reads or caching.
John On Mon Feb 09 2015 at 3:36:26 PM John D. Ament <[email protected]> wrote: > I'm not sure about consistency level, based on a screen shot I'm seeing > QUORUM. > > Replication factor is 3. > > Thanks, > > John > > > On Mon Feb 09 2015 at 3:17:35 PM Todd Nine <[email protected]> wrote: > >> 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 >>>>> >>>>> >>>>
