1.너니나야 이야기

You can provide hints to give the optimizer information about how to choose indexes during query processing. Section 12.2.7.1, “JOIN Syntax”, describes the general syntax for specifying tables in a SELECT statement. The syntax for an individual table, including that for index hints, looks like this:

(Language : sql)

tbl_name [[AS] alias] [index_hint]

index_hint:
    USE {INDEX|KEY} [FOR JOIN] (index_list)
  | IGNORE {INDEX|KEY} [FOR JOIN] (index_list)
  | FORCE {INDEX|KEY} [FOR JOIN] (index_list)

index_list:
    index_name [, index_name] ...

 

By specifying USE INDEX (index_list), you can tell MySQL to use only one of the named indexes to find rows in the table. The alternative syntax IGNORE INDEX (index_list) can be used to tell MySQL to not use some particular index or indexes. These hints are useful if EXPLAIN shows that MySQL is using the wrong index from the list of possible indexes.

You can also use FORCE INDEX, which acts like USE INDEX (index_list) but with the addition that a table scan is assumed to be very expensive. In other words, a table scan is used only if there is no way to use one of the given indexes to find rows in the table.

USE KEY, IGNORE KEY, and FORCE KEY are synonyms for USE INDEX, IGNORE INDEX, and FORCE INDEX.

Each hint requires the names of indexes, not the names of columns. The name of a PRIMARY KEY is PRIMARY. To see the index names for a table, use SHOW INDEX.

Index hints do not work for FULLTEXT indexes.

USE INDEX, IGNORE INDEX, and FORCE INDEX affect only which indexes are used when MySQL decides how to find rows in the table and how to do the join. They do not affect whether an index is used when resolving an ORDER BY or GROUP BY clause. As of MySQL 5.0.40, the optional FOR JOIN clause can be added to make this explicit.

Examples:

(Language : sql)

SELECT * FROM table1 USE INDEX (col1_index,col2_index)
  WHERE col1=1 AND col2=2 AND col3=3;

SELECT * FROM table1 IGNORE INDEX (col3_index)
  WHERE col1=1 AND col2=2 AND col3=3;

1. 테이블에 새로운 컬럼 추가

alter table tablename add column [추가할 컬럼명] [추가할 컬럼 데이타형]

2. 테이블에 컬럼타입 변경하기

alter table tablename modify column [변경할 컬럼명] [변경할 컬럼 타입]

3. 테이블에 컬럼이름 변경하기

alter table tablename change column [기존 컬럼명] [변경할 컬럼명] [변경할 컬럼타입]

4. 테이블에 컬럼 삭제하기

alter table tablename drop column [삭제할 컬럼명]

5. 테이블컬럼에 인덱스 주기

alter table tablename add index 인덱스명(인덱스를 줄 컬럼1 , 인덱스를 줄 컬럼2, ... )

6. 테이블컬럼에 인덱스 삭제하기

alter table tablename drop index 인덱스명;

7. 테이블에 Primary Key 만들기

alter table tablename add primary key (키를 줄 컬럼명1 , 키를 줄 컬럼명2, ...)

8. 테이블에 Primary Key 삭제하기

alter table tablename drop primary key;

9. 테이블명 바꾸기

alter table 기존테이블명 rename 새로운테이블명

10. 인덱스 생성

CREATE [UNIQUE] INDEX index_name ON tbl_name (col_name[(length]),... )

11. 인덱스 삭제

DROP INDEX index_name

 

CMT를 사용하지 않고 iBATIS의 트랜잭션을 이용해 수동으로 트랜잭션 관리를 하고 있었다.

그런데 JBOSS에서는 CachedconnectionManager란 녀석이 친절하게 Connection leak을 방지하기 위해 Connection을 끊어준다.
(JBOSS 입장에서는 iBATIS의 connection관리 행위를 이해하지 못하므로)

그래서 답은 CMT를 사용하거나, 해당 기능을 사용하지 않으면 된다는 것이다.
물론 그로인해 Connection leak에 대한 책임이 WAS에게서 개발자로 넘어오게 되긴 하지만 말이다.

참고글에서는 persistant framework 을 믿고 해당 기능을 끄라는데, 왠지 찜찜하다.

다음은 원글이다.

What does the message "Closing a connection for you" mean?

It means you are not closing your connections to return them to the pool. To avoid connection leaks you should have code like the following:

Connection connection = dataSource.getConnection();
try
{
// DO WORK
}
finally
{
   try
   {
       connection.close();
   }
   catch (Throwable ignored)
   {
   }
}

For jdbc you should do the same thing for Statements and ResultSets. Normally Statements are closed when the Connection is closed, but connection pooling means the close does not happen. Similarly, if you have prepared statements in a cache, ResultSets need to be closed.

