심플 이즈 베스트

### 대형 이미지 처리 - libvips와 ImageMagick의 성능 비교 이미지 처리는 웹 개발에서 데이터 분석까지 다양한 분야에서 중요한 역할을 합니다. 많이 사용되는 툴로는 ImageMagick과 libvips가 있으며, 각각 강력한 기능과 성능을 제공합니다. 이번 포스트에서는 두 라이브러리의 장단점과 벤치마크 결과를 통해 대형 이미지 처리와 썸네일 생성 시 어떤 툴이 더 적합한지 살펴보겠습니다. --- ### 장단점 비교표: libvips vs. ImageMagick - Magick의 장점은 다양한 확장자 (heif/heic/psd/svg/gif/raw 이미지 등으로 library 적재하여 빌드시 무궁무진함) - VIPS의 경우 고해상도 이미지에 대해 추출 시 속도 장점이 존재 | **기능** | **libvips** | **ImageMagick** | |---------------------|--------------------------------------------------------------------|----------------------------------------------------------------| | **추출 속도** | 빠름, 특히 대형 이미지 처리 시 4-8배 빠름 | 다양한 작업에서 안정적인 성능, 대형 이미지 처리 시 속도 저하 가능 | | **메모리 사용량** | 메모리 효율적, 필요한 픽셀만 메모리에 로드 | 전체 이미지를 메모리에 로드하여 더 많은 메모리 소비 가능 | | **기능성** | 이미지 리사이즈 및 변환에 최적화, 다소 복잡한 설정 필요 ...

리스팅 까지 진행됫고, 업/다운을 Drogon을 통해 구현한다 --- ## 1. 서버 기능 구현 ### 1-1. Drogon Contoller 구현 Drogon Contoller 등록 진행을 한다 ( 아래 작업을 해야 빌드시 인식이 됨 ) ``` cd /root/drogon2/drogon/build/drogon_ctl drogon_ctl create controller FileController ``` --- ### 1-2. 업/다운 구현 소스 위치할 경로 ( /root/drogon2/drogon/build/drogon_ctl/testAPI/controllers ) FileController.h #pragma once #include using namespace drogon; class FileController : public HttpController { public: std:: string _storagePath = "/root/storage/"; METHOD_LIST_BEGIN // "/upload" 경로의 POST 요청 처리 ADD_METHOD_TO(FileController::handleUpload, "/upload", Post); // "/download/{filename}" 경로의 GET 요청 처리 ADD_METHOD_TO(FileController::handleDownload, "/download/{1}", Get); METHOD_LIST_END // 메서드 선언 void handleUpload(const HttpRequestPtr& req, std::function && callback); void handleDownload(const HttpRequestPtr& req, std::function && ca...

업/다운로드를 구현 하기 전 우선 장비 local 저장소를 만들고 해당 저장소를 web에서 볼수있게 먼저 정의한다 --- ## 1. 저장소 생성 및 권한 부여 - 저장소 생성 ``` mkdir /root/storage cd /root/storage vi test.txt ( 적당히 아무값 넣고 저장 종료 ) ``` - nginx가 뜬 user권한을 폴더에 부여 ``` ps aux | grep nginx --- # 제 경우는 nobody 이므로 해당 폴더 소유주 변환 [root@vbox build] (master) $ ps aux | grep nginx root 52636 0.0 0.0 4544 2412 ? Ss 01:26 0:00 nginx: master process ./nginx root 59772 0.0 0.1 13064 9600 pts/1 T 06:04 0:00 /usr/bin/vim nginx.conf nobody 60676 0.0 0.0 13168 5484 ? S 06:23 0:00 nginx: worker process nobody 60677 0.0 0.0 13168 5612 ? S 06:23 0:00 nginx: worker process --- # 권한 및 소유주 변환 sudo chmod -R 755 /root/storage sudo chown -R nobody:nobody /root/storage # SELinux 보안 컨텍스트 수정 sudo chcon -R -t httpd_sys_content_t /root/storage ``` 위 작업들을 수행하지 않으면, 403 Fobbiden을 맞게된다 --- ## 2. Nginx 설정 적용 - alias 통해, list api 가 들어오면 /root/storage의 경로를 보여준다 ``` user nobody; worker_proce...

