리눅스에서 프로그램 실행 속도를 측정하는 방법

리눅스에서 프로그램 실행 시간을 측정하는 것은 간단해 보일 수 있지만, 제대로 구현하는 것이 시스템이 빠르게 발전하느냐, 아니면 느리게 움직이느냐의 차이를 만듭니다.스크립트를 이용해 작업을 자동화하거나, 애플리케이션을 개발하거나, 서버를 관리하기 시작하면 시간은 더 이상 추상적인 개념이 아니라 기술적 의사 결정을 내리는 데 있어 핵심적인 정보가 됩니다.

일상생활에서 우리는 단순히 어떤 것이 "빠른지" 또는 "느린지"에만 관심이 있는 것은 아닙니다. 구체적인 측정값이 필요합니다. 초, 밀리초 단위로 표시하고, 값이 매우 큰 경우에는 HH:MM:SS 형식으로 표시해 주세요. 이를 통해 더 잘 이해할 수 있습니다. 그런 다음 솔루션을 비교하고, 병목 현상을 파악하고, 성능 추세를 모니터링하고, 전반적으로 프로그램과 서비스의 동작 방식을 추적할 수 있습니다.

리눅스에서 실행 시간을 측정하는 데 관심이 있는 이유는 무엇인가요?

개인용 노트북이든 운영 서버든, 리눅스를 사용할 때는 다음과 같은 사항을 고려해야 합니다. 스크립트와 프로그램의 실행 시간을 아는 것은 성능을 향상시키는 데 매우 효과적인 방법입니다.단순한 호기심이 아닙니다. 이는 자원 소모 감소, 빠른 응답 속도, 그리고 사용자에게 더욱 원활한 경험을 제공하는 결과로 이어집니다.

시간을 측정하는 주요 이유 중 하나는 다음과 같습니다. 성능 최적화: 어떤 작업에 걸리는 시간을 모르면 개선되었는지 악화되었는지 알 수 없습니다.백업, 데이터 처리 또는 배포 스크립트 실행 시간을 기록하면 어떤 부분이 느린지 파악하고 해당 부분에 최적화 노력을 집중할 수 있습니다.

또한 이것은 다음과 같은 핵심입니다. 해결 방법 비교: 프로그래밍에서는 동일한 문제를 해결하는 방법이 거의 항상 여러 가지가 있습니다.Bash, Python 또는 C 언어로 알고리즘을 구현하거나 다양한 데이터베이스 쿼리를 테스트할 수 있습니다. 각 대안의 실행 시간을 측정함으로써 특정 환경에서 실제로 가장 효율적인 방법을 선택할 수 있습니다.

또 다른 흥미로운 점은 시간 경과에 따른 성능 모니터링: 오늘 빠르게 실행되는 스크립트도 몇 번의 변경 후에는 성능이 저하될 수 있습니다.실행 시간을 정기적으로 측정하면 예상보다 오래 걸리기 시작하는 시점을 파악하고 코드 수정, 라이브러리 변경 또는 시스템 부하와 연관 지을 수 있습니다.

실행 시간을 측정하는 것도 도움이 됩니다. 자신과 팀, 그리고 사용자들을 위해 현실적인 기대치를 설정하세요.가져오기 프로세스에 약 20분이 소요된다는 것을 알고 있다면 "단 몇 초 만에 완료될 것"이라고 장담하지 않을 것입니다. 더욱이 이러한 정보는 리소스 집약적인 작업을 언제 시작할지 계획하고 시스템 리소스를 적절하게 조정하는 데 매우 중요합니다.

마지막으로, 측정을 통해 다음을 파악할 수 있습니다. 확장성 문제: 데이터 양이 적을 때는 잘 작동하는 스크립트도 부하가 증가함에 따라 속도가 급격히 느려질 수 있습니다.다양한 입력 크기를 사용하거나 측정하여 지속 시간을 측정합니다. 다른 기계들병렬화, 캐싱, I/O 개선 또는 완전한 재설계가 필요한지 여부를 파악하기가 더 쉽습니다.

time 명령어를 사용하여 실행 시간을 측정합니다.

리눅스에서 프로그램이나 스크립트 실행 시간을 측정하는 가장 직접적인 방법은 명령어를 사용하는 것입니다. 시간은 성과 지표를 얻는 데 있어 간단하면서도 강력한 도구입니다.가장 좋은 점은 프로그램을 수정할 필요가 없다는 것입니다. 단순히 이 명령어를 앞에 붙여 프로그램을 실행하기만 하면 됩니다.