Thread Local Patterns

Many persistent frameworks (hibernate/ojb) open and close connections "at random". i.e. As far as JBoss is concerned it looks like one ejb allocated the connection and another closed it.

The connection close checking does not understand this behaviour. It expects the same ejb that allocated the connection to also close it.

If you use such a pattern, you can turn off this message (see below) but you are on your own when it comes to detecting connection leaks. From 3.2.6 there is a "listInUseConnections" on the CachedConnectionManager. However, there is this known issue with some transacion demarcation semantics. This is not really a JBoss use, more that ThreadLocal patterns bypass J2EE semantics. If you do hit the problem removing the CachedConnectionInterceptor from the conf/standardjboss.xml will workaround the spurious message. You can trust hibernate at least to close connections properly provided you are ending user transactions correctly.

Turning off Connection Close Checking

In production you don't need this checking. Hopefully you have found all the connection leaks during development. You can turn it off on the CachedConnectionManager.

• transaction-service.xml for 3.2.x
• jbossjca-service.xml for 4.x

Change "Debug" to false.

  <mbean code="org.jboss.resource.connectionmanager.CachedConnectionManager" 
         name="jboss.jca:service=CachedConnectionManager">
    <depends optional-attribute-name="TransactionManagerServiceName">jboss:service=TransactionManager</depends>

    <!-- Enable connection close debug monitoring -->
    <attribute name="Debug">false</attribute>

Related

<datasources>
  <local-tx-datasource>
    <jndi-name>jdbc.dsCizle</jndi-name>
<connection-url>jdbc:mysql://xxx.xxx.xxx.xxx:3306,xx2.xx2.xx2.xx2:3306/ticketbox?failOverReadOnly=false</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>xxxx</user-name>
    <password>xxxx</password>
    <min-pool-size>10</min-pool-size>
    <max-pool-size>100</max-pool-size>
    <blocking-timeout-millis>5000</blocking-timeout-millis>
    <idle-timeout-minutes>15</idle-timeout-minutes>

<check-valid-connection-sql>select '1'</check-valid-connection-sql>
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
  </local-tx-datasource>

</datasources>

1. JMeter의 소개

JMeter는 Apache Jakarta 프로젝트의 일환으로 만들어진 테스트 기능과 퍼포먼스를 측정하는 애플리케이션이다. 이 애플리케이션 100% 순수 자바로 작성되었으며 원래 웹 애플리케이션을 위해 디자인되고 사용되었으나 현재는 다른 기능의 테스트를 위해 확장되고 있다.

JMeter는 static, dynamic 한 모든 자원(파일, 서블릿, perl script, java object, database and query, ftp, soap 등)에 대해 퍼포먼스를 테스트할 수 있다. 이러한 테스트 결과로 분석결과를 그래픽으로 표시해주는 기능과 스크립트 객체 등에 대해 과도한 동시 처리 부하가 가능하다.

Apache Jmeter는 다음 사이트에서 얻을 수 있다.

http://jakarta.apache.org/jmeter/

JMeter에 대한 추가 정보는 위 사이트에서 얻을 수 있다. 한데 위 사이트는 영어로 구성되어 있기 때문에 조금 빈약하더라도 한국어로 된 정보는 자카르타 서울 프로젝트에서 얻을 수 있다.

http://jakarta.apache-korea.org

2. JMeter를 얻고 설치하기

JMeter를 설치 하기 위해서 우선 Jakarta 의 JMeter 사이트에 접속한다. 다음 그림들은 Jakarta 메인 사이트와 JMeter 사이트를 보여준다.


[그림 2-1] Jakarta 사이트


[그림 2-2] Jakarta JMeter 사이트

JMeter를 다운로드 받기 위해선 화면 왼쪽의 Download Binary 링크를 통해 들어가면 다운로드 받을 수 있다.


[그림 2-3] Jakarta 다운로드 링크 페이지

Jakarta 프로젝트는 다수의 서브 프로젝트들로 이뤄져 있기 때문에 실제적인 다운로드는 Downloads 섹션의 Jmeter를 클릭하면 다운로드 받을 수 있게 된다. [그림 2-3]은 그 화면을 나타낸다.


[그림 2-4] Mirror 페이지

[그림 2-3]에서 JMeter 를 클릭하면 곧 바로 다운로드를 시작하지는 않고 어디서 다운로드 받을지 물어오게 된다. 본 문서에서는 미러 사이트로 한국 아파치 사용자 모임을 선택했다. [그림 2-4]에 보이는 빨간 박스를 클릭하면 미러 사이트가 나타나게 된다. 미러 사이트를 선택했다면 Change 버튼을 눌러 미러 페이지를 변경시킨다.

