Files
Gnuboard7/modules/_bundled/sirsoft-ecommerce/src/Benchmark/OrderCreationBenchmark.php
T
HeuJung 5f4a733b3b feat(core,board,ecommerce,page): 성능 계측 인프라 4축 확장 및 계측 대상 선언 지점 신설
계측 축이 "목록 SELECT" 하나였고 프로파일 12종이 커맨드 파일에 하드코딩돼
있어 확장이 자기 대상을 추가할 수 없었다. 확장이 설치·제거되는 설치본마다
"실제로 존재하는 대상"이 달라지므로, 대상을 소유자가 선언하고 코어가 수집하도록
뒤집었다.

- 선언 지점 두 곳, 스키마 하나: 코어 config/benchmark.php,
 확장 getBenchmarkProfiles (모듈/플러그인). 수집은 method_exists 기반이라
 인터페이스를 직접 구현한 서드파티 확장이 깨지지 않는다.
- 축 4종(목록/화면/쓰기/배치)을 실행기로 분리하고 컨테이너 태그로 주입 —
 축이 늘 때 커맨드를 고치지 않는다.
- 화면 축은 HTTP 커널로 내부 요청을 처리한다. 라우트만 dispatch 하면 전역
 미들웨어를 건너뛰어 화면과 다른 것을 재게 된다. 인증은 프로파일이 선언한
 권한만 가진 임시 계정이 기본이며 --as 로 기존 계정을 지목할 수 있다.
- 화면/쓰기 축은 계측 계정 생성부터 처리까지 롤백되는 트랜잭션 안에서 실행해
 운영 DB 에도 잔여 데이터를 남기지 않는다. 배치 축은 내부 커밋·락 보유 때문에
 감싸지 않고 --allow-write 로만 통제한다.
- 잘못된 선언은 조용히 버리지 않고 사유를 경고로 남긴다. 버려진 선언이 곧
 계측 사각이 되기 때문이다. 전부 건너뛴 실행은 종료 코드 1 로 끝난다.
- 리포트는 환경 정보를 함께 적어 저장소 밖(storage/app/benchmarks)에 남긴다.
 측정값이 실행 머신에 종속되므로 저장소에 축적하면 비교 불가능한 수치가 섞인다.

작업 중 발견해 함께 고친 것:

- 이관 프로파일 3종의 soft_delete 선언이 실제 스키마와 어긋나 있었다
 (users/product_inquiries/pages 에 deleted_at 없음).
- 주문 목록이 상태 미지정 시 임시 주문 상태를 NOT IN 으로 제외하는데 선언에
 빠져 있었다. filters 가 등가 비교만 지원한 것이 근본 원인이라 연산자 형태를
 받도록 넓히고, 미허용 연산자는 측정 전에 거부한다.
- 댓글 프로파일은 지배적 술어가 상관 서브쿼리라 선언형으로 재현할 수 없어
 제거했다. 맨 테이블 스캔은 어느 화면도 내지 않는 수치가 된다.

g7:bench:pagination → g7:bench 로 개명(4축을 재므로). 이전 이름은 별칭으로 남겼다.

테스트 61건 통과, 라이브 18종 전건 측정.
2026-08-02 14:44:33 +09:00

117 lines
5.1 KiB
PHP