가장 기본적인 사용법은 다음과 같습니다. 측정하려는 명령어 앞에 "시간"이라는 단어를 추가하세요.예를 들어, 부하가 많이 걸린 디렉터리의 목록을 불러오는 데 걸리는 시간을 알고 싶다면 터미널에서 명령어 앞에 "time"을 붙여 입력하고 통계 정보가 포함된 출력을 기다리면 됩니다.

실행이 완료되면, 시간은 잘 이해해야 할 세 가지 주요 시간대를 보여줍니다.첫 번째는 "실제" 시간으로, 사용자가 인지하는 바와 같이 명령이 실행된 시점부터 종료된 시점까지 경과된 총 시간을 나타냅니다.

실시간 데이터 외에도 출력에는 "사용자" 및 "시스템" 값이 포함되어 있으며, 이 값들은 다음과 같은 정보를 제공합니다. 프로그램 실행 중 CPU 사용 방식에 대한 자세한 정보"user"는 프로세서가 사용자 모드에서 프로그램 코드를 실행한 시간을 나타내고, "sys"는 커널이 해당 프로세스를 대신하여 시스템 호출을 수행하는 데 소요된 시간을 나타냅니다.

이러한 분리는 매우 유용합니다. 왜냐하면 이를 통해 프로그램이 순수 계산에 시간을 소비하는지 아니면 디스크 및 네트워크와 같은 시스템 작업에 시간을 소비하는지 구분할 수 있습니다.예를 들어, "sys"가 많이 포함된 프로세스는 I/O 작업이나 시스템 호출의 집중적인 사용으로 인해 제한될 수 있는 반면, "user"가 많이 포함된 프로세스는 일반적으로 CPU 의존도가 더 높습니다.

측정 결과를 저장하려면 다음을 수행할 수 있습니다. 명령 데이터와 시간 통계를 모두 저장하기 위해 표준 출력과 오류 출력을 리디렉션합니다.이렇게 하면 나중에 스크립트의 여러 버전 간 또는 다른 서버에서 실행 시간이 어떻게 변하는지 분석할 수 있습니다.

시간 및 기타 기법을 사용하여 Bash 스크립트 실행 시간을 측정합니다.

완전한 Bash 스크립트에 관심이 있는 경우에도 접근 방식은 크게 달라지지 않습니다. 스크립트 앞에 `time` 명령어를 붙여 실행하면 스크립트 실행에 대한 전반적인 메트릭을 얻을 수 있습니다.이는 전체 워크플로우를 완료하는 데 걸리는 시간을 개괄적으로 파악하는 데 매우 유용합니다.

Time을 외부에서 사용하는 것 외에도 다음과 같은 방법도 있습니다. 날짜 변수와 산술 연산을 사용하여 스크립트 내의 특정 부분을 측정합니다.예를 들어, 특정 시점(에포크)부터 시작 시간과 종료 시간을 초 단위로 기록하고 두 시간을 빼면 특정 코드 블록이 실행된 시간을 알 수 있습니다.

많은 경우, 뺄셈 결과는 매우 큰 초 단위 숫자가 될 것이고, "7432"라는 숫자를 읽는 것은 직관적이지 않기 때문에, 초 단위 시간을 HH:MM:SS와 같은 사람이 읽기 편한 형식으로 바꾸는 것이 매우 실용적입니다.이렇게 하면 특히 주기적으로 검토되는 로그의 해석이 훨씬 쉬워집니다.

해당 변환을 자동화하려면 다음을 수행할 수 있습니다. 스크립트의 논리를 뒷받침하기 위해 날짜와 시간을 형식화하는 시스템 도구를 사용하십시오.또는 초를 시, 분, 초로 나누는 간단한 함수를 구현해 보세요. 이처럼 세부적인 정보는 긴 실행 로그를 이해하는 데 매우 중요합니다.

더욱 편안한 것을 원하신다면, 다른 스크립트를 실행하고, 시간을 측정하고, 다양한 형식으로 총 시간을 보기 좋게 출력하는 간단한 래퍼 또는 헬퍼 스크립트를 만드세요.이렇게 하면 리눅스 시스템에서 수행하는 모든 자동화 작업에서 해당 도구를 재사용할 수 있습니다.

디스크 활동 및 성능에 미치는 영향을 측정하는 도구

프로그램 속도는 CPU에만 의존하는 것이 아닙니다. 디스크 성능은 읽기 및 쓰기 작업이 많은 프로세스의 실행 시간에 큰 영향을 미칩니다.리눅스에는 저장 장치의 상태를 모니터링하는 데 사용할 수 있는 여러 콘솔 도구가 있습니다.

