[aerogear-dev] [simplepush] Performance

[Daniel Bevenius]

Sorry for my late reply to this thread, I've was side tracked with a few
other issues but I'm back on track now.
I don't have much to report at the moment except to share the branch we are
working on for the different database options, and how to run/configure
them if anyone would like to try them out.
We are currently looking into what store will be the best fit for our
SimplePush Server and are trying three types of databases, MySql (JPA),
Redis, and CouchDB in this
branch<https://github.com/danbev/aerogear-simplepush-server/tree/no-sql-databases>
.

Using the above branch one can try the different database by making changes
to the AS7/WildFly configuration (standalone.xml in most cases).
For example, to use a JPA database one would use:

<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
    <server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
        <datastore>
            <jpa
datasource-jndi-name="java:jboss/datasources/SimplePushDS"
persistence-unit="SimplePushPU"/>
        </datastore>
    </server></subsystem>

To use Redis:

<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
    <server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
        <datastore>
          <redis host="localhost" port="6379"/>
        </datastore>
    </server></subsystem>

To use CouchDB:

<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
    <server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
        <datastore>
          <couchdb url="http://127.0.0.1:5984" database-name="simplepush"/>
        </datastore>
    </server></subsystem>

I'm writing a gist describing how data is stored with Redis and CouchDB and
will post back here when it's done to get feedback.



On 26 September 2013 17:15, JR Conlin <jrconlin at gmail.com> wrote:

> I'm not familiar with Hibernate, but I'm a HUGE advocate of abstraction
> at functional levels. (e.g. classic MVC designs). Generally, what's good
> today may not be good tomorrow, and having unencumbered interfaces lets
> you swap in what makes the most amount of sense with the least impact to
> your code.
>
> The nice thing about Key/value is that you've got the most amount of
> flexibility around what you actually use to store data; Postgres, MySQL,
> Redis, Memcache, heck an in memory hash can all do it.
>
> As for which data store you actually use, that's kinda driven by what
> you expect your load to be. If you're only talking a few thousand
> clients with a dozen channels, each getting an update when a flights
> status changes, then you're not talking about putting a huge strain on
> your storage or it's Read/Write capacity. If you've got a few hundred
> million clients and some partners who've decided to use your system as
> part of their FPS game updates, then you've got lots more problems.
>
> (And now you start to understand why I wake up in a cold sweat screaming
> about how you don't use SimplePush for real time stock quotes.)
>
> On 2013/9/26 2:50 AM, Karel Piwko wrote:
> > No reason to push for Mongo then, my experience with NoSQL databases (not
> > counting XML databases) is pretty limited and I'm glad you gave me some
> insight.
> >
> > What about abstraction layer idea based on Hibernate OGM? Does it make
> any
> > sense to you? Currently is does support only Infinispan, EHCache and
> MongoDB
> > [1], so I guess it's out of question as well.
> >
> > Karel
> >
> >
> > [1]
> >
> http://docs.jboss.org/hibernate/ogm/4.0/reference/en-US/html/ogm-datastore-providers.html
> >
> > On Wed, 25 Sep 2013 17:59:10 -0300
> > Douglas Campos <qmx at qmx.me> wrote:
> >
> >> On Wed, Sep 25, 2013 at 09:53:19AM -0700, JR Conlin wrote:
> >>> The concern with using Mongo is that it's very lossy and fairly
> >>> unreliable as a data store for a number of reasons. (It's fine for
> >>> simple, low demand systems, but has complications once you really start
> >>> to hammer on it.)
> >>>
> >>> http://blog.schmichael.com/2011/11/05/failing-with-mongodb/
> >>> http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
> >>> etc.
> >>>
> >>> I'd suggest sticking with other DBs unless you're ok with loss or don't
> >>> plan on heavily exercising it.
> >> Seconded, have had severe data loss with mongo under high load at my
> >> previous job
> >>
> > _______________________________________________
> > aerogear-dev mailing list
> > 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/20131014/b771ce2f/attachment.html