Ping 27/Aug/2020

그간 진행해오던 프로젝트는 성능에 대해서 premature optimization을 고려해서 만들기 보다는 architectural한 면에 비중을 갖고 가능성을 염두에두고 선택을 해오며 만들었다.

그럼에도 꽤 괜찮은 성능이었었고, 이제는 첫번째 버젼의 완성과 문서 작성도 완료한 시점이어서 앞으로 성능을 높일 방안을 고민해보고 실험을 몇개 수행해서 방법 결정해봤다.

(현재 사용하는 방법과 새로이 사용할 방안의 이름은 모두 변경했다.)

1. 기존 성능 측정은:

   1. X event-writer

      • commit을 한번에 하지 않고, 매 이벤트마다 수행해서 느림. (현재는 변경되었음)
      • 약 11,196-microseconds (11-ms)

   2. X journal-writer

      • 2615-microseconds / 2.6-milliseconds

   3. 로직 처리

      • 0.000613-microseconds 정도 처리 속도. (0.6 milliseconds)

   4. 합계 : (milliseconds 단위)

      1. 11 + 2.6 + 0.6 = 14.2

2. 새로운 안은:

   1. event-writer

      1. Y / Z ZZ ZZZ ZZZZZZ.
      2. 3-microseconds –> 0.003 milliseconds.

   2. journal-writer

      1. QQQ
      2. 3-microseconds –> 0.003 milliseconds.

   3. 로직처리 (그대로)

      • 0.000613-microseconds 정도 처리 속도. (0.6 milliseconds)

   4. 합계 : (밀리초 단위)

      1. 0.6 + 2 * 0.003 = 0.6 + 0.006 = 0.606

      2. 14.2 (개선전) / 0.606 (개선후) = 23.432343234323433 정도 개선됨.

         1. Tx/Sec 단위로 환산하면,
         2. 개선전 : 약 70 Tx/Sec.
         3. 개선후 : 약 1650 Tx/Sec.

만족스럽다.

당장 방안을 적용할 것은 없고, 지금도 사실 1개 트랜잭션에 14.2밀리초 정도만 걸리는 것이므로 상대적으로 다른 트랜잭션을 일으키는 것들에 비해면 빠른 것이겠지만.

새로운 방안이 확실한 방법으로 훨씬 더 빠르고 많은 트랜잭션을 수용할 수 있을 수 있고, 조금만 더 작업하면 전환이 가능해서 마음이 편안하다.

Assuming you are using a normal harddisk (i.e. no ssd) you can expect a maximum of 50-100 writes per second. It seems that 15 writes per second is slightly low, but not impossible.

So if Postgres is doing 1500 updates per second they are either written to some buffer/cache or collapsed into a single update. Without knowing more about the actual test it is difficult to say which is the actual reason but if you were to open a transaction, update a single row 1500 times and commit after that than Postgres should be smart enough to only execute a single "real" write to the disk.

- https://stackoverflow.com/a/19136265/3309907

어느 정도 빠른 설정의 RDBMS의 트랜잭션 갯수에 간단히 근접하게 되었다.

그리고 이정도 개선 접근법도 더 빠른 컴파일러를 통한 최적화를 적용하지 않은 상태에서의 결과라 그런 최적화도 적용한다면 폭은 훨씬 더 커질 것이므로 즐겁다.