매우 다재다능한 유틸리티입니다. dstat은 디스크 활동을 비롯한 다양한 시스템 지표에 대한 실시간 통계를 얻을 수 있도록 해주는 도구입니다.디스크 입출력 작업에만 집중하고 싶다면 적절한 매개변수를 사용하여 해당 정보를 필터링하고 매초 값이 어떻게 변하는지 확인할 수 있습니다.

dstat 명령의 출력 결과에는 다음과 같은 열들이 표시됩니다. 읽기 및 쓰기 작업을 보여주므로 프로그램 속도를 저하시킬 수 있는 I/O 급증 현상이 있는지 확인하는 데 도움이 됩니다.이 도구는 대화형 도구이므로 분석에 필요한 데이터가 충분해지면 적절한 키 조합을 눌러 간단히 중단할 수 있습니다.

또 다른 고전적인 도구는 다음과 같습니다. iostat은 입력 및 출력 장치의 부하를 모니터링하고 해당 장치가 얼마나 오랫동안 사용 중인지 확인하도록 설계되었습니다.이 기능은 디스크 중 하나가 지속적으로 100% 사용률을 보이는지 확인하는 데 이상적이며, 이로 인해 해당 디스크에 액세스하는 모든 프로그램의 응답 시간이 길어질 수 있습니다.

서버와 같이 수많은 "루프 장치"가 있는 시스템과 같이 장치가 많은 시스템에서는 iostat에서 실제 물리적 디스크만 표시하도록 필터링하는 것이 흥미로울 수 있습니다.이는 적절한 매개변수를 설정함으로써 달성되며, 출력의 노이즈를 줄이고 진정으로 중요한 것에 집중할 수 있도록 해줍니다.

Ubuntu와 같은 배포판에서는 iostat을 사용합니다. 이 프로그램은 sysstat 패키지의 일부이므로 사용하기 전에 먼저 설치해야 합니다.일단 사용 가능해지면 정기적으로 보고서를 생성하도록 요청할 수 있는데, 이는 프로그램 실행 시간과 프로그램 실행 중 디스크 동작 간의 상관관계를 파악하는 데 매우 유용합니다.

특정 시점에 디스크를 가장 많이 사용하는 프로세스를 확인하려면 다음을 사용할 수 있습니다. 디스크 공간을 가장 많이 사용하는 프로세스를 확인하세요.진입 및 퇴출 운영에 중점을 둔 일종의 "상위"

또한 iotop을 사용하면 다음과 같은 작업을 수행할 수 있습니다. -d와 같은 옵션을 사용하여 새로 고침 간격을 조정하여 정보가 업데이트되는 빈도를 결정할 수 있습니다.참고로, 이 기능을 사용하려면 일반적으로 관리자 권한이 있거나 특정 관리자 그룹에 속해야 합니다.

덜 알려져 있지만 매우 유용한 또 다른 명령어는 다음과 같습니다. ioping은 I/O 볼륨보다는 디스크 지연 시간에 초점을 맞춥니다.즉, 스토리지가 요청에 응답하는 데 걸리는 시간을 측정하는 것으로, 특정 액세스의 지연을 증가시키는 하드웨어 또는 구성 문제를 감지하는 데 필수적입니다.

시스템 전체를 조망하려면 다음을 활용할 수 있습니다. atop은 기존 탑의 기능을 확장한 고급 도구입니다.atop은 다양한 데이터 포인트 중에서 디스크 성능 관련 정보를 표시하여 프로그램의 병목 현상이 스토리지, CPU, 메모리 또는 네트워크에 있는지 확인할 수 있도록 해줍니다.

디스크 부분에만 집중하고 싶으시다면, 파이프 및 필터와 결합하여 I/O 하위 시스템과 관련된 정보만 남길 수 있습니다.이렇게 하면 다른 지표에 방해받지 않고 스토리지 동작에 대한 구체적인 정보를 얻을 수 있습니다.

명령줄에서 웹 응답 시간을 측정합니다.

웹 서비스 역할을 하는 프로그램의 "속도"를 측정하려는 경우에는 상황이 조금 달라집니다. 여기서 핵심 정보는 일반적으로 사이트 또는 API의 응답 시간입니다.리눅스에서도 이를 위한 도구를 제공하며, 그중 가장 강력하고 유연한 도구 중 하나가 curl입니다.

명령 curl은 HTTP, HTTPS, FTP 또는 FILE과 같은 프로토콜을 사용하여 데이터를 전송하는 데 있어 진정한 만능 도구입니다.일반적으로 파일을 다운로드하거나 HTTP 헤더를 검사하는 데 사용되지만, 요청의 다양한 부분 시간을 측정하는 매우 흥미로운 기능을 숨기고 있습니다.

