On Sun, Jul 3, 2011 at 10:01 PM, Senaka Fernando <[email protected]> wrote:
> Hi all, > > On Sun, Jul 3, 2011 at 10:33 AM, Afkham Azeez <[email protected]> wrote: > >> >> >> On Sun, Jul 3, 2011 at 8:15 AM, Sumedha Rubasinghe <[email protected]>wrote: >> >>> >>> >>> On Sat, Jul 2, 2011 at 8:26 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> >>>> Senaka >>>> Shankar mentioned $subject. Isn't this sub-optimal? For instance, >>>> caching will not reduce the load on the DB in the current implementation. >>>> Why has it been implemented this way? >>>> >>> For the benefit of others who do not know the full context, >>> >>> Current distributed caching impl is local to a particular node. Whenever >>> the first request for a resource is made, if it's not in the local cache , >>> it gets added. This way there could be several caches of same resource local >>> to different G-Reg instances. When that particular resource is modified >>> through one G-Reg server, a message is being sent to other local caches to >>> invalidate their cached copy. >>> >>> I think was done due to several reasons. >>> - Replicating a large object over distributed cache being an over head >>> - A resource has considerable amount of meta data around it (properties, >>> associations/dependencies, tags, comments, etc). No clear decision on >>> replicating those or not. >>> - Collection & Resource not being serializable >>> >>> Technically, most of these issues can be solved easily. >>> >> > No, this was not done not simply because of technical limitations, there > were some pros in using the current model compared to what we are trying to > achieve by replicating it. Replication itself is expensive and can be more > expensive than a DB-fetch at times. > > >>> I believe we should at least , >>> - think of distribute caching resources bellow a certain size >>> - Cache certain type of media types (eg. synapse-config, wsdls) which >>> have more tendency to be accessed across cache >>> >>> >> +1 >> > > Agreed, but the gain is only the improvement in speed in making the first > call in each node. But, for that to be effective, we need to use synchronous > replication. Because, if you use asynchronous replication, the caches are > that the subsequent nodes will also make DB calls before the replication > completes. But, with synchronous replication, it will take a long time for > the very first fetch in the very first node to complete. > Fully synchronous replication is not recommended for massive scale. It would work only if we have a handful of nodes. > > Also, I'd like to clear the doubts around what we have in place. Frequently > accessed resources are cached at each node, until it gets invalidated. So, > the gain of doing what we have above is only improving the speed of the > first-call in a multi-node G-Reg deployment. Even in Stratos, this would > become useful only if two nodes are serving a single-tenant. If a single > tenant is restricted to a single-node, doing the above will actually reduce > performance and increase memory consumption rather than providing any > improvement. > We do not restrict a tenant to a single node, unless HTTP sessions are involved. The HTTP sessions are sticky. However, for registry access, we have no such concept. > > So, I'd like to discuss the pros and cons of doing the above before > actually going ahead with it, only if there is any benefit of doing it. > > Thanks, > Senaka. > > >> >>> /sumedha >>> >>> >>>> ---- >>>> Sent from my phone >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>** >> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * >> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >> * >> * >> *Lean . Enterprise . Middleware* >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Senaka Fernando* > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>** email: **[email protected]* <[email protected]>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware*
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
