[almighty] Cache solution for Almighty core

[Shoubhik Bose]

Interesting conversation to start Alexey.

I think at this moment, to ensure we don't fall into cache invalidation
issues - we could come up with strategies to cache information*  per
request*. ( in programming language native datastructures )

Example, when a request asks for 100 workitems, we should fetch a distinct
workitem type once only for this specific HTTP request.

Another optimization we could explore is in-memory caching on the database
side, if there's something not already done by the database.

/Shoubhik




On Tue, Nov 8, 2016 at 6:54 PM, Todd Mancini <tmancini at redhat.com> wrote:

> +1
>
> Sent from my phone, so anticipate hilarious autocorrects
> ------------------------------
> From: Aslak Knutsen <aslak at redhat.com>
> Sent: ‎11/‎8/‎2016 8:10 AM
> To: Todd Mancini <tmancini at redhat.com>
> Cc: Alexey Kazakov <alkazako at redhat.com>; ALMighty-public
> <almighty-public at redhat.com>
> Subject: Re: [almighty] Cache solution for Almighty core
>
> That's the beauty of immutable objects.. :)
>
> -aslak-
>
> On Tue, Nov 8, 2016 at 1:36 PM, Todd Mancini <tmancini at redhat.com> wrote:
>
>> There are only two hard things in Computer Science: cache invalidation
>> and naming things.
>>
>> -- Phil Karlton
>>
>> Many of the worst bugs I ever struggled to fix had to do with caching.
>> It is so very hard to get right in large, distributed, multi-tenant
>> systems. Proceed with caution; don't optimize early. (and have flags to
>> be able to turn it off 😉)
>>
>> Sent from my phone, so anticipate hilarious autocorrectsFrom: Alexey
>> Kazakov
>> Sent: ‎11/‎7/‎2016 7:15 PM
>> To: ALMighty-public
>> Subject: [almighty] Cache solution for Almighty core
>> Hi all,
>>
>> At some point we will probably need some universal cache solution which
>> we could use different types of objects in almighty core. I'm going to
>> spend some time on researching in this area but there are a few
>> questions I would like to discuss with the team.
>> There are some solutions like Memcached or Redis which could be used but
>> they require to have a server with the cache service (on a dedicated
>> container?) where we could keep WIT, WI and any other artefacts which we
>> want to access some value by a key. Some solutions like Memcached are
>> pure in-memory some like Redis can be persistent but my biggest concern
>> for now is what approaches are best for microservices world.
>> In monolith world we could have a shared cache server. One DB - one
>> cache service. But I'm not sure if it's worth having an internal
>> dedicated cache server for each relevant microserver.
>> Currently we are kinda building a monolith and a cache server could
>> work. But how our cache system should evolve when we start
>> splitting/introducing microservices in almighty-core? Is there any
>> concept of shared cache between microservices or it's always hidden by
>> the microservice implementation and the microservice just takes care of
>> synchronization of its internal model/DB and uses some internal fully
>> independent cache if needed.
>>
>> Any thoughts?
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161108/f9a1b227/attachment.htm>