API를 만들어보자 Drogon 으로 만들거고, 관련 해서 특정 값을 리턴하는 정도로 진행한다 --- ## 1. Drogon Test Project 설정 - drogon_ctl 이 설치된 곳에서 아래 명령어를 입력한다 ``` drogon_ctl create project testAPI cd testAPI ``` --- ## 2. 빌드 - 전체 경로의 경우 /root/drogon2/drogon/build/drogon_ctl/testAPI/build 가 된다 ``` mkdir build cd build cmake .. make ``` --- 만약 아래 에러 발생 시 환경변수 선언하고 drogon 재설치하는게 마음편하니 재설치하자 ``` CMake Error at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:76 (find_package): By not providing "FindJsoncpp.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Jsoncpp", but CMake did not find one. Could not find a package configuration file provided by "Jsoncpp" with any of the following names: JsoncppConfig.cmake jsoncpp-config.cmake Add the installation prefix of "Jsoncpp" to CMAKE_PREFIX_PATH or set "Jsoncpp_DIR" to a directory containing one of the above files. If "Jsoncpp...

C++ 서버로 만들어 보는게 목표이기에 프레임워크 서치를 우선 진행 ## 0. C++ 웹 프레임워크 조사 | 프레임워크 | 장점 | 단점 | |------------|------|------| | **Drogon** | - 최신 C++14/17 지원 - 비동기 프로그래밍 및 다중 스레드 지원 - HTTP2, WebSocket 지원 - 높은 성능 및 사용자 친화적 API - 활발한 커뮤니티 및 지원 | - 초기 설정이 복잡할 수 있음 | | **Pistache** | - 경량 설계로 빠른 웹 서버 구현 - RESTful API 개발에 적합 - 간단한 코드와 쉬운 학습 | - 개발 및 업데이트 속도가 느림 - 제한된 기능성 | | **Crow** | - Flask와 유사한 직관적인 사용법 - JSON 지원 및 라우팅 기능 포함 - 경량 설계 | - 기능이 제한적이며 대규모 애플리케이션에는 부적합 - 유지보수가 부족할 수 있음 | | **CppCMS** | - 고성능 웹 애플리케이션 구축 가능 - 세션 관리 및 국제화 지원 | - 설정이 복잡하고 높은 학습 곡선 - 문서가 부족하고 사용법이 어렵다 | | **Restbed** | - RESTful API 개발에 적합 - 비동기 및 확장 가능한 설계 | - 제한된 기능으로 대규모 프로젝트에는 부적합 - 커뮤니티 지원이 활발하지 않음 | - GPT 피셜 인기 좋은 Drogon으로 우선 진행해보기로한다. --- ## 1. 프레임워크 의존성 설치 ``` sudo yum install -y git cmake gcc-c++ libuuid-devel openssl-devel zlib-devel brotli-devel jsoncpp-devel libuuid libuuid-devel ``` jsoncpp-devel 없다면 별개 설치필요 --- ### jsoncpp는 별개 설치 ``` # jsoncpp 소스 코드 다운로드 git clone https://github.com/open-source-parsers/jso...

시스템 경로에 셋업하여 실행하는 법이 있지만, 다운로드 및 빌드하여 셋업하는 방법으로 진행하겠습니다. ## 구축환경 - Red Hat Enterprise Linux release 9.4 (Plow) ## 1. NGINX 다운로드 및 압축 해제 ``` wget http://nginx.org/download/nginx-1.21.6.tar.gz tar -xvf nginx-1.21.6.tar.gz ``` --- ## 2. 필요 Library 설치 ``` sudo yum install -y gcc pcre pcre-devel zlib zlib-devel openssl openssl-devel ``` - gcc: C 컴파일러로, NGINX 소스 코드를 컴파일하여 실행 가능한 프로그램으로 만드는데 필요합니다. - pcre: Perl Compatible Regular Expressions 라이브러리로, NGINX에서 정규 표현식을 처리할 수 있도록 지원합니다. - pcre-devel: PCRE 라이브러리의 개발 헤더 파일을 포함하며, NGINX를 컴파일할 때 필요합니다. - zlib: 데이터 압축을 위한 라이브러리로, NGINX의 Gzip 압축 기능을 사용하기 위해 필요합니다. - zlib-devel: zlib의 개발 파일을 포함하며, 소스 컴파일 시 필요한 헤더 파일과 라이브러리를 제공합니다. - openssl: SSL/TLS 암호화를 위한 라이브러리로, HTTPS 및 보안 연결을 처리하기 위해 NGINX에 필요합니다. - openssl-devel: OpenSSL 라이브러리의 개발 헤더 파일을 포함하며, NGINX의 SSL/TLS 지원을 컴파일할 때 필요합니다. --- 만약 설치시 아래 에러가 발생한다면 ``` Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) 0.0 B/s | ...

