다음 사이트 중 하나에 가입하면 무료로 쓸 수 있다.
http://lowratevoip.com
http://voipbuster.com
http://www.voipwise.com
[LowRate 가격표] http://www.lowratevoip.com/en/rates.html
south korea (Landline & Mobile) Superdeal ** FREE*
[5분 이하로만 사용!!! 5분 이상 사용시 다음부터는 안됨 -_-;]
[voipbuster 가격표] http://www.voipbuster.com/en/rates.html
South Korea (Landline) FREE* FREE*
South Korea (Mobile) 0.040 0.048
voipbuster는 일반전화만 60분무료
2007/09/28
닌텐도DS로 전화하기
닌텐도DS로 전화하는 방법 흐흐
1. http://libw11.free.fr/ 에서 프로그램을 다운 받는다.
2. DS에 넣어준다.
3. 다음 사이트 중 하나에 가입하거나, 삼성070 또는 LG070에 가입한다.
4.config.txt 설정을 한다.
VoipBuster.Com 기준
# This is a comment in the config file.
# Set domain sip provider (example: freephonie.net)
--domain sip.VoipBuster.com
# Set authentication username
--username Username (example: tiger)
# Set authentication password
--password Password (example: 123456)
# Optional registration interval (default 55) (for freephonie set 1800)
--reg-timeout 1800
# Optional microphone volume (default 1.0)
--micro-vol 3.0
# This is a comment in the config file.
# Set domain sip provider (example: freephonie.net)
--domain sip.lowratevoip.com
# Set authentication username
--username Username (example: tiger)
# Set authentication password
--password Password (example: 123456)
# Optional registration interval (default 55) (for freephonie set 1800)
--reg-timeout 1800
# Optional microphone volume (default 1.0)
--micro-vol 3.0
전화거는 방법 : 82(국가번호) 51(지역번호) 123 4567(전화번호)
+82-51-123-4567
+82-51-123-4567
2007/09/20
Web Application Stress Test
1 Web Application Stress Test Overview
웹 어플리케이션 개발 후 실제 운용 상황을 가상하여 테스트를 실시함으로써 어플리케이션, 시스템 , 네트워크 상황들을 점검해보는 목적이다. 안정적으로 동시 사용자 x 명까지 수용할 수 있는 시스템이다라는 가정을 검증하는 과정이다.
2 Web Application Stress Test Tool
A. ACT(Microsoft Application Center Test)
ACT(Microsoft Application Center Test)는 웹 어플리케이션에 대한 성능 테스트를 수행하고 관련 성능 정보를 수집하여 해당 웹 어플리케이션의 성능을 가늠해 볼 수 있게 해주는 툴이다 . 웹 어플리케이션이 이용되는 상황을 스크립트로 작성하여 시뮬레이션 할 수 있다.
n 스크립트 작성법
1. [시작] -> [ 프로그램] -> [Microsoft Visual Studio .NET] ->[ Visual Studio .NET Enterprise Features] -> [Microsoft Application Center Test] 를 선택하여 ACT를 시작한다.
2. [파일]->[ 새 프로젝트]를 선택하여 프로젝트 이름과 저장될 위치를 지정한다. 이름 : WooriBanca Stress Test , 위치 : \ WooriBanca\Stress Test\
3. 새로 생성된 프로젝트 폴더의 [ 테스트]에서 마우스 오른쪽을 눌러 [새 테스트 (N)…]를 선택한다. 5단계의 테스트 마법사가 실행된다.
4. 마법사 2 번째 단계 '테스트 원본 선택'에서 "새 테스트 기록하기"를 선택한다. 이는 매크로 기능처럼 사용자가 취한 행위를 vbs 스크립트로 자동 생성해준다. 4 번째 단계 '브라우저 기록'에서 "기록시작"을 누르면 신규 브라우저가 화면에 나타난다. 이 페이지에서 시작하여 우리은행 Bancassurance 의 특정 업무를 수행하는 과정을 실제 시뮬레이션 한다. 끝나면, 기록중지를 누른다. 테스트 명을 지정 (Woori Banca test)하고 마친다.
n 테스트 속성 설정
테스트 속성에는 일반 / 사용자 / 카운터 3개의 탭 페이지가 있다.
l 일반 : 테스트 회수 , 시간 등을 설정
Ø 테스트 로드 수준 브라우저 동시 연결 수 : ACT는 지정된 수만큼 동시에 브라우저 연결을 설정한다 . 실제 프로세스가 뜨는 것은 아니다.
Ø 테스트 지속 시간 : 지정한 시간 동안 반복적으로 테스트를 수행한다 .
Ø 지정한 횟수만큼 테스트 실행 : 실행시간에 상관없이 스크립트 수행을 지정된 회수만큼 수행한다 .
l 사용자 : 사용자 인증과 쿠키 처리 방식을 설정
l 카운터 : 테스트시 모니터링할 서버 , 클라이언트의 성능 카운터 설정
Ø 테스트 수행과정에서 서버 및 클라이언트에서 모니터링 할 카운터를 설정한다 .
Ø 원격 컴퓨터의 성능카운터를 확인하려면 관리자 권한이 있어야 한다 .
B. OpenSTA(Open System Testing Architecture)
OpenSTA(Open System Testing Architecture)는 WAE(Web Application Environment)하에서 동작하는 웹 서버, 어플리케이션 서버 및 데이터베이스 서버 등에 부하테스트를 수행할 수 있는 성능 테스팅 툴(Performance Testing Tool) 이다. 가상 유저(Virtual User) 를 이용한 실 사용자와 동일한 부하를 생성할 수 있고 생성된 스크립트의 결과 등 분석 자료를 추출할 수 있다. http://opensta.org/download.html 에서 프로그램을 다운로드 할 수 있고 http://portal.opensta.org/ 에서 필요한 기술 정보를 얻을 수 있다.
n 스크립트 작성법
1. [시작] -> [ 프로그램] -> [OpenSTA] -> [OpenSTA Commander]를 선택하여 OpenSTA 를 시작한다.
2. 아래의 그림의 메뉴를 이용해 새로운 테스트 스크립트를 생성하고 디폴트 이름을 적절하게 변경한다 .
3. 생성된 스크립트를 더블 클릭하여 나온 아래와 같은 화면에서 버튼을 클릭하여 브라우저를 통해서 테스트 시나리오를 레코딩한다.
4. 아래의 그림의 메뉴를 이용해 새로운 테스트를 생성하고 디폴트 이름을 적절하게 변경한다 .
5. 테스트를 더블 클릭하여 나타난 화면에 테스트하고자 하는 Script 를 끌어다 놓는다. 하나의 테스트에는 여러 개의 테스트 그룹이 포함될 수 있고 하나의 테스트 그룹에서는 순차적으로 실행되는 200개의 Script가 포함될 수 있다. 각각의 테스트 그룹별로 속성을 다르게 지정할 수 있다.
n 테스트 속성 설정
테스트 속성에는 VUs(가상 유저수 ) / Start(시작설정) 속성 등이 있다.
l VUs( 가상 유저수) : 스크립트를 실행하는 가상 유저수를 Task Group 별로 지정한다.
l Start( 시작설정) : 시작을 즉시할 것인지/ 스케줄을 사용할 것이지 등의 시작 설정과 반복 회수/ 실행 시간등을 지정한다.
C. ACT vs OpenSTA
|
| ACT | OpenSTA |
| 시나리오 | 단일 스크립트 방식 : 여러 개의 ACT를 동시에 실행할 경우 멀티 스크립트 가능 | 멀티 스크립트 방식 : 시나리오별 Virtual User 지정 가능 => 실제 사용 모습을 재현하는데 ACT에 비해서 용이 |
| 부하 단위 | 동시 브라우저 수 | Active Virtual User : 이해가 쉬움 |
| 분석 리포트 | 요약 / 페이지별 강력한 분석 보고서 | ACT에 비해서 취약 : HTTP Data를 분석할 수 있음 |
| 용도 | Capacity 측정을 위한 부하시 사용 적합 | Capacity 측정을 위한 부하 및 낱개 페이지별 Response Time 측정에 적합 |
| 개별 특성 | .vbs 파일 수정 가능 | 성능 테스트를 실행하는 클라이언트 리소스를 적게 사용(CPU 등 확인시) |
| Exchange 사서함 주소가 한글 사이트에 대해서 Auto recorded script를 일부 수정해 주어야 함 | www.openSTA.org 공개 소스 |
D. Performance Monitor( 성능 모니터)
n 성능 카운터 항목
l 클라이언트 사이드 : 성능 테스트를 수행하는 클라이언트에서 확인해야 할 내용 .
| 개체 | 성능 카운터 | 표시 내용 |
| Processor | % Processor Time/_Total | 테스트 클라이언트의 프로세서 사용 량이다. |
| Memory | Available Bytes | 테스트 클라이언트에서 사용할 수 있는 메모리의 양. |
| Network Interface | Bytes Total/sec | 테스트 클라이언트에서 또는 테스트 클라이언트로 이동하는 네트워크 소통 량. |
l 서버 사이드 : 성능 테스트를 수행하는 서버에서 확인해야 할 내용
| 개체 | 카운터 | 설명 | 해석 |
| .NET CLR Exceptions | # of Exceps Thrown | 응용 프로그램이 시작된 이후에 throw된 총 예외 수 이다. 이 값은 .NET 예외 및 .NET 예외로 변환되는 unmanaged 예외가 포함된 값 . 예: unmanaged code의 null 포인터 참조 예외는 managed code에서 .NET System.NullReferenceException으로 다시 throw된다. | 예외는 아주 드문 경우에만 나타나야 하며 프로그램의 정상적인 제어 흐름에는 존재하지 않는 것이 바람직. |
| Requests Queued | 처리 대기중인 요청수.. 이 숫자가 IIS 대기열 길이를 초과하면 "서버 사용량이 많습니다." 오류가 발생한다. | 이 숫자는 0에 가까워야 한다.1보다 큰 경우, Request Wait Time을 동시에 해석하여 큐 대기시간을 동시에 파악해야 한다 . | |
| Request Execution Time | 가장 최근 요청을 실행하는데 소요된 시간(ms) | 적은 값일수록 요청을 빨리 처리했다는 증거. | |
| Worker Process Restarts | 워커 프로세스(aspnet_wp.exe)의 재시작 회수. | 웨커 프로세스의 recycling 시 이벤트 로그에도 그 기록이 남는다. | |
| Appliacations | Requests/Sec | 초 당 실행되는 요청 수이다. | 시스템의 처리 능력을 가늠. |
| Internet Information Services Global | File Cache Flushes and File Cache Hits | 이 카운터를 비교하면 캐시 정리에 대한 적중률을 알 수 있다. 플러시는 파일이 캐시에서 제거될 때 발생한다. 이들 카운터는 개체가 캐시에서 플러시되고 있는 속도를 표시하고 있으며, 플러시가 너무 느리게 발생하면 메모리가 불필요하게 사용되는 것이다 . ObjectCacheTTL, MemCacheSize 및 MaxCacheFileSize 레지스트리 설정을 조정하면 이 값을 조정할 수 있다. |
|
| Internet Information Services Global | File Cache Hits % | 이 카운터는 총 캐시 요청에 대한 캐시 적중률을 표시. | 정적 페이지가 있는 사이트의 캐시 적중률은 약 80%이어야 한다. |
| Memory | Available Bytes | 이 숫자는 남아 있는 사용 가능한 실제 메모리의 양 표시함. |
|
| Memory | Cache Bytes | 정적 파일에 사용된 캐시 크기를 표시. 기본적으로 캐시 바이트는 사용 가능한 메모리의 약 50%로 설정되지만 사용 가능한 메모리가 감소하여 시스템 성능이 저하되면 더 낮게 설정된다. |
|
| Memory | Pages/sec | 서버의 메모리가 부족하여 서버의 작업 부하를 처리할 수 없으면 이 숫자는 지속적으로 올라갑니다. |
|
| Memory | Pool Paged Bytes and Pool Nonpaged Bytes | 풀에는 응용 프로그램과 운영 체제에서 만들고 사용한 개체가 저장됩니다. 풀이 채워지면 메모리 누실이 있을 수 있습니다. |
|
| Network Interface | Bytes Total/sec | 사용 가능한 대역폭과 이 값을 비교하면 발생할 수 있는 네트워크 병목 상태를 명확하게 표시할 수 있습니다. 일반적으로 바이트 수/초는 사용 가능한 총 대역폭의 50% 이하로 유지해야 합니다. |
|
| Object | Threads | Threads는 프로세서에서 명령을 실행할 수 있는 기본 실행 엔터티입니다. 이 숫자가 시간에 따라 계속 커지면 Process:Thread Count 카운터를 열어 모든 스레드를 만들고 있는 인스턴스를 확인합니다. |
|
| PhysicalDisk | % Disk time | 읽기/쓰기 작업을 하는 디스크의 경과된 시간을 비율로 표시합니다. 이 카운터 숫자가 높고 프로세서 및 네트워크 대역폭이 포화되어 있지 않으면 디스크 병목 현상이 발생할 수 있습니다. 이 카운터를 로깅하기 전에 Windows 2000 명령줄에서 "diskperf -yD"를 실행하십시오. 지속적으로 숫자가 80% 이상이면 메모리 누실을 나타내는 것일 수 있습니다. 다중 디스크 시스템에 대해 이 카운터의 0 인스턴스에서 x 인스턴스까지 추가하도록 합다. |
|
| PhysicalDisk | Disk Queue Length | 아직 해결되지 않은 요청 수를 디스크에 표시합니다. 한 디스크에 표시되는 대기열 길이가 지속적으로 3 이상이면 디스크, 메모리 또는 SQL Server 구성 문제를 나타냅니다. |
|
| Process | Private Bytes - _Total | 다른 프로세스와 공유할 수 없는 모든 인스턴스가 할당한 현재 바이트 수를 표시합니다. 목록에서 _Total 인스턴스를 선택합니다. 메모리를 모두 소모하고 있는 것으로 간주되는 다른 모든 인스턴스를 선택. |
|
| Process | Private Bytes(inetinfo 인스턴스) | Private Bytes(inetinfo)는 다른 프로세스와 공유할 수 없는 HTTP/ASP 서비스가 할당한 현재 바이트 수 입니다 . 이 숫자가 지속적으로 커지면 서버쪽 개체에 누실이 있을 수 있습니다. Process: Private Bytes(_Total)와 비교해야 한다. | COM+내 Server Type(dllhost.exe)의 카운터 값도 모니터링해야 한다 . |
| Process | Thread Count(inetinfo 인스턴스) | 웹 서버 프로세스에서 만든 스레드 수입니다. |
|
| Processor | % Processor Time(_Total 인스턴스) | 이 카운터를 통해 프로세서 포화 상태를 가장 잘 볼 수 있습니다. 모든 CPU에서 스레드를 처리하는 데 소비된 시간을 표시합니다. 하나 이상의 프로세서에서 숫자가 지속적으로 90% 이상이면 하드웨어에 대한 테스트가 지나치게 집중되어 있다는 것을 나타냅니다 . 다중 프로세서 서버에 대해 이 카운터의 0 인스턴스에서 x 인스턴스까지 추가하십시오. |
|
| Processor | Interrupts/sec | 프로세서 사용률이 90% 이상이고 인터럽트 시간 백분율이 15%보다 크면 프로세서는 지나치게 인터럽트됩니다. |
|
| Server | Bytes Total/sec | 네트워크 동작을 표시합니다. |
|
| System | Processor Queue Length | 이 카운터는 웹 서버의 모든 프로세서가 공유하는 대기열에서 실행 대기하고 있는 스레드 수를 표시합니다. | 프로세서 병목 상태가 되면 지속적으로 값이 2보다 커질 수 있습니다 . |
| System and Thread | Context Switches/sec, Context Switches/sec: dllhost(thread # instance) 및 Thread: Context Switches/sec: inetinfo(thread # instance) | 이들 카운터는 시스템 전체에서 발생하는 컨텍스트 전환 수와 IIS 5.0 내에서만 발생하는 컨텍스트 전환 수를 표시합니다. |
|
| Thread: | % Processor Time: InetInfo => Thread # | InetInfo 프로세스의 각 스레드가 사용하는 프로세서 시간을 나타냅니다. |
|
| Thread: | Context Switches/sec: InetInfo => Thread # | IIS 서비스의 스레드가 프로세서의 설정 또는 해제를 전환하는 횟수를 나타냅니다. |
|
| Web Service | Bytes Total/sec | 웹 서버에서 보내고 받은 바이트의 합계를 표시합니다. |
|
| Web Service | Current Anonymous Users | 인증되지 않은 스트레스 테스트 동안 서비스에 연결되어 있는 현재 연결 수를 표시합니다. |
|
| Web Service | Current Connections | HTTP 서버에 현재 연결되어 있는 인증된 사용자 수입니다. | Current Non-Anonymous Users 수와 동일. |
| Web Service | Not Found Errors | 반환된 404 응답 코드 수를 표시합니다. |
|
n 성능 모니터 사용 권고 사항
l 최대 4시간까지 모니터링하는 경우 모니터링 빈도는 15sec(Default)을 유지한다. 8시간이상 모니터링하는 경우 시스템의 Overhead를 줄이기 위해 300sec(5분)이상으로 설정한다.
l 모니터링 주기는 15분을 기본으로 한다.
3 Web Application Stress Testing
A. 스트레스 테스트 계획
n 테스트 목적 설정
l 사용자 임계치 정의
예) 급여오픈시 3,000 User가 30분간 집중적으로 로그인함
예) 출근 직후 혹은 퇴근 직전 1시간동안 1,000 User가 집중적으로 로그인 후 보험 실적 입력
예) 동시 사용자 200 User가 3초안에 로그인 할 수 있도록
n 테스트 환경 설정
l L4 Switch의 Balancing Algorithm을 고려하여 각 서버 그룹을 1 대를 대상으로 할 것인지 서버 그룹 내 2대의 서버를 모두 대상으로 할 것인지 등을 결정
예) 사용자 요구 사항이 동시 사용자 200 User 일 때 전체 Web/App 서버가 4대로 구성될 경우 한 서버에 동시 사용자 50 User를 테스트, Web/App 서버 이후의 Back-End 서버는 모두 정상 가동
l 스트레스 테스트에 사용되는 데이터베이스를 테스트 환경에 맞추어 설정한 후 반복적인 테스트에 쉽게 대응할 수 있도록 백업하거나 원상 복구용 스크립트를 작성해 주는 것이 좋다.
n 테스트 시나리오 정의
l 테스트 시나리오 범위
Ø 전체 시스템 중 다른 서버와의 연계 및 시스템의 핵심 기능, 성능에 영향을 미칠 것으로 보이는 모든 접점을 범위로 하여 시나리오 구성 : 로그인, 게정계와의 연동, 타보험사와의 연동 등
l 테스트 시나리오 정의 예
Ø 로그인 (동시 사용자 200명) : 동시 사용자 200명 로그인 테스트
Ø 로그인 -> 계정계와의 연동(동시 사용자 100명) : 동시 사용자 100명으로 로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 100명의 동시 사용자를 [로그인 -> 계정계와의 연동] 테스트
Ø 로그인 -> 타보험사와의 연동(동시사용자 50명) : 동시 사용자 100명으로 로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 50명을 [로그인 -> 계정계와의 연동] 시나리오로 부하를 준다. 이 상태에서 다시 50명의 부하를 [로그인 -> 타보험사와의 연동]에 가한다.
B. 스트레스 테스트 실행
n System Performance( 응답시간 )
l 현상계 사용 시나리오에 준해서 OpenSTA로 부하를 가하고 ACT를 이용해서 Performance에 대한 보고서를 얻어낸다 .
예) 로그인 -> 타보험사와의 연동(동시사용자 50명)
[OpenSTA]
Ø 로그인 : 동시 사용자 100명 부하
Ø 로그인 -> 계정계와의 연동 : 동시 사용자 50명 부하
Ø 로그인 -> 타보험사와의 연동 : 동시 사용자 50명 부하
[ACT]
Ø 로그인 -> 타보험사와의 연동 : 동시 브라우저수 1개로 부하를 가하면서 Performance 보고서를 취득
n System Capacity( 용량 )
l 성능 모니터를 이용한 성능 카운터(메모리, CPU, 디스크, 프로세스 등)를 이용해서 보고서를 얻어낸다 .
C. 스트레스 테스트 분석
n 테스트 결과 분석 가이드
l 테스트 결과에서 많은 양의 에러(응답 코드 200번 보다 큰 응답 코드)를 발견할 경우, 에러 발생 지점은 성능이나 병목 이슈의 후보가 될 수도 있다.
l 스트레스 테스트 도구들은 Ramping Up 스트레스를 준다 . 즉, 처음에는 부하의 수준을 조금 주다가 시간이 흐를수록 부하의 수준을 늘려가게 된다. 시스템에 어느 정도의 부하에서 테스트가 실패하는지도 살펴볼만한 요소가 되나.
l 시스템의 성능의 관점에서 RPS(Request Per Second)의 값은 서버의 Capacity와 테스트 시나리오에 모두 관련이 있다. RPS값은 테스트 시나리오의 복잡성, 서버의 Capacity와 관련이 있으므로 절대적인 응답시간이나 Capacity 의 기준으로 간주해서는 안되며 하나의 참조자료가 될 수 있다.
l 시나리오의 응답시간은 ACT의 결과인 " 반복 당 평균 TTLB(밀리초)"가 좋은 척도가 된다.
l 부하분석 결과 예)
| 부하 시나리오 | 서버용량 | 응답속도 | ||||||
| 시나리오 |
| CPU% | RPS | Queue | CC | 평균(Sec) | 최소 | 최대 |
| 로그인 | 10 | 10 | 6 | 0 | 24 | 5.67 | 4.00 | 9.00 |
| 20 | 19 | 12 | 0 | 49 | 5.57 | 4.00 | 7.00 | |
| 50 | 34 | 28 | 0 | 113 | 5.71 | 4.00 | 11.00 | |
| 75 | 58 | 43 | 0 | 188 | 5.61 | 4.00 | 10.00 | |
| 100 | 84 | 50 | 1 | 235 | 7.08 | 4.00 | 12.00 | |
| 125 | 86 | 54 | 1 | 350 | 8.33 | 4.00 | 14.00 | |
| 150 | 86 | 54 | 1 | 349 | 12.00 | 4.00 | 20.00 | |
| 200 | 92 | 51 | 3 | 450 | 16.24 | 5.00 | 28.00 | |
| 300 | 91 | 48 | 20 | 672 | 31.24 | 6.00 | 46.00 | |
Ø 위의 로그인 프로세스의 경우 동시 사용자 100명일 경우가 현재 시스템이 커버할 수 있는 최대수로 보여진다 . 100명일 경우와 150명일 경우 CPU 평균 사용량(84~86)과 RPS(50~54)등이 모두 비슷하지만 응답시간의 경우 많은 차이 (7.08~12.00)를 보인다. 따라서 시스템이 커버할 수 있는 적정 동시 사용자수는 100명으로 볼 수 있다.
l 부하 테스트의 결과 현재의 시나리오에서 시스템이 커버할 수 있는 동시 사용자수와 응답 속도가 사용자의 요구에 만족스럽지 않을 경우
Ø ACT 의 페이지별 TTLB를 확인하여 오래 걸리는 페이지에 대한 추가적인 조사 작업을 수행
Ø OpenSTA 의 결과인 HTTP Data List의 데이터를 이용하여 특정 시나리오내의 구간을 정의하여 구간별 응답시간을 상세히 분석해 볼 수 있다(수작업 필요).
Ø 다른 요소(Database 등) 에 성능상의 문제가 없는지 확인.
피드 구독하기:
글 (Atom)