미러 사이트는 다수가 존재하는데 다운로드 속도가 느릴 경우 바꿔가며 시도해본다. 일반적으로 기본적으로 선택되는 미러 사이트를 이용해도 된다.


[그림 2-5] JMeter 다운로드 링크

[그림 2-4]의 화면에서 미러 사이트를 변경하지 않았거나 변경한 경우 화면 스크롤을 내리면 빨간박스로 그려진 부분 2.3.1.zip 부분을 볼 수 있다. 이 부분을 클릭하면 본격적인 다운로드 윈도우를 볼 수 있다.


[그림 2-6] 파일 저장 윈도우

[그림 2-6]에서 보여지는 윈도우는 파일을 어디에 저장할 것인지를 물어오는 화면이다. 본문에서는 바탕 화면에 저장하였다.


[그림 2-7] 바탕화면에 저장된 JMeter 파일

[그림 2-6]에서 바탕 화면에 저장된 파일은 [그림 2-7]과 같다.


[그림 2-8] JMeter 실행 파일

JMeter는 Java Application 이기 때문에 별도의 설치 프로그램을 필요로 하지 않는다. 본문에서는 압축파일을 선택한 후 바탕 화면 폴더에 압축 내용을 별도의 폴더 생성 과정 없이 풀었다. 이렇게 푸는 이유는 JMeter 압축파일이 별도의 상위 폴더를 가지고 있기 때문이다. [그림 2-8]은 그런 화면을 나타낸다.

JMeter의 실행은 [그림 2-8]에 보이는 것처럼 jmeterw.cmd 파일을 더블 클릭하면 실행한다.


[그림 2-9] JMeter의 실행 화면

3. JMeter 기본 과정

JMeter는 테스트 환경에 있어 상위 항목으로 WorkBench와 Test Plan를 두고 있다. 이 상위 항목을 다른 이름으로 노드라고 표현한다. 노드라는 단어는 Tree에서 비롯되었는데 JMeter는 각각의 element를 계층적으로 관리 하기 위해서 Tree 구조를 사용한다. JMeter는 테스트 앞서 Test Plan을 먼저 작성하게 된다. Test Plan은 한국어로 풀어 쓰면 테스트 계획인데 JMeter의 모든 Test는 이 Test Plan을 먼저 세워야 한다.

Test Plan  + HTTP TestWorkBench

[모식도 3-1] JMeter 모식도

[모식도 3-1]은 위에서 설명한 구조를 간략히 그려내 본 것이다. JMeter는 Test Plan과 WorkBench 아래에 놓이는 것을 가리켜 Element라고 한다. 한국어로는 요소라는 말이 적절하겠지만 이해를 돕기 위해 원어로 표기한다. Element는 여러 종류가 있는데 Test Plan에 바로 올 수 있는 Element는 다음과 같은 것들이 있다.


[그림 3-1] Test Plan 에 추가될 수 있는 element

[그림 3-1]은 Test Plan 노드 아래 추가될 수 있는 element를 나타내고 있는데 기본 테스트를 하기 위해선 Thread Group과 Listener 의 추가가 우선적이다. Thread Group는 테스트의 가장 기본적인 요소로써 Test Plan 노드 아래 몇 개든 올 수 있다. Thread Group은 논리적인 모습으로 표현하면 테스트 클라이언트들의 묶음이라고 보는 표현이 타당하다.

JMeter는 단지 Thread Group을 구성하는 것만으로 결과를 볼 수 없다. 이 뚱딴지 같은 이야기는 JMeter가 결과를 보기 위한 또 다른 구성 요소를 필요로 한다는 것이다. JMeter는 테스트 결과를 다양한 형태로 볼 수 있도록 다음과 같은 구성 요소를 지원한다.


[그림 3-2] Listener의 구성 요소

[그림 3-2]에 보이는 element 중 가장 많이 사용되는 요소는 Graph Results, Summary Report, View Results in Table, View Results Tree다.

다시 앞으로 돌아가서 Thread Group은 테스트에 있어서 기본적인 단위가 된다고 했다. 이제 Thread Group 아래 다른 element를 추가할 필요가 있다.

Test Plan 노드에 Thread Group을 추가한 후 마우스 오른쪽 클릭을 통해 보면 [그림 3-1]에서 보던 것과 비슷한 화면이 보이는데 하나 더 추가된 element 그룹이 존재한다.


[그림 3-3] Thread Group에서의 마우스 오른쪽 팝업

[그림 3-3]에는 Sampler 그룹이 보이는데 바로 이 그룹이 JMeter 테스트에 있어서 실제로 부하를 보내는 실제적인 주체가 들어 있는 그룹이다. Sampler는 다양한 element가 들어가 있는데 대표적으로 다음과 같은 sampler 항목을 들어볼 수 있다.