테스트용 Linux 셋업을 위해 가상환경 설치 진행 VMWare를 쓸려햇는데 가입이 귀찮게 되어있어 VirtualBox로 선회 ### 셋업 환경 - window10 ### 설치 ## 1. VirtualBox - Download - https://www.virtualbox.org/wiki/Downloads - 위 경로에서 다운로드 진행 ( OS에 맞게 설치, widnows hosts 로 진행 ) --- - 다운로드 이후 설치 진행 --- ## 2. RHEL(RedHat Enterprise Linux) OS 다운로드 CentOS를 주로썼지만 EOL (End of Line) 으로 이제는 RHEL쓰기를 권장 - https://developers.redhat.com/products/rhel/download (24.11.02 기준 9.4 version) - RHEL을 무료로 사용하려면 Individual Developer Subscription에 등록해야 하고 등록 비용은 발생하지 않는다. --- ## 3. VirtualBox - RHEL 가상머신 만들기 1. 머신 > 새로 만들기 ㄴ 저장소 경로 설정 --- 2. VM 비밀번호 셋업 --- 3. 가상머신 리소스 할당 ㄴ 사용 컴퓨터에 따라 동적으로 변함. 저는 4core / 8GB 할당함 (20GB) --- 4. 소프트웨어 확인 (GUI 시스템은 필요없어서 제거) --- 5. 접속 확인 --- ## 4. Putty 연결 아래 사항 확인 ### 4-1.VM 설정에서 확인 사항 ``` 1. VirtualBox를 실행하고 연결할 가상 머신을 선택한 후 설정 2. 네트워크 탭 이동 > 어댑터 1을 NAT로 설정한 후 고급 옵션 3. 포트 포워딩 규칙 설정 이름: 원하는 이름 입력 (예: SSH) 호스트 포트: 9999 (또는 사용하지 않는 포트) 게스트 포트: 22 (기본 SSH 포트, 고정) ex) putty -(9999...

아파치 웹 서버(Apache HTTP Server)에서 프로세스 수 조절은 웹 서버의 성능을 최적화하고 안정성을 높이기 위해 중요한 작업입니다. 서버의 트래픽, 사용 환경, 리소스에 따라 적절한 프로세스 수를 설정하면 서버가 더 효율적으로 동작할 수 있습니다. 이 글에서는 Apache의 주요 멀티 프로세싱 모듈(MPM)인 Prefork와 Worker에서 프로세스 수를 조절하는 방법을 살펴보겠습니다. --- ### Apache의 MPM 종류 Apache는 요청을 처리하는 방식을 결정하는 **멀티 프로세싱 모듈(MPM)**을 제공합니다. 대표적인 MPM은 아래와 같습니다: - Prefork MPM: 각 요청을 별도의 프로세스로 처리하는 방식. 메모리 사용이 높지만, 각 프로세스가 독립적이어서 안정성이 높습니다. - Worker MPM: 하나의 프로세스 내에서 여러 스레드로 요청을 처리하는 방식. 메모리 효율이 뛰어나지만, 스레드가 공유하는 리소스에 대한 주의가 필요 - Event MPM: Worker MPM의 확장형으로, 비동기 요청을 더 효율적으로 처리할 수 있습니다. --- # Prefork MPM 설정 **Prefork MPM**은 요청마다 개별 프로세스를 생성하여 처리합니다. 이 설정을 통해 각 요청이 독립적으로 처리되므로 메모리 사용이 많지만, 안정성이 높은 방식입니다. 1. 설정 파일 열기: /etc/httpd/conf/httpd.conf 또는 /etc/apache2/apache2.conf 파일을 편집기로 엽니다. 2. Prefork 설정 추가 및 수정: ``` StartServers 5 # 시작 시 생성할 프로세스 수 MinSpareServers 5 # 최소 유휴 프로세스 수 MaxSpareServers 10 # 최대 유휴 프로세스 수 MaxRequestWorkers 150 # 동시에 처리할 최대 클라이언트...