<?php
namespace Modules\Sirsoft\Ecommerce\Benchmark;
use App\Models\User;
use Illuminate\Support\Facades\Auth;
use Modules\Sirsoft\Ecommerce\Models\Order;
use Modules\Sirsoft\Ecommerce\Models\Product;
use Modules\Sirsoft\Ecommerce\Models\ProductOption;
use Modules\Sirsoft\Ecommerce\Models\TempOrder;
use Modules\Sirsoft\Ecommerce\Services\OrderProcessingService;
use Modules\Sirsoft\Ecommerce\Services\TempOrderService;
/**
* 주문 생성 계측 대상 — `g7:bench` write 축이 실행하는 저장 경로
*
* 주문 생성은 재고 차감·쿠폰 소진·마일리지 적립·알림 발행이 한 트랜잭션에 얽힌 저장
* 경로이므로, 계측 커맨드가 쿼리를 스스로 조립해 재는 방식으로는 실제 비용을 알 수 없습니다.
* 그래서 이 클래스가 실제 서비스 경로(`OrderProcessingService::createFromTempOrder`)를
* 호출하고, 커맨드는 시간·쿼리 건수만 잽니다.
*
* 임시 주문을 팩토리로 직접 조립하지 않고 실제 서비스(`TempOrderService`)로 만드는 이유는,
* `createFromTempOrder` 가 저장된 계산 파라미터로 금액을 **재계산해 저장값과 대조**하기
* 때문입니다. 손으로 만든 계산 결과는 재계산값과 어긋나 `OrderAmountChangedException` 으로
* 막히며, 어긋나지 않게 맞추더라도 그때는 실제 결제 경로가 아닌 다른 것을 재게 됩니다.
*
* 준비(`prepare`)는 계측 구간 밖에서 회차마다 실행됩니다 — 임시 주문은 한 번만 주문으로
* 전환되므로 회차마다 새로 필요하고, 그 준비 비용이 측정값에 섞이면 안 됩니다. 여기서 만든
* 상품·회원·주문은 계측 커맨드가 감싼 트랜잭션 롤백으로 전부 되돌아갑니다.
*/
class OrderCreationBenchmark
{
public function __construct(
private readonly TempOrderService $tempOrderService,
private readonly OrderProcessingService $orderProcessingService,
) {}
/**
* 계측 회차 1건에 필요한 선행 상태를 준비합니다. (계측 구간 밖)
*
* 기존 상품을 골라 쓰지 않고 매 회차 새로 만드는 이유는, 설치본마다 상품 구성·재고·
* 판매상태가 달라 같은 조건에서 재고 있는 단일 옵션 상품 1건을 스스로 세우는 편이
* 회차 간·환경 간 비교 가능성을 보장하기 때문입니다.
*
* @param int $run 계측 회차 번호
* @return array{temp_order: TempOrder, user: User, expected_total_amount: float} 계측 컨텍스트
*/
public function prepare(int $run): array
{
$user = User::factory()->create();
$product = Product::factory()->create([
'stock_quantity' => 10000,
'has_options' => false,
'option_groups' => null,
// 기본 배송정책 해석에 맡긴다 — 특정 정책을 지목하면 그 정책의 비용만 재게 된다
'shipping_policy_id' => null,
]);
$option = ProductOption::factory()->forProduct($product)->create([
'stock_quantity' => 10000,
'price_adjustment' => 0,
'is_default' => true,
'is_active' => true,
]);
// 구매 대상 제한 검증이 Auth::user() 의 역할을 읽으므로 인증 주체를 세운다.
// 콘솔에는 세션이 없어 login() 대신 setUser() 를 쓴다.
Auth::setUser($user);
$tempOrder = $this->tempOrderService->createTempOrderFromDirectItems(
items: [[
'product_id' => $product->id,
'product_option_id' => $option->id,
'quantity' => 1,
]],
userId: $user->id,
cartKey: null,
);
return [
'temp_order' => $tempOrder,
'user' => $user,
// 프론트엔드가 보내는 결제예정금액에 해당 — 임시 주문의 최종 금액을 그대로 쓴다
'expected_total_amount' => (float) $tempOrder->getFinalAmount(),
];
}
/**
* 계측 대상 — 임시 주문을 실제 주문으로 생성합니다.
*
* @param array{temp_order: TempOrder, user: User, expected_total_amount: float} $context prepare 산출물
* @return Order 생성된 주문
*/
public function create(array $context): Order
{
return $this->orderProcessingService->createFromTempOrder(
tempOrder: $context['temp_order'],
ordererInfo: [
'name' => '성능계측',
'phone' => '01000000000',
'email' => $context['user']->email,
],
shippingInfo: [
'recipient_name' => '성능계측',
'recipient_phone' => '01000000000',
'country_code' => 'KR',
'zipcode' => '06236',
'address' => '서울특별시 강남구 테헤란로 1',
'address_detail' => '1층',
],
paymentMethod: 'card',
expectedTotalAmount: $context['expected_total_amount'],
);
}
}