[그림 3-4] 많이 쓰이는 Sampler

Sampler는 위의 그림에 보이는 것보다 더 많지만 기본적인 기능 테스트 및 웹 애플리케이션 테스트에는 [그림 3-4]에 있는 Sampler가 더 많이 쓰인다.

본문에서는 HTTP Request Sampler에 대해서만 집중적으로 다룰텐데 다른 Sampler에 대해선 다른 기회가 주어진다면 하나씩 파보는 기회를 가져보도록 하겠다.

Thread Group에는 Sampler 뿐 아니라 다른 element들도 추가가 가능한데 이들 element에 대해서도 다른 기회가 주어졌을 때 파보는 기회를 가져보겠다.

자 이제까지 설명한 것은 JMeter에서 스트레스 테스트를 하기 위한 기본 구조를 설명하였다. [그림 3-5]는 지금까지 설명한 구조를 실제로 구현한 JMeter의 Test Plan 의 모습이다.


[그림 3-5] 간단한 Test를 위한 Test Plan

다음 섹션에서는 [그림 3-5]를 기반으로 한 Simple한 Test를 진행해보겠다.

4. JMeter를 사용한 Simple Test

지금까지 간략히 JMeter의 테스트 계획에 대해서 알아보았는데 본 섹션에서는 앞에서 다루었던 Test Plan에 실제 숨을 불어넣어 본다.

본문에서는 저자가 운영진으로 활동하고 있는 한국 아파치 사용자 모임 사이트를 대상으로 삼았다. 우선 HTTP Request 노드를 선택하면 JMeter 의 오른쪽 화면이 바뀌면서 [그림 4-1]처럼 나타나게 된다.


[그림 4-1] HTTP Request 선택

[그림 4-1]에는 빨간 박스가 다수 보이는데 이 박스 안의 내용을 입력하거나 선택함으로서 테스트 정보를 입력한다.

첫번째 입력할 정보는 테스트할 서버의 IP 또는 URL을 입력하는데 URL은 프로토콜 정보를 제외한 순수 주소만 적는다. 다음과 같은 URL이 테스트할 정보라고 보고 Server Name을 분리하자.

http://www.apache-kr.org/www/board.php?cmd=retrieveContent&board_cd=techtalk&rg_d=20080410&rg_seq_n=1&pageID=1&search_gb=&fr_rg_d=&to_rg_d=&searchstring=
Server Name은 www.apache-kr.org가 되어야 한다.

두번째 입력하고 선택할 정보는 Method와 Path인데 이 정보는 실제로 테스트할 URL 정보가 들어간다.

Path는 실제 테스트할 URL을 말하는데 / 로부터 시작하고 인자가 시작되기 전까지의 정보를 적는다. 앞에서 언급된 URL을 기준으로 path는 아래와 같이 분리된다.

/www/board.php

위에서 나타난 파일이 어떤 인자를 받는다면 그 인자 방식을 Method에서 선택해준다. 여러 Method를 사용할 수 있지만 웹 애플리케이션은 일반적으로 GET 방식과 POST 방식을 사용한다. 예제로 쓰는 URL은 모든 정보를 GET 방식으로 던진다. 따라서 Method는 GET으로 지정한다. 물론 인자를 받지 않는다면 Parameter 정보를 입력하지 않아도 된다.

HTTP Request 노드의 Method 기본값은 GET이기 때문에 혹시 GET이 아니면 수정해주도록 한다. Add 버튼을 클릭하면 파라메터 정보를 입력받게 된다.

본문에서는 Add 버튼을 5번 눌러 파라메터 입력을 5개 만들었다. 입력할 파라메터는 다음 목록과 같다.

cmdboard_cdrg_drg_seq_npageID

서버 정보 및 파라메터 정보를 모두 입력한 화면은 [그림 4-2]와 같다.


[그림 4-2] 테스트 정보를 모두 입력한 화면

HTTP Request 정보를 모두 입력했다면 Thread Group에 관한 설정을 할 차례다. JMeter의 왼쪽 트리에서 Thread Group 노드를 선택하면 [그림 4-3]과 같은 화면이 나타난다.


[그림 4-3] Thread Group 정보 입력

[그림 4-3]에 보이는 Thread Group 정보는 몇가지 예의 주시해서 입력해야 할 정보가 있다.

첫번째 박스는 몇 명의 사용자로 동시 접속 부하를 줄것인지에 대한 것인데 사용자명을 높게 지정할수록 서버의 부하 테스트도 더 커진다.
두번째 박스는 한명의 사용자가 접속자가 서버로 부하를 주러 떠나고 다른 사용자가 부하를 주러 떠날 때 사용자간의 접속 시간을 지정한다. JMeter 문서에는 쓰레드의 생성 주기를 나타낸다고 하지만 이해를 돕기 위해서 사용자간의 접속 시간으로 보면 된다.