적절한 옵션을 선택하면 curl을 사용할 수 있습니다. 작업 후 이름 확인, 연결 및 전송 시간과 관련된 일련의 변수를 출력합니다.즉, URL로 요청을 보내면 프로세스의 각 단계에 소요된 시간을 초 단위로 확인할 수 있습니다.

예를 들어 HTTP 사이트의 동작 방식을 확인하고 싶다면 다음과 같이 할 수 있습니다. curl을 자동 실행 모드로 호출하고, 출력할 타이밍 데이터를 지정한 다음, 응답 내용을 /dev/null로 리디렉션하여 버립니다.이렇게 하면 이 상황에서 중요한 성능 지표만 확인할 수 있습니다.

표시할 수 있는 변수 중 하나는 다음과 같습니다. time_namelookup은 작업 시작부터 DNS 이름 확인이 완료될 때까지 걸린 시간을 나타냅니다.이 값이 높으면 병목 현상은 웹 서버 자체가 아니라 이름 확인 과정에서 발생할 수 있습니다.

또 다른 관련 지표는 time_connect는 서버 또는 프록시와 TCP 연결을 설정하는 데 걸리는 시간을 측정합니다.이 값이 증가하는 것은 네트워크 문제, 서버 과부하 또는 방화벽으로 인한 지연을 나타낼 수 있습니다.

변수 time_pretransfer는 시작 시점부터 데이터 전송이 정확히 시작되는 순간까지의 시간을 나타냅니다.따라서 콘텐츠 전송에 앞서 이름 확인, 연결 및 협상이 포함됩니다.

또한 주의를 기울여야 할 중요한 점은 다음과 같습니다. time_starttransfer는 작업 시작부터 응답의 첫 번째 바이트를 전송할 준비가 될 때까지의 시간을 나타냅니다.이 지표는 일반적으로 서버가 요청을 처리하고 초기 응답을 생성하는 데 걸리는 시간과 관련이 있습니다.

마지막으로, 당신은 time_total은 첫 ​​단계부터 전송이 완료될 때까지 전체 작업에 소요된 총 시간을 나타냅니다.이는 일반적으로 웹사이트의 "로딩 시간" 또는 "응답 시간"에 대한 일반적인 참고 자료로 사용되는 데이터입니다.

curl로 인쇄하려는 형식이 매우 길거나 복잡한 경우, 해당 결과를 텍스트 파일로 저장한 다음, 적절한 옵션을 사용하여 curl이 해당 파일에서 읽도록 할 수 있습니다.이렇게 하면 서로 다른 테스트와 URL에 대해 동일한 출력 패턴을 훨씬 쉽게 재사용할 수 있습니다.

해당 파일에서는 관심 있는 모든 시간 변수를 읽기 쉬운 레이블과 함께 그룹화할 수 있습니다. curl을 실행할 때마다 파싱된 URL에 대한 간단한 시간 보고서가 반환됩니다.이렇게 하면 애플리케이션의 다양한 서버, 경로 또는 구성을 빠르게 비교할 수 있습니다.

HTTPS 사이트의 시간 측정 방법 및 고려 사항

HTTPS로 제공되는 웹사이트의 경우, 통신 과정에는 측정해 볼 만한 추가적인 단계들이 있습니다. Curl은 SSL/TLS 협상 및 리디렉션에 소요되는 시간을 고려하기 위해 추가 변수를 포함합니다..

이러한 변수 중 하나는 다음과 같습니다. time_appconnect는 작업 시작부터 원격 서버와의 연결 또는 SSL 교환이 완료될 때까지 걸린 시간을 측정합니다.이 값이 높게 나온다면 TLS 구성, 인증서 또는 암호화 계층 자체에 문제가 있을 수 있습니다.

또 다른 유용한 지표는 다음과 같습니다. time_redirect는 최종 거래 이전에 발생한 모든 리디렉션 단계에 소요된 시간을 합산한 값입니다.여기에는 이름 검색, 연결 및 중간 전송이 포함되므로 최종 콘텐츠에 도달하기 전 3XX 홉에서 얼마나 손실되는지 파악하는 데 도움이 됩니다.

HTTP에서와 마찬가지로 이러한 변수는 다음과 같습니다. 형식화된 파일에 포함되어 다양한 HTTPS 사이트를 대상으로 수행하는 테스트에서 재사용될 수 있습니다.이렇게 하면 서버, 도메인 또는 테스트 환경 간의 결과를 쉽게 비교할 수 있는 일관된 보고서를 항상 얻을 수 있습니다.

