|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Mifos-issues mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-issues
On the GSoC page for Multi-tenant caching (which I'm assuming is connected to this jira) the scope talks about caching at a service level. If this next part of this comment is out of scope that's fine. However, I wanted to be clear on what the original caching problem was perceived to be.
The problem is that any mifosx read api call has to look at a number of other authorisation, code and/or configuration data before it executes its 'main' read. All of this data can be cached as it rarely if ever changes and it is small (even for large MFI's)
The attached file mysqlUncached.txt contains MySql general query log output from a retrieve client api call (yep, I'm sure there would be easier ways to get this same data):
https://localhost:8443/mifosng-provider/api/v1/clients/35?tenantIdentifier=default
Only the final 2 selects are specific to the request, the others are executed to identify the tenant database and by Spring security (I'm assuming) to authenticate the requesting users and to pick up their permissions and associated data.
Although, in general, mifosx read requests use direct SQL, it looks like the Spring security uses hibernate (not sure though).
Although, the security database calls, that get user and office and permission and role information, are the same for each request, other direct SQL calls vary by request... although the security calls would be a very good place to start with caching.
The funny side of this data being uncached at the moment can be seen, for example, if a person uses Amazon EC2 to run mifosx and puts the mysql databases on RDS (an amazon database service where the data is on a different machine so each database call is a network call) - Requests are very slow - because each request requires a number of database calls.
Not so noticeable where the mysql is on the same machine as the tomcat (which mysql query-cache turned on) but still it is important to have caching available for larger databases.