[aerogear-dev] [simplepush] Performance

JR Conlin jrconlin at gmail.com
Thu Sep 19 12:08:27 EDT 2013


On 2013/9/19 5:18 AM, Lucas Holmquist wrote:
>
> On Sep 19, 2013, at 12:34 AM, Daniel Bevenius
> <daniel.bevenius at gmail.com <mailto:daniel.bevenius at gmail.com>> wrote:
>
>> >I wonder what kind of numbers would we get by ditching JPA
>> completely and using a non-relational DB like Redis
>> Yeah, I think we will most likely need to if we want to come close to
>> the other implementations performance wise. Others use Memcache and
>> I've seen MongoDB in use as well. 
>>
>> Perhaps I should just add performance tests for the rest of the
>> SimplePush operations so that we have them covered and then look into
>> using a non-relational DB. Once that is done we can revisit this
>> performance task.
>> What do people thing about that?
>
> +1,  relational DB's are dinosaours
Hardly. It's just a question of what the right tool for a given job is.
(I'll note that Google is spending quite a bit of time and effort
improving Maria because they use a LOT of relational DBs for very large
data.

In this case, however, it's pretty easy to reduce things to simple
key/value. I picked Memcache, partly because of the fact that it does
record auto-expiration, which means that I don't have to do garbage
collection on uncollected records. If you switched to an alternate
schema (such as keeping a single record per UAID that contained all the
CHID data as well as stuff like the proprietary info or other crap), you
could even use simple flat files and skip the DB requirement altogether.

We were kicking the idea around of only storing undeliverable data into
the DB, and instead letting each websock connector deal with managing
it's own data. For our implementation, I've already preferenced delivery
over storage for connected clients and seen a fair bit of improvement on
delivery. (Remember, SimplePush is not a 100% guaranteed delivery
system, so please avoid using it for nuclear reactor management or
pacemakers.)

We'll probably hold off on doing further memory refinement until we get
some actual use data, but I like having options available.
>
>>
>>
>>
>>
>> On 19 September 2013 06:03, Bruno Oliveira <bruno at abstractj.org
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>     Hmmm tempting idea :)
>>
>>     > On Sep 19, 2013, at 12:23 AM, Douglas Campos <qmx at qmx.me
>>     <mailto:qmx at qmx.me>> wrote:
>>     >
>>     > That's a nice report!
>>     >
>>     > I wonder what kind of numbers would we get by ditching JPA
>>     completely
>>     > and using a non-relational DB like Redis...
>>     >
>>     > --
>>     > qmx
>>     > _______________________________________________
>>     > aerogear-dev mailing list
>>     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>     _______________________________________________
>>     aerogear-dev mailing list
>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130919/b1ae892c/attachment.html 


More information about the aerogear-dev mailing list