다음 사항을 명심하는 것이 중요합니다. 암호화의 특성상 HTTPS 사이트는 일반 HTTP 사이트보다 응답 시간이 약간 더 오래 걸리는 것이 일반적입니다.차이가 지나치게 크다면 TLS 매개변수, 키 크기 또는 서버 구성을 검토하는 것이 좋을 수 있습니다.

중요한 세부 사항은 다음과 같습니다. curl이 반환하는 값은 겉보기에 비슷한 조건에서도 실행할 때마다 크게 달라질 수 있습니다.서버 부하, 네트워크 혼잡 또는 DNS 응답 시간과 같은 요소는 응답 시간에 직접적인 영향을 미칩니다.

그래서 그게 맞는 거죠. 하루 중 여러 시간대에 검사를 여러 번 반복하고 평균값 또는 값의 범위를 구하십시오.단일 시점의 측정값에 기반하여 최적화 결정을 내리면 잘못된 결론으로 ​​이어질 수 있습니다.

컬링의 가능성을 더욱 깊이 탐구하고 싶다면 언제든지 다음을 시도해 볼 수 있습니다. 사용 가능한 모든 옵션을 보려면 해당 명령어를 사용하여 매뉴얼 페이지를 참조하십시오.거기에서 웹 성능 테스트를 위한 훨씬 더 많은 시간 변수와 고급 기법들을 찾아볼 수 있습니다.

지연 및 손실을 이해하는 데 유용한 네트워크 명령어

네트워크를 통해 통신하는 프로그램의 속도는 코드 자체뿐만 아니라 다른 요소에도 달려 있습니다. 연결 품질과 네트워크 상태는 실행 시간에 직접적인 영향을 미칩니다.리눅스는 이 부분을 확인하기 위해 여러 명령어를 제공합니다.

우선, 당신은 가지고 있습니다 ss는 활성 네트워크 연결 목록을 상당히 상세하게 보여주는 최신 도구입니다.적절한 매개변수를 사용하여 실행하면 어떤 TCP 연결이 열려 있는지, 어떤 프로세스가 해당 연결을 사용하고 있는지, 그리고 연결 상태가 어떤지 확인할 수 있습니다.

당신이 알고 싶어하는 것이 있다면 어떤 서비스들이 특정 포트에서 수신 대기하며 연결을 기다리고 있습니까?ss 명령어를 다른 옵션 조합과 함께 사용할 수도 있습니다. 이렇게 하면 어떤 장치가 트래픽을 수신하여 서버 성능에 영향을 미치는지 파악할 수 있습니다.

패킷 손실 및 다른 서버와의 기본 지연 시간을 확인하려면 고전적인 방법이 있습니다. 핑은 여전히 ​​필수적인 도구입니다.적절한 옵션을 선택하여 발송하는 소포 수를 제한하면 평균 왕복 시간과 손실률을 신속하게 파악할 수 있습니다.

라우팅 문제가 의심되는 경우 다른 유틸리티를 사용할 수 있습니다. traceroute는 패킷이 목적지에 도달하기까지 거치는 네트워크 홉을 보여줍니다.중간 라우터 목록과 각 라우터의 응답 시간을 확인할 수 있으며, 이를 통해 지연이 발생하는 지점을 정확히 파악할 수 있습니다.

CentOS나 Ubuntu 같은 배포판에서는 다음이 필요할 수 있습니다. traceroute를 사용하려면 먼저 해당 패키지 관리자를 사용하여 설치하십시오.설치가 완료되면 대상 서버의 IP 주소 또는 도메인 이름을 입력하기만 하면 패킷이 이동하는 경로를 확인할 수 있습니다.

이러한 네트워크 도구를 프로그램 시간 측정 및 디스크 통계와 결합함으로써, 업무 과정에서 시간이 어디에 쓰이는지 상당히 완벽하게 파악할 수 있습니다.이는 외부 리소스에 의존하는 분산 애플리케이션이나 서비스가 있는 경우에 매우 중요합니다.

실제로 리눅스의 명령줄은 다음과 같이 작동합니다. 시스템 성능 진단 및 최적화를 위한 진정한 스위스 아미 나이프스크립트 실행 시간부터 네트워크 지연 시간, 디스크 포화도까지 모든 것을 적절한 도구를 사용하면 측정할 수 있습니다.

이러한 명령어를 체계적으로 사용하고, 테스트 과정을 문서화하고, 결과를 기록한다면, 이를 통해 성능 저하를 훨씬 쉽게 감지하고, 병목 현상을 파악하며, 정보에 기반한 확장성 결정을 내릴 수 있습니다.궁극적으로 정확한 측정은 실질적인 개선을 위한 첫걸음입니다.