regina Wed Jan 10 22:00:36 2001 EDT
Modified files:
/phpdoc/kr/features persistent-connections.xml
Log:
Index: phpdoc/kr/features/persistent-connections.xml
diff -u phpdoc/kr/features/persistent-connections.xml:1.3
phpdoc/kr/features/persistent-connections.xml:1.4
--- phpdoc/kr/features/persistent-connections.xml:1.3 Tue Jan 9 21:49:22 2001
+++ phpdoc/kr/features/persistent-connections.xml Wed Jan 10 22:00:36 2001
@@ -1,28 +1,28 @@
- <chapter id="features.persistent-connections">
- <title>영구적인 데이터베이스 접속 (Persistent database
connections)</title>
-
- <simpara>
+<chapter id="features.persistent-connections">
+ <title>영구적인 데이터베이스 접속 (Persistent database
+connections)</title>
+ <simpara>
영구적인 접속(Persistent connection)은 여러분의 스크립트가
종료되어도
SQL link를 닫지 않는 접속을 말한다. 영구적인 접속이
요청되면,
PHP는 기존의 (이전에 열어 두었던) 동일한(identical)
영구적인 접속이 있는가를 검사한다.
만약 있다면 기존의 것을 사용하고, 없다면 새로운 link를
만든다.
'동일한' 접속이란 같은 호스트에 같은 사용자명과 같은
암호를 사용한 접속을 말한다.
</simpara>
- <simpara>
+ <simpara>
가끔 웹서버의 작동과 작업의 할당에 대해 잘 알고 있지
못한 사람들은
영구적인 접속이 사실은 별 것 아니라고 오해하기도 한다.
- 특히, 영구적인 접속이 동일한 SQL link에서 'user sessions'를
여는데 별 나을 것도 없다던가, transaction을 효율적으로
처리하는 것도 아니라다던가, 혹은 다른 어떤
+ 특히, 영구적인 접속이 동일한 SQL link에서 'user sessions'를
+여는데 별 나을 것도 없다던가,
+ transaction을 효율적으로 처리하는 것도 아니라다던가, 혹은
+다른 어떤
특별한 것을 하는 것도 아니라고 한다. 사실, 이런 말들에
대해 명백히 말하자면,
영구적인 접속은 비영구적인 접속에 비해 어떠한 기능적인
향상도 주지 못한다.
</simpara>
- <simpara>
+ <simpara>
왜?
- </simpara>
- <simpara>
+ </simpara>
+ <simpara>
이것은 웹서버의 동작 방식에 따라 다른 효과를 낸다.
여러분의 웹서버가 웹 페이지를 만들기위해 PHP를
이용하는데는 3가지 방법이 있다.
</simpara>
- <simpara>
+ <simpara>
첫 번째 방법은 PHP를 CGI "wrapper"이 형태로 사용하는 것이다.
이 방법의 경우, 웹서버에 매 PHP 페이지가 요구될 때 마다,
PHP 인터프리터의 실행이 만들어지고 종료된다.
@@ -31,7 +31,7 @@
이 경우 영구적입 접속을 사용하여 어떤 이득도 얻을 수
없다.
다르게 말하면 이 경우는 영구적인 접속을 해도 영구적이
아니다.
</simpara>
- <simpara>
+ <simpara>
두 번째 방법은 가장 대중적인 방법인데,
PHP를 다중프로세스(multiprocess) 웹서버의 모듈로 사용하는
것이다.
(현재는 Apache가 유일하다.) 다중프로세스 서버는 보통 한
개의 부모(parent) 프로세스와,
@@ -44,7 +44,7 @@
자신이 처음 요구받았을 때 SQL 서버에 접속하게 된다.
다른 페이지에서 SQL 서버에 접속 요구시는 이전에
만들어진 접속을 다시 사용하게 된다.
</simpara>
- <simpara>
+ <simpara>
마지막 방법은 PHP를 멀티쓰레드(multithreaded) 웹서버의
플러그-인의
형태로 작동시키는 것인데, 현재 이방법은 이론적으로만
존재하고,
실제로 만들어 진 것은 없다. ISAPI, WSAPI, NSAPI (Windows에서)
등의
@@ -53,11 +53,11 @@
동작시키려는 작업이 현재 진행중이다. 이 경우 기본
동작은 위에서 언급한
다중프로세스 모델과 동일하게 동작한다.
</simpara>
- <simpara>
+ <simpara>
영구적인 접속이 실제로 어떠한 기능적인 향상도 주지
못한다면,
이것을 사용해 어떤 이점이 있나요?
</simpara>
- <simpara>
+ <simpara>
이것에 대한 간단한 답은 효율성이다.
영구적인 접속은 SQL 서버와의 link를 만드는 것에 따른
overhead가 클 경우에 유용하다.
이 overhead는 많은 요인에 따라 커지기도 하고 작아지기도
한다.
@@ -72,27 +72,23 @@
실행하였던 20개의 다른 자식 프로세스가 있다면,
아마도 각각의 자식 프로세스에대해 1개씩, 20개의 SQL
접속이 있을 것이다.
</simpara>
- <simpara>
- Note, however, that this can have some drawbacks if you are using a
- database with connection limits that are exceeded by persistant
- child connections. If your database has a limit of 16 simultaneous
- connections, and in the course of a busy server session, 17 child
- threads attempt to connect, one will not be able to. If there are
- bugs in your scripts which do not allow the connections to shut
- down (such as infinite loops), a database with only 32 connections
- may be rapidly swamped. Check your database documentation for
- information on handling abandoned or idle connections.
+ <simpara>
+ 이 방법은 영구적 접속의 개수가 데이타베이스 서버가
+허용하는 의 접속수를 초과해서 설정되어
+ 있는 경우 문제가 될 수 있다.
+ 만약 데이타베이스가 16개의 동시 접속을 허용하고, 이
+서버 세션들이 모두 사용중이면,
+ 17번째 thread는 연결을 시도하다가 실패할 것이다. 만약
+여러분이 만든 스크립트에
+ 이런 경우에 대비한 특별한 대책이 없이 재시도를
+반복하다보면 가능한 모든 connection을
+ 사용하여 복구할 수 없게 된다. 이런 abandoned 혹은 idle
+connection을 다루는 자세한
+ 설명은 데이타베이스 문서를 참조하기 바란다.
</simpara>
- <simpara>
+ <simpara>
중요한 언급 한가지!
영구적인 접속은 일반적인 접속에 일대일로 대응되도록
설계되었다.
이것은 스크립트의 다른 부분은 그대로 두고,
언제라도 비영구적인 연결을 영구적인 연결로 대치할 수
있다는 것을 의미한다.
이것으로 여러분은 아마도 스크립트의 효율을 향상시킬
수도 있을 것이다.
</simpara>
-
- </chapter>
-
+</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