세번째 박스는 Thread Group에 속해있는 Sampler들을 몇번 보낼 것인지 지정한다. 이해가 어렵다면 HTTP Request에서 지정했던 URL을 Loop Count 에 지정한 숫자만큼 다시 서버에 요청을 한다고 이해하면 된다. 만약 Forever 박스를 체크했다면 JMeter 실행자는 JMeter를 수동적으로 정지시켜줘야 한다.

본문에서는 Number of Threads(users)를 10명으로 Loop Count는 3으로 수정하였다. 이 숫자나 양은 테스트 부하에 따라 적절하게 조정해주면 된다.

이제 부하 테스트를 해볼 차례다. 부하 테스트는 메뉴에서 Run > Start를 선택하거나 Ctrl + R 키를 누르면 Test Plan을 저장할 것인지 묻게 되고 아니오(N)을 누르면 테스트를 시작한다. 만약 Test Plan이 저장되어 있다면 바로 부하 테스트를 시작하게 된다.


[그림 4-4] 테스트 계획을 저장하시겠습니까?

부하가 진행되는 중에는 [그림 4-5]에 있는 네모 박스에 녹색불이 들어오면서 테스트를 시작한다.


[그림 4-5] 부하가 진행중인 표시

부하 테스트가 끝나면 JMeter의 왼쪽 트리에서 View Results Tree를 선택하면 오른쪽 화면이 [그림 4-6] 처럼 바뀌게 된다.


[그림 4-6] View Results Tree

[그림 4-6]과 같이 테스트한 결과가 출력되었다면 테스트는 정상적으로 이루어진 것이다. 하지만 종종 화면 좌측에 보이는 초록색의 삼각 아이콘 모습이 나타나지 않으면 네트워크 연결 오류나 서버측 오류로 인해 테스트할 없는 상황으로 본다.

다음 [그림 4-7]은 Graph Results 노드를 선택한 결과이다.


[그림 4-7] Graph 결과로 표시된 부하 테스트

5. JMeter를 사용한 실제 전략

본 섹션에서는 JMeter를 사용해 실제로 로그인하고 로그인한 정보를 바탕으로 접근 가능한 URL에 접근해 부하 테스트를 진행해보겠다.

본문에서는 테스트를 설명하기 위해서 daum 에 로그인하고 저자가 카페지기로 있는 사이트에 가서 특정글에 대한 요청을 서버에게 던져서 정상적으로 글을 가져오는지 확인해보겠다.

우선 다음과 같이 Test Plan 노드를 추가한다.


[그림 5-1] Daum의 Café에 접속하기 위해 글을 가져오기 위한 Test Plan

[그림 5-1]과 같이 Test Plan을 만들면 되는데 가만 보면 못 보던 요소가 하나 존재한다. 바로 HTTP Cookie Manager인데 Cookie Manager는 JMeter 2.0.3 부터 새로이 추가된 element다.

이 element의 추가는 [그림 5-2]에서 보이는 것과 같이 추가한다.


[그림 5-2] HTTP Cookie Manager 추가하기

Cookie Manager는 Thread Group이나 Test Plan 노드에 추가해도 되는데 Test Plan 노드에 추가하는 경우는 여러 Thread Group이 모두 로그인 페이지를 요구하는 경우 유용하게 사용할 수 있다.

반대로 특정 Thread Group에서만 로그인 페이지를 요구하는 경우 Thread Group에만 추가하면 된다.

그리고 HTTP Request Sampler를 총 2개 추가한다.

HTTP Request Sampler는 다음 [그림 5-3]과 같이 설정한다.


[그림 5-3] HTTP Request 1

첫번째 HTTP Request는 Daum에 로그인 요청을 하는 Sampler이다. [그림 5-3]에 보이는 요소에 대해서는 섹션 4에서 다루었기 때문에 섹션 4와 비교했을 때 다른 것만 알아보기로 한다.

[그림 5-3]에는 빨간 박스로 강조되어진 부분이 있는데 이 부분은 JMeter에서 요청을 한후 자동으로 주소를 변경할지를 설정하는데 일부 사이트의 경우 이 옵션이 켜져 있을 경우 문제가 된다. 때문에 로그인하는 요청의 경우 옵션은 해제해주는게 좋다. 그리고 Follow Redirects 옵션을 켜주는게 좋다. Follow Redirects 옵션은 웹 사이트의 Redirect 액션을 허용한다.

[그림 5-4]는 실제 게시물에 접근하는 요청이다. 이때 접근하는 URL은 미리 페이지 등록정보를 통해 확인한 URL을 이용한다.


