라라벨과 루멘, PHP 날코딩간의 성능 비교를 해 보신 분들이 없는 것 같아 직접 해 봤다. 결론은 뻔하지만, PHP 날코딩이 가장 빠르고, 메모리 사용량도 적다. 프레임워크를 써야 이유는 다른 곳에 있으니, 이 실험 결과만 보고 오해나 곡해하지 마시기 바란다.

주의 이 실험은 다른 PHP 프레임워크 또는 다른 플랫폼의 프레임워크와 라라벨 또는 루멘의 성능을 비교하기 위한 것이 아니다(다른 PHP 프레임워크와의 비교는 “How Lumen Is Benchmarked”를 참고하라). 이 실험은 라라벨과 루멘의 기본적인 속도와 필요 리소스를 측정해 봄으로써, PHP 날코딩의 성능과 프레임워크가 제공하는 이점 간의 트레이드오프(trade-off)에 대한 의사 결정 포인트를 제공하기 위한 목적으로 수행하였다.

1. 실험 환경

다음 머신에서 실험했다.

• macOS Sierra 10.12.1
• 2.7 GHz Intel Core i5
• 8GB 1867 MHz DDR3
• SSD

사용한 소프트웨어 버전은 다음과 같다.

• PHP 7.0.11 with Xdebug, without OPcache
• MySQL 5.7.15
• Laravel Valet 1.1.22 (로컬 웹 서버)

2. 실험 방법

다음과 같이 실험했다.

• 웹 브라우저에서 테스트를 위한 URL 엔드포인트를 각 시나리오별로 총 5회 방문했고, 아웃라이어 2개는 버리고 남은 3개만 이용했다.
• 해당 엔드포인트는 MySQL 데이터베이스에서 2개의 레코드를 가져와서 HTTP 응답을 내 보내는 일을 하는데, HTTP 응답을 반환하기 직전에 현재까지의 1) 실행 시간, 2) 메모리 사용량을 로그에 기록하였다.

2.1. MySQL 테이블 레코드

MySQL에 저장된 2개의 레코드를 팅커(라라벨 내장 REPL) 콘솔에서 확인했봤다.

2.2. 테스트 코드

라라벨 기준으로 성능 측정 코드는 다음과 같다.

<?php // index.php

define('LARAVEL_START', microtime(true));

<?php // routes/web.php

Route::get('/', function () {
    $todos = App\Todo::all();

    Log::info('metric', [performance()]);

    return $todos;
});

performance() 함수는 이렇게 생겼다. 할당된 메모리 양이 아니라, 사용한 메모리 양으로 측정했다(memory_get_usage()).

<?php // app/helpers.php

function performance()
{
    return implode(',', [
        '처리시간(ms): ' . (microtime(true) - LARAVEL_START),
        '메모리(MB) : ' . memory_get_usage() / 1000000,
        'CPU(%): ' . sys_getloadavg()[0],
    ]);
}

3. 실험 결과

3.1. 라라벨

laravel/framework 5.3.19 버전을 이용했다.

3.2. 루멘

laravel/lumen-framework 5.3.1 버전을 이용했다.

3.3. PHP 날코딩

날 코딩이라 하지만, 컴포저와 PDO를 사용하고 MVC 구조로 짠 코드다.

4. 결론

속도나 메모리 사용량 면에서 PHP 날코딩이 확실히 유리하다. 이 테스트 기준으로 2GB 메모리 머신에서 PHP 날코딩이 1초당 610,649개의 요청을 처리할 수 있다면(2000/0.92 * 1000/3.56), 라라벨은 5,895개의 요청을 처리할 수 있다(2000/7.37 * 1000/45.34).

물론, 현실 세계에서 이런 간단한 서비스는 없으므로, 한 요청당 수십 MB의 메모리를 사용하고 수백 ms의 처리 시간이 걸린다. 운영 환경에서는 아파치나 엔진엑스를 사용하고, Xdebug를 끄고, OPcache를 켜서 성능을 향상시킬 수 있다.

프레임워크의 장점으로 생산성, 안정성, 보안을 들 수 있다. 수퍼 개발자가 있어 열 명이 해야 할일을 혼자서 처리하고, 해킹에 뚫릴 일이 전혀 없고 유지보수 하기도 편리한 자체 서비스 프레임워크를 직접 개발할 수 있다면, 라라벨과 루멘과 같은 프레임워크를 쓸 필요 없다.

경험적으로 수퍼 개발자에 의존하는 서비스 운영은 절대 바람직하지 않다. 수퍼 개발자가 자신의 지위를 악용하거나, 아프거나 퇴사라도 하는 순간 서비스는 한 순간에 무너진다.

컴퓨터의 성능은 좋아졌고, 가격은 싸져서 스케일 업(scale-up)이 쉬워졌다. 또, 쉽게 스케일 아웃(scale-out)할 수 있는 클라우드도 널렸다. 개발자 한 명 채용하는 비용보다 컴퓨터 비용이 훨씬 싸다는 점을 잊지 말자. 좋은 서버 쓰고 안정적인 코드를 빨리 개발하는 것이 더 현명하다.

반면 서비스가 궤도에 올라 사용자가 늘고 1ms와 1KB라도 쥐어 짜야 하는 상황이라면 자체 프레임워크 개발을 고려해볼 만한다. 물론 성능이 더 좋은 플랫폼으로 갈아 타는 방법도 있다. 서비스를 살리기 위해 스택을 버려야지, 스택을 살리기 위해 서비스를 버리는 어리석음을 범하지 말라. 라라벨이나 루멘은 범용 프레임워크이므로 최적화가 필요한 초대형 서비스에는 적합하지 않다는 생각이 든다.