Work: August

[peeyush-tm]

V2

• [x] Offline Mode
  • [x] iOS
  • [x] Android
• [x] Tenant Organizations
• [x] DLF Use Case

V3: Discussion: 16 August 2017 -[3:00 - 5:00 PM]

🔴 - high priority 🔵 - medium priority ⚪️ - low priority ⚫️ - look for some 3rd party 🚀 - Optmise

• Agenda - V3 Architecture
• Agenda - How to migrate V2 -> V3 (V3 must have full-fledged VMS product)
• [x] 🔴 ⚠️ - Database Problem - Idle in Transaction
  1. 🔴 - JWT Authorization between the services owned by Veris
  2. 🔴 - Authorization needs to be managed by the service itself
     • ⚫️ 🔍 - Explore the Gateway for this feature
  3. 🔴 - Client API updates (dependent on point 2, 3)
  4. 🔵 - Runtime Metadata: should hold the data for the widgets and widget rules
  5. 🔵 - Widget Metadata: should hold the data for the processes and process rules
  6. ⚫️ 🔍 - Distributed tracing & monitoring for all the services
  7. ⚪️ 🚀 - client optimization - resolve data locally
  8. ⚪️ 🚀 - client optimization - offline storage for data & rules on client side
  9. ⚪️ - feature in the client - go back and front
  10. 🔵 🚀 - client optimization - local/ in-place variables
      • $.date
      • $.time 🔍 based on the the Client Capabilities - $.device
  11. 🔵 🚀 - client optimization - [dependent on the offline mode] - individual REDUX store
  12. 🔵 🚀 - client & server optimization - search for a better RULES engine
  13. ⚪️ 🚀 - server optimization - Mistral Authentication per organization
  14. 🔵 - Change the bounded static/ default process execution. right now the processes are hardbound to the Ekka organization
  15. 🔵 🚀 - server optimization - onboarding workflow is a long-running process
      • signup
      • add_member
      • assign_app
• Event Driven Architecture - Read about
  • CQRS
  • Observer Pattern
  • Actor Pattern 🔍 more study is required on the event-driven architecture part
  • message queue
  • client pub-sub

[veris-ankitpopli]

Database Problem :+1:

Problem 1

• We were tuning Postgres using pgtune, but forgot there might be ulimit set. ulimit was 64kb. The machine was under utilized.

Problem 2

• after the ulimit problem was solved, postgres machine was still under utilized, which led to fewer connections to the db. The no of threads on the uWSGI was less. Increased them Now the server is easily handling 100 req/s in ~7 secs with a concurrency of 10. The db utilization is ~60% at this scale. All the databases are on the same machine.