# Kotlin 서버 환경에서 '!!' vs '?' 연산자 사용 가이드 Kotlin에서 '!!'와 '?' 연산자는 널(null) 안정성을 위해 자주 사용됩니다. 서버 환경에서는 특히 안정적인 코드가 중요하기 때문에, '!!'와 '?'를 상황에 맞게 올바르게 사용하는 것이 필수적입니다. 이 글에서는 두 연산자의 차이와 서버 환경에서 안전한 코드 작성을 위한 사용 가이드를 예시와 함께 정리합니다. --- ## '!!' 연산자: 널 강제 해제 - '!!' 연산자는 **널이 아님을 확신**할 때 사용하는 연산자로, 객체가 `null`일 경우 `NullPointerException`을 발생시킵니다. - 잘못 사용하면 서버의 예기치 않은 종료를 유발할 수 있기 때문에 서버 환경에서는 주의가 필요합니다. ### '!!'예제 ``` fun processData(data: String?) { val length = data!!.length // data가 null이면 예외 발생 println("Data length: $length") } fun main() { processData("Hello") // 정상 작동 processData(null) // NullPointerException 발생 } ``` 위 예제에서 data가 null인 경우 NullPointerException이 발생하며 서버가 중단될 위험이 있습니다. ## 서버에서 !! 사용 시 주의사항 - nullable 값의 null 가능성을 충분히 확인 후 사용해야 합니다. - 서버와 같이 예기치 않은 데이터가 유입될 수 있는 환경에서는 !! 사용을 최소화하는 것이 좋습니다. ## ? 연산자: 안전 호출 (Safe Call) - ? 연산자는 안전 호출 연산자로, 객체가 null일 수 있을 때 예외를 방...

# ImageMagick convert 명령어에서 CPU 사용량 제어하기 ImageMagick은 이미지 변환과 편집을 위한 강력한 도구로, convert 명령어를 통해 다양한 작업을 수행할 수 있습니다. 특히 시스템 리소스 사용을 세밀하게 제어할 수 있는 옵션들이 있어 시스템 성능을 최적화하고 자원 관리를 효율적으로 할 수 있습니다. 이 글에서는 convert 명령어의 CPU와 메모리 사용량을 제어하는 주요 옵션들에 대해 설명합니다. --- ## 1. -limit 옵션으로 리소스 사용 제한하기 -limit 옵션을 사용하면 ImageMagick이 사용하는 리소스를 제어할 수 있습니다. 주요 리소스 제한 옵션은 다음과 같습니다: ### 1.1 -limit thread -limit thread는 ImageMagick이 사용할 스레드 수를 제한하는 옵션입니다. 기본적으로 ImageMagick은 시스템의 모든 논리적 스레드를 사용하지만, -limit thread를 통해 특정 개수로 제한할 수 있습니다. **예시**: ``` convert -limit thread 2 input.jpg output.jpg 위 명령어는 convert 작업이 최대 2개의 스레드만 사용하도록 설정합니다. ``` ### 1.2 -limit memory와 -limit map -limit memory는 메모리 사용량을, -limit map은 메모리 매핑을 위한 사용량을 제한합니다. 시스템 메모리가 부족할 때 메모리 맵의 크기를 제한하여 ImageMagick이 디스크 기반 임시 저장소를 활용할 수 있도록 합니다. **예시**: ``` convert -limit memory 1GB -limit map 2GB input.jpg output.jpg ``` 위 명령어는 convert 작업에서 메모리는 최대 1GB, 메모리 맵은 최대 2GB까지 사용하도록 제한합니다. ### 1.3 -limit time -limit time은 작업에 소요되는 최대 시간을 초 단위로 설정하는 옵션입니다. 지정...

