Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt

With the Billing Service refactoring, customers with great workloads can enjoy much faster and more reliable billing services than ever before. A brief analysis of the refactoring reasons as well as the results after the refactoring follows.

Refactoring Reasons


The main goal of this Billing Service refactoring project was to address the following performance issues of the Billing Process to provide some “breathing room” for customers with great workloads.

  • Database connection timeouts that occur with every increased workload.

  • Inefficient use of computing resources (application and database servers).

  • Inefficient design of internal activities Billing Process.

  • Lack of logging transparency.

Results After Refactoring


Having completed the first version of the Billing Service refactoring project, the following benefits have been observed and measured based on statistics gathered from the interworks.cloud production billing executions so far.

Performance benefits

  • Reduced Subscription Renew Activity time to more than half.

    • Development statistics suggested ~70% faster activities.

    • interworks.cloud production dropped from 36' to 15' (~58% faster) while the number of subscriptions increased.

  • Reduced Subscription Update Activity time to more than half.

    • Development statistics suggested ~65% faster activities.

    • Production statistics are expected in the following days.

  • Reduced Billing Process execution (in total) by almost half.

    • The billing process is defined as all these steps that update subscriptions, generate charges, invoices, and payments.

      • Important note: Benefits on the total Billing Process execution are highly dependent on the client’s integrations, external systems performance and the number of email notifications sent on every billing run.

Development benefits

  • Billing Service execution is more transparent and accessible to developers .The since the code is more structured, well-formatted, and documented.

  • Obsolete or confusing legacy features have been removed to reduce code clutter.

  • Billing logging has been enriched to facilitate debugging and support in production environments.

  • Execution times are being logged for all Billing Activities in order to monitor individual and overall performanceit facilitates better debugging, is free from legacy features and leftovers, and logs are more verbose.

What is Coming


Notifications Process

Move all Notifications to a new complementary and parallel process, just like the Provisioning Process, in order to permanently reduce the total execution time of the Billing Service.

Invoicing parallelization

Refactor the Invoicing Activity to increase its throughput, leading to a faster invoicing process.

Renew and Status Updates parallelization

It might be possible to execute Execute the Renew and Status Update Activities at the same time, in parallel, decreasing even further the total execution time of the Billing Service.

Payments parallelization

An investigation should be done on how Payments could be executed Execute the Payments in parallel and not linearly as it is now. This is will provide a major performance boost to , decreasing even further the total execution time of the Billing Service.

Billing Process per organization

The Billing Process must be scheduled per Organization independently! Organizations should Organizations will be able to schedule their own Billing Process according to their timezone and business preferences. Preferably, the scheduling (and re-scheduling) should be done in real-time from within our administration panel.

Table of Contents


Table of Contents
minLevel1
maxLevel7
excludeTable of Contents