> Why not do something simpler first and validate that by adding a cache on the database access?

That is also an option but I'm not sure how well that would scale in the long run. I think that we will later need to be able to host multiple instances in an environment like OpenShift where I'm not sure if a relational database is the best choice. Having a relational database might not really be needed either, but was chosen mainly because that was the most familiar and quickest solution at the time to have persistence of some sort. 

I agree. We should not spend time on trying to speed up a relational database when we are very likely not going to use one in the future and it doesn't seem like the right fit for this implementation anyway.

 

On 19 September 2013 08:10, Erik Jan de Wit <edewit@redhat.com> wrote:

On Thu, Sep 19, 2013 at 6:34 AM, Daniel Bevenius <daniel.bevenius@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?

Why not do something simpler first and validate that by adding a cache on the database access?

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev