Vista를 구입한지 얼마 되지 않은 사람들 에겐 좋은 소식으로 들리지 않을 듯.

두 번째 코드테스트 버전인 M2를 오는 4월이나 5월중에 발표할 것으로 보이며, M3 버전은 2008년 3/4분기에 나올 전망.

Windows7은 약 3년의 개발 기간을 거쳐 2010년경 공급될 것으로 예정 되어 있었으나, 당초 계획보다 좀 더 시기를 앞당겨 2009년 후반 정식 제품으로 출시될 가능성이 높아졌다고 한다.

웹기반 표준기술인 웹서비스 기술을 활용하여 새로운 비즈니스를 창출한다는 측면에서 SOA는 최근 화두가 되고 있는 웹 2.0과 매우 유사한 특징을 지니고 있다.

마이크로소프트 아키텍쳐 전략 담당관인 John de Vados는 웹 2.0과 SOA의 개념과 주요 특성을 비교하면서 현재 웹 2.0은 소비자 중심 비즈니스 모델을 지원하고, SOA는 기업 중심 모델을 지원하고 있다고 보고 있다. 그리고 미래 비즈니스 세계는 이 둘간의 구분이 모호해지고 연계가 활발해짐에 따라, 궁극적으로 웹 2.0이 글로벌 차원의 SOA를 실현할 수 있을 것으로 전망하고 있다.

세상은 넓고, 사람은 많고, 기술은 끝없이 바뀐다.
아무리 어려운 난관에 부딪혀도 반드시 방법이 있음을 믿고,
아무리 하찮은 적이라도 우리와 다른 기술을 가지고 있을지도 모른다는 점을 한시도 잊지 말라.

내가 최고라도 자만하지 말라.
옆을 보고, 앞을 보고, 뒤를 보아라.
산을 넘고, 강을 건너고, 바다를 건너라.

세상을 살되 한 뼘이라도 더 넓게 살고,
사람을 사귀되 한 명이라도 더 사귀며,
기술을 배우되 한 가지라도 더 배워라.

상대가 강하면 너희를 바꾸고,
너희가 강하면 상대를 바꾸어라.

1. 사용자 등록정보 바꾸기

  경로 : HKey_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion

  수정 : [RegisteredOwner] 값 수정, [RegisteredOrganization] 값 수정

2. 휴지통 이름 바꾸기

경로 : HKey_Classess_Root\Clsid\{645FF040-5081-101B-9f08-00AA002F954E}

수정 : [기본값] 수정, [LocalizedString]의 데이터 뒤에 쉼표 입력

3. 작업 표시줄의 시간 표시 바꾸기

경로 : HKey_Current_User\Control Panel\International

수정 : [s1159] 값을 ‘낮’으로 수정, [s2359] 값을 ’밤’으로 수정

4. 인터넷 익스플로러의 제목 표시줄에 문구 넣기

경로 : HKey_Current_User\Software\Microsoft\Internet Explorer\Main

수정 : [Window Title]키의 데이터를 원하는 문자로 수정

5. 인터넷 익스플로러의 툴바에 그림 넣기

경로 : HKey_Current_User\Software\Microsoft\Internet Explorer\Toolbar

수정 : [Backbitmap] 값의 데이터에 삽입할 비트맵(bmp) 파일 경로 및 이름 입력

1. Cookie 개요 

Cookie는 사용자가 방문한 웹 사이트에서 추후에 어떤 용도로든 사용하기 위해서 사용자의 하드디스크에 남기는 정보를 의미한다. 예를 들어 사용자가 특정 팝업창에 대해 "더 이상 띄우지 않음", "오늘은 띄우지 않음" 등과 같은 체크 박스를 선택할 경우 다음부터 해당 사이트에 방문할 때 더 이상 그런 팝업창이 나타나지 않게 되는데 이는 Cookie 정보가 사용자의 PC에 저장되어 있기 때문이다. 엄밀히 말하자면 이런 Cookie는 Persistent Cookie라고 불리우며 메모리 공간에 상주하여 브라우저 관련 프로세스가 실행되고 있을 때까지만 유효한 Cookie 정보도 있는데 이를 Non-Persistent Cookie 혹은 Session Cookie라고 부른다.

2. Cookie 종류 

Cookie의 종류에는 Persistent Cookie와 Session Cookie(Non-Persistent Cookie)가 있다. 이 두 개를 비교하면 다음과 같다. 

3. Cookie 동작 원리 

클라이언트가 웹서버에 접속할 때 Cookie가 어떤 식으로 교환되는지 살펴보기로 하자.
우 선 클라이언트가 해당 서버에 대한 Persistent Cookie를 저장하고 있다면 저장하고 있는 Cookie 정보가 만료되었는지 여부를 확인하여 만료되지 않았다면 해당 Cookie 정보를 보낸다. 이 정보는 Request Header에 포함되어 전달된다. 

From. marga

여기에 정리 된 내용은 출처에서 간추린 내용이며, 출처 사이트로 가면 이미지와 함께 좀더 자세히 이해 할 수 있을 것 이다.

매우 좋은 내용의 글 이므로 원문을 꼭 읽어볼 것을 추천한다.

원문  http://blog.naver.com/arternis74?Redirect=Log&logNo=150017024791

외국사이트에 가입할때면 주소 기입이 간혹 난감해진다.

로마표기법에 따른 한글 치환 프로그램을 하나 만들까 했더니 이미 해논곳이 있어서 링크를...ㅋ

언어닷컴 주소 변환기 : http://archive.eoneo.com/lang/en/freezone/addressConverter/

'서울시 개똥이네'를 변환하면...

'Gaettongine Seoul S.KOREA' 이렇게 변환해준다.

편하다. 변환 표기가 좀 아니다 싶을때도 있지만, 큰 문제는 없다.

Rails를 사용하는 사람들은 아파치 웹 서버와 CGI. 성능에 문제가 많은데 그런 부분을 보완한 Lighttpd + FCGI 조합을 많이 쓰인다. 그리고 무엇보다 Lighttpd에 열광하는 이유는 기본으로 제공되는 안정적인 fastcgi 모듈이다. 이 모듈이 아파치의 mod_fastcgi보다 빠르고 안정적이라는 사실은 모두가 인정하고 있다.
Lighttpd + Pound + Mongrel 이 조합도 좋아 보인다. 그래서인지 앞으로는 Lighttpd의 사용률이 많이 올라가지 않을까 생각해본다.

1. Activity Diagram 개요

    ① 정의 : 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 모델

    ② 작성목적

        * 처리순서 표현 (대상에 관계없이..)

        * 비즈니스 프로세스 정의(이 용도로 가장많이 사용됨) : 업무의 As-is분석, To-be 분석 가능

        * 프로그램 로직 정의 : 처리흐름의 도식화로 프로그램 로직 정의 가능

        * 유즈케이스 실현

    ③ 작성시기 : 그 시점이 한정되어 있지 않고 다양하게 사용 가능

        * 업무 프로세스 정의 시점.

        * 유즈케이스 정의서 작성 시, 처리절차 기술할 때

        * 오퍼레이션 사양 정의시

    ④ 작성순서

        * 작성대상 선정 : 업무프로세스 모델링, 오퍼레이션 사양 정의

           ↓

        * Swim lane 정의 : 대상영역에 명확한 역할을 정의해야 할 때.

           ↓

        * 처리절차 모델링 : 시작점, 끝점 반드시 표현.

2. Activity Diagram 구성요소

    ① Things

        * Activity : 행위나 작업 ( 내부적으로 구조를 가지는 단위

              ex) 상품조회, 구매결정, 결재내용입력, 결재자지정....

        * Initial State : ●         * Final State : ⊙

        * Decision(Branch) : ◇

        * Synchronization bar : 병렬처리절차가 시작되거나 모이는 지점

            ex)

    ② Relationship

        * Transition(전이) : 하나의 액티비티가 행위를 완료하고 다른 액티비티로 처리순서가 옮겨

    ③ Swim lane : 하나의 처리를 구분지음.

3. Activity Diagram 사례

    ① SCM 시스템의 일반 정보에 대한 Role 액티비티 다이어그램

        * AS-IS

        * TO-BE

         → 모든 사용자에게 일반정보를 제공했던 것을 등록여부와 거래품목 등록여부 확인 후

             등록된 사용자에게만 일반정보 제공.

    ② 프리즘에서 유지보수 절차 프로세스를 정의한 액티비티 다이어그램

목 차

1    Web Application Stress Test Overview.

2    Web Application Stress Test Tool

A.   ACT(Microsoft Application Center Test)

?    스크립트 작성법..

?    테스트 속성 설정..

B.   OpenSTA(Open System Testing Architecture)

     ?    스크립트 작성법..

?    테스트 속성 설정..

C.   ACT vs OpenSTA.

D.   Performance Monitor(성능 모니터)

?    성능 카운터 항목..

?    성능 모니터 사용 권고 사항..

3    Web Application Stress Testing.

A.   스트레스 테스트 계획..

?    테스트 목적 설정..

?    테스트 환경 설정..

?    테스트 시나리오 정의..

B.   스트레스 테스트 실행..

?    System Performance(응답시간)

?    System Capacity(용량)

C.   스트레스 테스트 분석..

?    테스트 결과 분석 가이드..

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

D.    Performance Monitor(성능 모니터)

n        성능 카운터 항목

l        클라이언트 사이드 : 성능 테스트를 수행하는 클라이언트에서 확인해야 할 내용.

l        서버 사이드 : 성능 테스트를 수행하는 서버에서 확인해야 할 내용

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      부하분석 결과 예)

Ø        위의 로그인 프로세스의 경우 동시 사용자 100명일 경우가 현재 시스템이 커버할 수 있는 최대수로 보여진다. 100명일 경우와 150명일 경우 CPU 평균 사용량(84~86)과 RPS(50~54)등이 모두 비슷하지만 응답시간의 경우 많은 차이(7.08~12.00)를 보인다. 따라서 시스템이 커버할 수 있는 적정 동시 사용자수는 100명으로 볼 수 있다.

l      부하 테스트의 결과 현재의 시나리오에서 시스템이 커버할 수 있는 동시 사용자수와 응답 속도가 사용자의 요구에 만족스럽지 않을 경우

Ø        ACT의 페이지별 TTLB를 확인하여 오래 걸리는 페이지에 대한 추가적인 조사 작업을 수행

Ø      OpenSTA의 결과인 HTTP Data List의 데이터를 이용하여 특정 시나리오내의 구간을 정의하여 구간별 응답시간을 상세히 분석해 볼 수 있다(수작업 필요).