이전에는 설치를 진행하였고, (https://warguss.blogspot.com/2018/12/nginx-c-nginx-centos-2.html) 이번에는 따로 만들 모듈로 요청을 받는 것을 진행 해 보겠습니다. 우선 간단한 에코 서버를 준비합니다... (https://gist.github.com/suyash/2488ff6996c98a8ee3a84fe3198a6f85 이 사이트의 server.c를 그냥 사용했습니다) 빌드 후 다시 띄워주세요 (g++ -o server 파일) ./server 여기서 port만 우선 사용할 포트로 수정합니다.  (저는 10002 port를 사용하였습니다) nginx 설정을 수정합니다. 요런식으로 수정하고 nginx 다시 띄웁니다. 그리고 다시 웹으로 접속합니다. [root@localhost.localdomain back_module] $ ./server client connected with ip address: 0.0.0.0 received: 'GET / HTTP/1.0 Host: 127.0.0.1:10002 Connection: close Cache-Control: max-age=0 Upgrade-Insecure' 잘 찾아오네요.... 정리하자면  1. back module 개발 2. nginx 설정에서 특정 Command는 Back Module로 보내게끔 수정(port 일치 필요) 3. back module 띄움 4. nginx 재시작 5. 접속 테스트 이렇게 될거 같네요.  nginx가 요청 - Logic 모듈이 잘 분리되어 있는거 같습니다.  이를 토대로 Common한 Http Server를 개발해볼 예정입니다. 감사합니다~ 추가로 읽으면 좋을 것 ...

Nginx 개념에 대해 확인 하였는데, 이번에는 Nginx 설치 및 기본 화면 띄우기 목적으로 진행 하였습니다. 저는 Centos환경에서 했기 때문에 차이가 있을 수 있습니다. 설치를 위해 수행해야할 루틴은 다음과 같습니다. wget  http://nginx.org/download/nginx-1.15.7.tar.gz yum install pcre-devel   yum install openssl-devel nginx 압축 해제 tar -xvf nginx-1.1.5.7.tar.gz 내부 ./configure --prefix=$원하는 경로 입력 make make install 순차적으로 하나씩 보자면 1.  wget  http://nginx.org/download/nginx-1.15.7.tar.gz = nginx library 다운로드(원하는 버전으로 골라서 하시면됩니다) 2. yum install pcre-devel (nginx 설치 시 필요한 라이브러리로 선 설치 합니다) 3. yum install openssl-devel (마찬가지입니다.) 4. 다운로드 받은 것 해제합니다. 5. 해제 되면 ./configure 를 실행합니다.  (prefix를 통해 원하는 경로로 설정가능합니다) 6. make로 빌드 7. make install로 빌드한것을 configure로 설정한 경로로 셋업 합니다. 그 이후에는 설정 한 경로의 conf/nginx.conf에서 port 확인합니다. (보통 80port로 설정 되있을 텐데, 해제가 필요합니다) 저는 아래와 같이 방화벽 해제 하였습니다. 1. vi /etc/sysconfig/iptables 2. -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 3. service iptables restart 로...

간단한 프로젝트 진행 중.... (https://github.com/warguss/CommonServer) NginX란? (영어 참 지옥이네요...) 하나 하나 풀어서 확인해 보겠습니다. Controlling NGINX Processes at Runtime - Master and Worker Processes = 주인 그리고 하인 수행... [Master-Worker?] = Master 스레드가 요청을 받아서, Worker 스레드에 나눠주는 개념 (프로세스로도 가능) (Worker 스레드는 기본적으로 스레드 풀로 구성) = Master가 모든 것을 관장 하신다고 보면 될거 같습니다. - 상세 = 공식 문서입니다. 전 영어 잘몰라서 번역기로 해보겠습니다... [요약하자면...] 1. Master Process와 하나 이상의 Worker Process존재 (캐싱 설정이 되어 있다면 메모리 or H/W 캐싱으로 처리가능 [무엇을?]) 2. Master Process는 conf 파일을 읽고, 지속적으로 Worker Process를 관리 3. 실제 요청 처리는 Worker Process가 처리 4. 요청에 대한 분배 처리는 OS-dependent(뭐지이거) 메카니즘으로 처리 5. worker process에 대한 갯수 설정은 nging.conf에서 하세요 (코어 갯수에 따라 자동적으로 조정되긴한다[진짠지...]) Controlling Nginx = Master Process 사용법 정도라서 넘어가겠습니다... 위 공식 문서는(https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#master-and-worker-processes) 입니다. 설정 파일들에 대한 자세한 설명들이 있지만, 이건 사용 방법 이라 판단 되기에 바로 설치로 넘어가도록 하겠습니다. ...