[그림 5-4] HTTP Request 2

[그림 5-4]는 게시물에 접근하는 요청이다. 빨간 박스로 강조된 부분은 Path에 인자로 넘겨지는 부분인데 이와 같이 URL에 접근에 있어서 파라메터를 요구하는 경우는 1개씩 인자를 생성해주어야 한다.

이제 요청 결과를 알아보기 위해 Test Plan을 실행한다. Test Plan의 실행은 Run > Start 메뉴를 선택하거나 Ctrl + R 키를 누른다.

그럼 [그림 5-5]와 같이 Test Plan을 저장할 것이냐고 물어오는데 본문은 테스트이므로 아니오를 눌러 저장하지 않는다.


[그림 5-5] Test Plan을 저장할것입니까?

스트레스 테스트가 끝나면 JMeter의 왼쪽 트리에서 View Results Tree 노드를 선택한다.


[그림 5-6] View Results Tree 노드 선택

이제 JMeter의 화면 오른편에는 [그림 5-7]과 같은 화면이 있는 걸 볼 수 있다.


[그림 5-7] View Results Tree 초기 화면

이제 [그림 5-7]에 보이는 항목을 클릭하면 [그림 5-8]과 같이 변경된다.


[그림 5-8] 2번째 HTTP Request 클릭 후

[그림 5-8]의 결과를 보면 정상적으로 수행은 된거 같은데 어떤 결과가 왔을지 사뭇 궁금해진다. 결과를 확인하기 위해 [그림 5-8]에 보이는 Response data 탭을 클릭하고 적절하게 위치를 이동하면 아래와 같은 결과를 확인해볼 수 있다.


[그림 5-9] 정상적으로 받아온 데이터

[그림 5-9]에 보이는 화면과 같이 데이터를 정상적으로 받아온 것을 확인할 수 있다. 물론 [그림 5-9]에 보이는 것과 같이 보이지 않는다면 [그림 5-9] 하단에 보이는 Render HTML이나 Show Text 라디오 버튼을 선택해야 한다. Render HTML의 경우 일부 웹 사이트는 정상적으로 보여지지 않을 수 있기 때문에 Show Text 라디오 버튼을 선택해서 보는 것이 더 정확하다.

사족으로 [그림 5-9]에 보이는 내용은 가수 이소은씨가 팬카페에 2007년 4월에 게시판에 남겨준 내용이다.

여기까지 잘 따라왔다면 정상적으로 처리가 되어야 하지만 그렇지 않다면 뭔가 이상이 있는 경우이므로 다시한번 확인해보기로 한다.

6. JMeter 로그 분석하기

JMeter로 테스트는 했는데 정작 테스트 결과를 볼 수 없거나 엉뚱한 자료만 가지고 있다면 분석은 못하게 될것이다.

이를 위해서 Listener로 Summary Report element를 추가해주는 것을 권장한다.

섹션 5에서 수행했던 Summary Report를 보면 [그림 6-1]과 같다.


[그림 6-1] Summary Report

[그림 6-1]은 섹션 5에서 수행된 Summary Report인데 눈여겨 봐야 할 컬럼은 총 5개로 위 그림에서 강조되어 있다.

결과 분석을 위해 첫번째 컬럼부터 살펴본다.

• 1번째 컬럼 : 서버에 요청한 횟수
• 2번째 컬럼 : 평균 응답시간(ms단위)
• 3번째 컬럼 : 최소 응답시간(ms단위)
• 4번째 컬럼 : 최대 응답시간(ms단위)
• 5번째 컬럼 : Error율(%단위)

5번째 컬럼을 제외하곤 4번째 컬럼까지는 값의 단위는 밀리 세컨드 단위(ms)이다. 1초는 0.001 밀리세컨드이다. 계산이 귀찮다면 google 에 밀리 세컨드 값을 넣고 다음과 같이 검색어를 입력한다.

78 milliseconds to seconds

그러면 google이 자동으로 계산해준다.

5번째 컬럼은 서버로의 요청 중에 문제가 있을 경우 에러가 났다거나 한 경우 그 에러율을 퍼센테이지로 표시해준다.

여기서 살펴본 것을 기준으로 간단한 보고서 작성이 가능하겠으나 더 자세한 보고서 작성을 위해 JMeter User Manual을 참조해 다양한 Listener 추가를 통해 다양한 결과 형태를 볼 수 있으므로 꼭 한번씩 참조해서 실행해보는 것을 권장한다.

7. JMeter 활용 전략

JMeter는 그 초기 목적과 달리 다양한 테스트를 위해 확장되고 있으므로 여러 목적으로 사용할 수 있다.

따라서 저자는 JDBC, Java Request, JUnit, FTP 등을 테스트 하기 위해 JMeter 사용을 권장한다.

