krivachy

1. I see that most of your connections and queries are running on the master(writer) database instance itself without much load on the reader instance. You can consider dividing your workload such that read-only queries/workloads are directed to the reader instance, and only write queries are handled by your writer instance. This will help alleviate the large undo logs(RollbackSegmentHistoryListLength) due to long running queries and in itself this should mitigate a lot of the performance issues. 

	One way to achieve splitting of Reads and Writes is by making use of a third party software Proxy solution which can split reads and writes to the appropriate endpoints. Below are a few example software solutions which you can consider:
	[+] ProxySQL - https://proxysql.com/ 
	[+] Heimdall Data - https://www.heimdalldata.com/ 
    
    
2. If and where possible, try to split large transactions into multiple smaller transactions. This will again reduce the growth of the undo log which seems to be the main cause of t

krivachy

describe('create issue mutation', () => {
  it('should create an issue', async () => {
    // Given: workspace + customer + issue type
    const testWorkspace = await testData.newWorkspace();
    const ctx = await testData.testAggregateContext({ testWorkspace });
    const issueType = await issueAggregate.createIssueType(ctx, {
      publicName: 'Run of the mill issues',
    });
    const customer = await customerAggregate.createCustomer(ctx, factories.newCustomer());

krivachy

package example


import scala.concurrent.{ExecutionContext, Future}
import scalaz._, Scalaz._

object Demo extends App {
  implicit val ec = ExecutionContext.global

  val FutureApplicative = Applicative[Future]