Hi, In addition to my previous mail, instead of directly writing to a DB, periodically we are publishing the events to BAM for analysing and processing so it will run in a different thread.
On Fri, Nov 21, 2014 at 11:00 PM, Pulasthi Supun <pulas...@wso2.com> wrote: > Hi All, > > The method that Udara mentioned would indeed improve performance. but when > we scale it up to couple hundred or more applications again this will > become a overhead. So how about introducing a map ( as an cache ) that > keeps all the invocation data until the map is written to the database > periodically.This way all the counter data in the map can be added to the > database in a single batch operation which would scale even if there is a > large number of applications. > > Best Regards, > Pulasthi > > > I have implemented a Javascript to store the events and post periodically. > When an user clicks on an App, javascript triggers and store the relevant > data(AppId, UserId) as events(in client side) and periodically (user can > define the time gap) JS posts the event[] to a jaggery file. Then from the > jaggery it sends the data to server. > > On Fri, Nov 14, 2014 at 11:49 PM, Udara Liyanage <ud...@wso2.com> wrote: > >> Hi, >> >> So every time an app is accessed the incremented counter needs to be >> written to db. Isn't it an considerable overhead if apps are accessed >> frequently. How about keeping the counter in a cache or write to db say for >> every 10 times(a meaningful value) an app is accessed? >> >> Touched, not typed. Erroneous words are a feature, not a typo. >> On Nov 14, 2014 5:20 PM, "Lahiru Cooray" <lahi...@wso2.com> wrote: >> >>> Hi all, >>> >>> I'm trying to add a new feature to AppManager to unable user to *sort* >>> the subscribed Apps by accessed frequency. >>> >>> In the back end there will be a counter used to store the no of hits per >>> App against each subscriber. When a subscriber access an App (via >>> AppManager gateway end point URL) the counter will be increased. >>> >>> [image: Inline image 3] >>> >>> >>> And in the front end there will be two options that user the can select. >>> (recently added Apps/ most frequently accessed Apps) >>> >>> *Proposed table structure:* >>> >>> *CREATE TABLE APPMGR_APP_HIT_TOTAL* >>> *(* >>> *API_ID INT(10) NOT NULL,* >>> *USER_ID VARCHAR(50) NOT NULL,* >>> *HIT_COUNT BIGINT,* >>> *PRIMARY KEY (API_ID,USER_ID)* >>> *)* >>> >>> Highly Appreciate your feedbacks. >>> >>> -- >>> *Lahiru Cooray* >>> Software Engineer >>> WSO2, Inc.;http://wso2.com/ >>> lean.enterprise.middleware >>> >>> Mobile: +94 715 654154 >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