JMeter의 보다 폭 넓은 활용을 위해서 다음과 같은 사용 전략을 제시한다.

• JDBC 테스트 : DB가 얼마나 부하를 견딜 수 있는지 알고 싶다
• Java Request 테스트 : 순수 자바 애플리케이션을 만들고 있는데 별도의 테스트 툴이 없어서 힘들다.
• JUnit 테스트 : 애플리케이션 테스트를 위해 Junit Test Case를 만들었는데 JMeter로 대신 실행해서 JUnit을 부하 테스트 하는데 사용하고 싶다.
• FTP 테스트 : FTP 서버를 구축했는데 얼마나 접속했을 때 다운되는지 알고 싶다(실제 이렇게 할 사람이 있는지 모르겠다)

물론 위와 같은 사용 제시 외에도 JMeter는 대표적인 오픈소스 IDE인 Eclipse와 연동해서 사용하는 것이 가능하다. 다음에 기회가 되면 이 같은 사용법을 제시할 수 있기 바란다.

 

 

중견 탤런트 김영애(58)가 결혼 6년만에 파경을 맞았다.

김영애는 21일 연합뉴스와의 전화 통화에서 "서류상으로는 지난해 11월께 이혼했다. 그러나 그 이후로 잘해 보려고 다시 노력 했다. 하지만 결국 지난 3월말 헤어지기로 했다"고 밝혔다.

그는 "웬만하면 잘 살아보려고 했지만 어떻게 일이 이렇게 됐다. 너무 죄송하다"며 "지난 2년여간 너무 힘들었고 잠을 못 이루는 나날이 많았다. 수면제를 먹어도 잠을 못자는 날이 이어졌다"고 덧붙였다.

김영애는 2003년 5월 다섯살 연하의 재미 사업가 박모씨와 재혼했으며, 함께 황토팩 사업을 꾸려왔다.

그는 "두 번 이혼하는 모습을 보여드려 너무 죄송하다"면서 "앞으로 연기자로 더 충실하게 열심히 살겠다"고 말했다.

김영애는 영화 '애자'의 개봉을 앞두고 있다.

 

<출처>연합뉴스

 

---------------------------------------------------------------------------

 ♧ 수족구병 ♧
--------------------------------------------------------------------
바이러스 감염으로 손·발·입 속에 작은 수포가 생기는 질병이다.

주로 영·유아에게 발생하며 여름철에 많이 발병하고, 잠복기는 4∼6일 정도이다.

손바닥과 발등에 물집과 발진이 생기고 입 안에도 물집이 동반되며 궤양이 생기는 증상을 보인다.
대부분의 경우 수포가 수 일만에 없어져 자연 치유된다.
드물게 뇌수막염 등으로 발전하기도 하지만 그동안 사망사례가 보고된 적은 없었다.

최근 국내에서 처음으로 수족구병으로 12개월 된 영아 숨졌다.
질병관리본부는 중국과 동남아에서 유행하는 '중국형 수족구병 바이러스'가 국내에 유입·전염된
것으로 보고 있다.

손 깨끗이 씻고 청결 유지가 최선이라고 한다.

 [데일리안 나은경 객원기자]

◇ <닥터 몽 의대가다>에서 중간고사 재시험 중 눈물을 흘린 가수 MC몽. ⓒ 엠넷미디어

´의대생´ 변신에 도전한 MC몽이 ´중간고사´ 재시험 중 끝내 눈물을 흘려 팬들을 더없이 안타깝게 했다.

음악&버라이어티 채널 Mnet <닥터 몽 의대가다>(연출:박준수PD)]를 통해 가톨릭 의대에서 청강생 자격으로 수업을 받고 있는 MC몽은 지난 주 드디어 첫 중간고사를 치렀다. 하지만 합격 선을 넘지 못했고 결국 ´재시험´을 볼 것을 통보 받은 상황. 이로 인해 MC몽이 의대 제적 위기에 몰린 것은 물론 앞으로의 프로그램 존폐 여부까지 불투명해 진 셈이다.

이에 MC몽은 자신으로 인해 정말 프로그램이 이대로 끝나는 건 아닌가 싶어 담당 교수를 찾았고 지푸라기라도 잡는 심정으로 솔직한 자신의 마음을 전한 것.

MC몽은 “제가 부족한 건 있지만 분명 노력하는 부분도 보였을 거에요. 저의 부족한 지식으로 인해 가톨릭 의대가 망신 당하는 일은 없을 겁니다” 며 “시청자들의 눈으로 국내 의료 환경이 어떤 지, 어떤 과정을 거쳐 의사가 되는 지를 알려주는 것이 내 역할이라고 생각한다”고 말했다.

이어 “함께 공부하며 가톨릭 의대 교수님들을 존경하게 됐다. 하지만 제작진에게는 솔직히 섭섭한 게 많다”며 “내게 능력 이상의 것을 요구하며 진짜 의대생들과 똑같은 공부를 하고 똑같은 결과를 내길 바라는 거 같아 너무 힘들다”고 호소, 끝내 눈물까지 보이고 말았다.

한편, 오는 21일 방송분에서는, 지난 5일 어린이날을 맞아 강남 성모 병원 ‘소아암 병동’을 찾았던 MC몽의 모습이 공개될 예정.

MC몽은 특유의 능청스러움과 편안함으로 ‘어린이 날’ 하루 동안 아픈 어린이들의 친구로 최고의 날을 선물해 잊지 못할 행복한 추억을 선물했다.

연출을 맡고 있는 박준수PD는 “MC몽이 다녀간 이후, 병원 측에서 그 동안 방문했던 연예인 중 가장 정성스럽게 환우들을 돌보고 편히 대했던 거 같다. 그래서 어린이들도 이 날 무척이나 즐거워 했다는 말을 제작진에게 전해왔다”고 전했다.
- Copyrights ⓒ (주)이비뉴스, 무단 전재-재배포 금지 -

 

 

 

'닥터몽 의대가다'에서 MC몽 눈물보이다.

 

서인영의 카이스트를 이어 MC몽이 가톨릭 의대에 들어간 후 좌충우돌을 보여주는 프로 '닥터몽 의대가다'에서 첫 중간고사에서 합격선을 넘지 못해 재시험 통보를 받았다.

엠씨몽은 시청자들에게 국내의료환경과 의사가되는 과정을 보여주기위한 역할을 한다고 생각한다며

그러나 제작진은 진짜 의대생들과 똑같은 결과를 바라는 것 같이 힘들다며 끝내 눈물을 흘렸다.

 

분명, 그학교의 학생이 되었으니 최선을 다해서 공부를 해야겠지만, 어디까지나 프로그램의

하나라고 생각한다. 연예인들의 스케줄은 밤낮없이 방송녹화에 행사에... 어느정도 커버는

해줘야하는게 아닐까... 그리고 엠씨몽이 그만한 능력이됐음 의대를 정말 갔지 않았을까

[출처] '닥터몽 의대가다'에서 MC몽 눈물보이다.|작성자 beauty3300

루시고든 사망루시고든 사망루시고든 사망루시고든 사망루시고든 사망

 

 

영국의 여배우 루시 고든(Lucy Gordon)이 프랑스 파리의 아파트에서 사망한채 발견돼 팬들을 안타깝게 하고 있다

해외 각종 매체들은 고든이 지난 20일 아침 파리에 위치한 자신의 아파트에서

 

 남자친구에 의해 목을 매 숨진 채 발견됐다고 일제히 보도했다.

 

 이날은 고든의 29번째 생일을 이틀 앞둔 날이다.

 

 프랑스의 한 신문에 따르면 당시 남자친구는 같은 아파트에서 자고 있던 것으로 알려졌다.

프랑스 경찰 측은 일단 자살로 추정하고 있지만 타살일 가능성을 감안해 부검도 실시할 예정이다.

 

 경찰은 "우리는 자살이라고 생각한다"고 밝혔고

 

 고든의 매니저인 장 루이 디아모니카 역시 "자살로 확인했다"고 말했다.

경찰에 따르면 파리의 한 상점 주인은 "이틀전 우리 가게에 왔을 때 고든은 밝고 경쾌한 아가씨였다.

 

행복해 보였다. 우리는 즐겁게 이야기를 나눴다"고 말해 자살 이유에 대해 의문을 증폭시켰다.

 

'스파이더맨2'에 출연한 루시 고든[사진=영국 타블로이드지 '선' 인터넷판 캡쳐]

 

루시의 아버지 리차드 고든은 "나와 나의 아내 수(Sue), 루시와 자매인 캐티는 그를 사랑했었다.

 

 루시는 사랑스럽고 마음이 넓은 아이였다.

 

 우리는 루시가 자랑스럽다. 루시는 타고난 배우였다"고 딸의 죽음을 안타까워했다.

또 칸국제영화제의 대변인은 고든에 대해 "전도 유망한 배우였다"며

 

"그의 사망 소식에 우리는 애통한 마음을 금할 길 없다"고 공식적으로 발표했다.

 

고든은 사망전 칸영화제에 참석했던 것으로 알려졌다.

 

모델 출신으로 2001년부터 영화배우로 나선 고든은 '스파이더맨3'에 제니퍼 듀간 역으로도 출연하는 등

 

촉망받는 여배우였기 때문에 영국은 물론 프랑스에도 충격을 던져주고 있다