호스팅2009. 12. 18. 16:51

안녕하세요, 오늘은 좋은 정보를 하나 제공해 드리려고 합니다.
최신 기술을 습득할 수 있는 방법은 오프라인 교육에 참가하거나 온라인 교육을 받으실 겁니다.

그런데, 엔지니어가 오프라인 교육에 참가하기 위해 1일 ~ 3일 동안 자리를 비우는 것은 쉬운 일이 아닙니다.
따라서 온라인 교육이 좋은 대안이 되는데, 원하는 교육을 찾는 것도 쉬운 일은 아니죠.

아래 Microsoft Partner Network에 무료 회원으로 가입하시면 웹 관련 전문 교육 과정을 수강하실 수 있습니다. 또한, 일부 오프라인 강의도 있습니다. 일정이 허락한다면 오프라인, 안되시면 온라인 강의를 들으시면 되는 거죠.

 

 

Posted by 조이트리
호스팅2009. 4. 24. 13:06

지금까지 미디어 서비스를 어떤 방식으로 운영하셨나요? 스트리밍 또는 프로그레시브 다운로드 방식이었죠?
스트리밍은 동영상/미디어 유출 등을 보호할 수 있고, 대역폭을 효과적으로 사용할 수 있다는 장점에 많이 사용되었고
프로그레시브 다운로드는 웹서버에 동영상 파일을 그냥 위치시켜 놓으면 특별한 노력 없이 미디어 서비스가 가능했기에 많이 사용되었습니다.

하지만, 스트리밍 방식은 캐싱이 되지 않는 다는 단점이 있었고, 프로그레시브 다운로드는 대역폭의 낭비가 한계였습니다. 예를들면, 1시간 짜리 동영상을 10분 보고 중단하는 경우에도 1시간에 해당하는 700M를 모두 한 번에 다운 받기 때문에 미디어 서비스를 하는 회사 입장에서는 자원이 낭비되고 있었습니다. 이를 해결하기 위해 IIS7에서는 Bit Rate Throttling 기능을 통해 서비스 공급자가 버퍼링을 없애기 위한 20초, 10초 등의 데이터만 더 다운 받도록 하는 방식을 추가했었죠. 이건 앞의 글에서 찾아보실 수 있습니다.

여기에 한 발 더 나아가서 IIS7의 Smooth Streaming이 발표되었습니다.

Smooth Streaming은 사용자가 요청할 때 그 파일의 일부를 보내주는데 중간에 Edge Server를 두고 그 서버를 통해 클라이언트로 파일을 전송합니다. 이 조각난 파일들은 Cache로 남아 있게 되고, 다른 사용자의 요구에 실제 Origin서버까지 가지 않고 Edge Server에서 전송받는 형태죠. 즉 스트리밍의 단점인 캐싱을 가능하게 해주고, 프로그레시브의 단점인 대역폭 낭비를 막아주는 것이죠. 여기에 한 발 더 나아가서 아래와 같이 사용자의 네트웍, PC 상황에 맞도록 300K, 700K, 2.4M 등의 가변적인 파일 공급을 통해 사용자는 느끼지 못하는 동안 최고의 품질을 경험하게 하는 방식 입니다.
Posted by 조이트리
호스팅2009. 4. 1. 16:28

웹 개발 해야지, 하고 마음먹으신 후 해야할 일들을 나열해 볼까요?

PC에 윈도우는 깔려있다고 가정해보죠. IIS 웹서버, DBMS, .NET Framework, 개발툴 등을 별도의 사이트를 찾아다니면서 다운로드 받아서 설치하셔야 하는데, 쉽게 말해 번거롭죠. 시간도 많이 걸리고.
결국 microsoft.com, download 사이트, codeplex.com 등 여기 저기 찾으셨어야 하죠.

마이크로소프트 웹 플랫폼 설치기 2.0 하나면 이런 고민이 다 해결됩니다.
Web Platform Installer 2.0
http://www.microsoft.com/web/downloads/platform.aspx


위의 설치기를 이용하면 PHP 커뮤니티 버전 (5.2.9-1) 역시 함께 설치 됩니다.

  • Internet Information Services (IIS) 5.1 on Windows XP SP3
  • IIS 6.0 on Windows Server 2003 SP2
  • IIS 7.0 on Windows Vista SP1 and Windows Server 2008
  • SQL Server 2008 Express
  • .NET Framework 3.5 SP1
  • Visual Web Developer 2008 Express Edition
  • Various IIS Extensions
  • ASP.NET and features such as ASP.NET MVC
  • Silverlight Tools for Visual Studio

이런 웹 플랫폼 위에서 구동되는 다양한 애플리케이션들을 사용하실 수 있습니다.
http://www.microsoft.com/web/gallery/Categories.aspx
바로 위의 링크를 클릭하시면 찾아 보실 수 있죠.

제로보드, TextCube 등 우리나라에서 인기있는 애플리케이션은 어디 있냐고요?
http://www.windowslovephp.co.kr 에 가시면 매뉴얼을 확인하실 수 있습니다.
PHP on Windows, ASP, ASP.NET on Windows가 이제는 모두 가능하게 된거죠.

Posted by 조이트리
호스팅2009. 1. 29. 17:07

2주에 한 번씩 위와 같은 Training을 진행하고 있습니다. 호스팅 비즈니스도 변화의 시기가 왔습니다. 웹호스팅,
서버호스팅  외에 애플리케이션 호스팅 등의 영역이 추가되었습니다. 누가 먼저 선점하는지 지켜봐야 할 것 같습니다. 

오늘 진행한 세미나에서는 Windows Server 2008 + IIS7 + PHP + MySQL 환경에서 구동되는 www.zconvert.com 사이트를 소개해 드렸습니다. 이 사이트는 Windows Server 2008의 가상화, Hyper-V 기반위에서 구동되고 있는데 사이트 속도를 보시면 굉장히 빠른 것을 보실 수 있습니다.
PHP on Windows가 좋은 궁합이라는 것을 보여주는 사례라고 할 수 있죠. 

또한, 많은 분들이 잘 모르고 계시는 대역폭을 절감할 수 있는 IIS7의 Bit Rate Throttling 을 통한 비용절감 방안, 애플리케이션 호스팅의 가능성 및 최초 적용 솔루션으로 Dynamics CRM에 대한 소개 등의 시간을 가졌습니다. 
이후에 일정이 잡히면 공지하도록 하겠습니다. 많은 참여 부탁 드립니다. 


Posted by 조이트리
호스팅2008. 11. 17. 11:36

 웹에서 비디오를 서비스하는 것은 가장 일반적인 시나리오 중의 하나가 되었습니다. 상품에 대한 설명 비디오, 동영상 교육 비디오, 광고, UCC 동영상, 뮤지비디오 등 정말 다양합니다.

그런데 한가지 이슈가 있죠. 네트웍 대역폭은 IT에서 가장 비용이 많이 드는 항목 입니다. 또한, 고화질을 원한다면 그 비용은 훨씬 더 비싸지죠.

그렇다면, 위와 같은 동영상을 호스팅 하는 방법과 그 비용을 줄일 수 있는 방법에 관심이 갈 수 밖에 없을텐데요, 그 부분을 오늘 설명드리도록 하겠습니다.

1. 무료 미디어 호스팅 서비스를 사용하는 방법
    - YouTube, 마이크로소프트 Silverlight 스트리밍 서비스, NHN의 블로그에 연계하는 방법 등 다양하죠. 즉, 비디오 컨텐츠를 다른 회사의 네트웍을 이용해서, 그 회사가 대역폭 비용을 내도록 하는 방법이죠. 그 회사는 광고등으로 수익을 얻게 되는 방식 입니다. 마이크로소프트의 Silverlight 스트리밍 서비스는 10G의 컨텐츠까지 업로드할 수 있고, 한달에 5TB까지는 무료로 다운로드 가능하도록 제공 되는 서비스 입니다. (최대 1.4 Mbps Bit-rate 제공)

2. 자체 서버에서 미디어를 호스팅 하는 방법
  
- 미디어에 인증을 부여하고 싶거나, 큰 동영상을 서비스하는 경우, 또는 비디오에 광고를 넣고 싶은 경우에는 직접 호스팅을 하고 싶어질 겁니다. 컨트롤을 해야 하기 때문이죠.

이때는 두가지 옵션이 있습니다.
    1) 스트리밍 서버 시나리오
       . 스트리밍 시나리오에서는 클라이언트 (Silverlight, 윈도우 미디어 플레이어, 플래쉬 등)가 스트리밍 서버에 연결을 하게 됩니다. 스트리밍 서버가 비디오 스트림을 내려 보내고, 사용자는 앞으로 가거나 뒤로 돌려보기, 정지, 멈춤 등을 자유롭게 할 수 있습니다. 사용자가 브라우저를 닫거나, 다른 페이지로 이동하면 비디오 스트림이 자동적으로 데이터 보내는 것을 멈추게 되죠.
Windows Media Services (WMS)는 윈도우에서 무료로 다운받아 사용할 수 있는 스트리밍 서버이고, 윈도우 미디어 플레이어나 크로스 플랫폼 기능이 제공되는 Silverlight 등의 클라이언트를 사용할 수 있습니다. 웹에서 비디오 스트리밍을 제공할 때 가장 확장성이 뛰어나고 비용 효율적인 방식이며, 온디맨드 스트리밍, 또는 실시간 스트리밍 등의 방식으로도 사용될 수 있습니다. 또한, Windows Server 2008 Web Server 에디션에서도 구동 가능합니다.

   2) 프로그레시브 다운로드 시나리오
       . 프로그레시브 다운로드 시나리오에서 클라이언트 (플래쉬, Silverlight)는 웹서버에 직접 연결되어 비디오를 다운로드 받기 시작하며, 충분한 양이 다운로드 되면 바로 플레이가 가능합니다. 이 방식의 장점은 웹서버에 설정하는 것이 정말 쉽습니다. 웹서버에 해당 미디어를 복사한 후, URL 주소만 정해지면 클라이언트 비디오 플레이어가 플래이 합니다. 웹서버에 설정이 필요없고, 스트리밍 서버 셋업등의 과정이 불필요합니다.

프로그레시브 방식의 단점은 웹서버가 최대한 빨리 파일이 다운로드 한다는 것입니다. 사용자가 사이트에서 비디오 보기를 클릭하면 웹서버가 클라이언트로 해당 파일을 최대한 빠르게 보내기 시작합니다. 사용자가 처음부터 끝까지 비디오를 본다면 별 문제가 없지만, 비디오를 보다가 중간에 멈추거나, 다른 페이지로 옮겨 가면 보지도 않는 파일이 다운로드가 된다는 불합리한 부분이 있습니다. 보지도 않는데 다운로드 되는 내용이 수 메가바이트나 된다면, 그 만큼의 돈을 낭비하고 있는 셈이 되는거죠.

3. 그래서, IIS7.0 비트 레이트 Throttling 모듈 (Bit Rate Throttling Module)이 있습니다.
     - 해당 모듈은 미디어 유형에 관계없이 Bandwidth, 즉 대역폭의 낭비를 막아줍니다. 최초로 마임타입 확인 후, 파일에 대해 Bit-rate 인코딩을 한 후 최초 20초간 플레이 할 수 있는 양의 미디어를 최대한 빠르게 전송합니다. 일단 20초 만큼의 미디어가 다운된 이후 부터는 Bit Rate Throttling 모듈이 전송되는 양을 제어하기 시작합니다. 그러면서, 클라이언트가 플레이어를 멈추거나 다른 페이지로 옮겨가는 것을 모니터링 하다가 사용자가 시청을 멈추는 순간 자동적으로 파일 보내기를 멈추게 하는 역할을 합니다.

예를들면, 35MB짜리 비디오 파일이 500Kbps의 속도로 인코딩되어 상영되면, IIS는 20초에 해당하는 만큼의 파일을 즉시 내려보낸 후 (20초 * 500Kbps, 1.25MB), 이후에는 초당 500Kbps의 컨텐츠를 내려보냅니다. (20초 만큼의 버퍼만 갖도록 유지, 사용자가 보다가 버퍼링이 일어나지 않도록 하기 위함)

만약, 1분 후에 사용자가 비디오 보기를 멈추거나 다른 페이지로 옮겨 가면, IIS가 상황을 인지하고 컨텐츠 전송을 멈추게 됩니다. IIS는 단지 80초에 해당하는 비디오만 다운로드 했기 때문에 전체 35MB 중 (5M, 즉 80초 * 500kbps)의 대역폭만 사용한 셈이 되는 것이죠. 이 30MB가 수백번 반복 된다면 대역폭, 즉 비용을 엄청나게 절약할 수 있게 되는 것입니다.


  • Bit Rate Throttling Module Setup
  • Bit Rate Throttling Configuration Walkthrough
  • Bit Rate Throttling Extensibility
  • ScottGu's의 블로그를 참고하여 글을 정리하였습니다.

    Posted by 조이트리
    마케팅2008. 7. 27. 16:57
    몇 가지 고려사항이 있습니다.

    첫째, PHP 웹사이트의 보안을 위해 다른 사이트와 격리 시켜야 합니다.
     . 웹사이트 마다 어플리케이션 풀을 각자 할당
     . 어플리케이션 풀 아이덴티티에 사용자 계정 사용
     . 어플리케이션 풀 아이덴티티를 사용하기 위해 Anonymous 사용자 설정
     . FastCGI의 impersonation 설정 확인 (fastcgi.impersonate = 1)

    둘째, PHP 프로세스를 재활용 하세요
     . 네이티브 PHP 리사이클링이 시작되기 전에, php-cgi.exe가 항상 리사이클 되도록 하는 것이 좋습니다.
       FastCGI의 프로세스 리사이클링은 instanceMaxRequests라는 파라미터에 의해 결정됩니다.
       리사이클 되기 전에 몇개의 FastCGI 프로세스를 처리할 것인지를 설정하는 역할을 하죠. 이 파라미터 이외에도
       PHP 자체적으로 프로세스 리사이클링을 담당하는 파라미터가 있는데, PHP_FCGI_MAX_REQUESTS가 바로
       그거죠. instanceMaxRequest 값을 PHP_FCGI_MAX_REQUESTS 값보다 작거나 같게 하면 PHP의 네이티브
       리사이클링은 절대 발생하지 않겠죠? 아래와 같이 설정하면 됩니다.

    C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000

    C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /+[fullPath='c:\{php_folder}\php-cgi.exe'].environmentVariables.[name=’PHP_FCGI_MAX_REQUESTS’, value='10000']

    ※ 미리 값을 설정하지 않으면 기본 설정값은 instanceMaxRequest=200, PHP_FCGI_MAX_REQUESTS=500 으로 할당됩니다.

    셋째, PHP의 버전
     . PHP 어플리케이션은 주로 특정 버전의 PHP의 기능 및 특징을 이용하여 개발되죠. 웹호스팅 환경에서, 또는 기업에서 사용하는 PHP 어플리케이션이 다양한 버전의 PHP를 사용한다면, 한대의 서버에서 여러개의 PHP를 지원하는 것은 필수겠지요. IIS7의 FastCGI 핸들러는 여러 버전의 PHP를 지원합니다. PHP4.4.8, PHP5.2.1, PHP5.2.5 non thread-safe 버전이 모두 필요하다면 PHP컴파일러를 파일 시스템에 각각 다운 받아야 합니다. (c:\php4.4.8, c:\php5.2.1, c:\php525nts)를 설치한 후 각 버전의 어플리케이션 풀을 생성합니다.

    C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php448\php.exe']

    C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php521\php-cgi.exe']

    C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php525nts\php-cgi.exe']

    site1, site2, site3의 3개의 웹사이트가 있고 각 사이트가 별도의 버전 PHP를 사용한다면 아래와 같이 설정할 수 있을 겁니다.

    C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’]

    C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’]

    C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]

    넷째, PHP 보안강화를 위한 추천 항목
    1. Disable remote URL's for file handling functions:
      • Set allow_url_fopen=Off
      • Set allow_url_include=Off
    2. Disable register_globals:
      • register_globals=Off
    3. Restrict where PHP can read and write on a file system, e.g.:
      • open_basedir="c:\inetpub\"
    4. Disable safe mode:
      • safe_mode=Off
      • safe_mode_gid=Off
    5. Limit script execution time:
      • max_execution_time=30
      • max_input_time=60
    6. Limit memory usage and file sizes:
      • memory_limit=16M
      • upload_max_filesize=2M
      • post_max_size=8M
      • max_input_nesting_levels=64
    7. Configure error messages and logging:
      • display_errors=Off
      • log_errors=On
      • error_log="C:\path\of\your\choice"
    8. Hide presence of PHP:
      • expose_php=Off

    감사합니다.



    Posted by 조이트리
    호스팅2008. 7. 2. 14:57

    앞의 글에서 PHP 관련하여 적어보았습니다. FastCGI 설정하는 법과 PHP를 설정하는 법을 살펴보겠습니다.
    서버관리자 - 롤 서비스에서 CGI를 선택하세요. CGI와 FastCGI 서비스를 모두 설치합니다.


    이제 PHP 엔진이 필요하죠. http://www.php.net/downloads.php를 클릭하셔서 non-Thread safe 버전의 PHP를 다운 받으세요. non-Thread safe와 FastCGI를 함께 사용하셔야 최적의 성능을 보장받을 수 있습니다. Thread safety check를 할 필요가 없기에 시간이 단축되는 것이죠.

    1. 파일을 압축해제하세요. C:\PHP 디렉토리를 만드시는 것이 좋습니다. 또한, php.ini-recommended를 php.ini로 파일명을 바꾸세요
    2. php.ini 파일을 오픈 한 후 몇 가지 파라미터의 주석을 해제하세요.
        - fastcgi.impersonate = 1
        - cgi.fix_pathinfo = 1
        - cgi.force_redirect = 0
        - open_basedir 설정 (웹 사이트 컨텐츠가 있는 폴더나 네트웍 경로)
    3. PHP가 제대로 설치되었는지 확인을 위해 명령문에 아래와 같이 입력
        C:\PHP> php -info

    IIS가 PHP 어플리케이션을 처리하기 위해 처리기 매핑(Handler Mapping)을 설정해야 합니다. 주요 목적은 PHP 파일의 요청을 FastCGI를 통해 PHP 엔진으로 보내는 것입니다.




    요청 Path: *.php
    모듈: FastCGIModule
    실행파일: C:\php-cgi.exe
    이름: PHP via FastCGi (원하는데로 설정)

    대화상자에서 OK를 선택하시면 됩니다.

    이후에 c:\inetpub\wwwroot 폴더에 phpinfo.php 파일을 하나 생성합니다.
    내용: <?php phpinfo(); ?>

    브라우저를 연다음 http://localhost/phpinfo.php를 입력하면 설정이 제대로 되었다면 php에 대한 정보를 보여주는 화면이 나옵니다.

    이제 다 끝났습니다. 마지막으로 PHP와 FastCGI 리사이클링을 위한 설정을 해보죠
    FastCGI는 native PHP 리사이클링이 이루어지기 전에 php-cgi.exe 프로세스들을 리사이클링 시킵니다. 바로 이 리사이클링은 설정 프로퍼티, instanceMaxRequests에 의해 조절됩니다. 이 값은 FastCGI가 리사이클링 되기 전에 몇개의 요청을 처리할 것인지를 정하는 것이죠. PHP 역시 비슷한 설정값을 가지고 있는데, PHP_FCGI_MAX_REQUESTS가 바로 그것입니다. 만약 instanceMaxRequests의 값을 PHP_FCGI_MAX_REQUESTS의 값보다 작거나 같게 설정하면 PHP의 리사이클은 절대 발생하지 않을 것입니다.
    만약, 파라미터 값이 설정되지 않으면 디폴트 값을 사용하게 됩니다.
    instanceMaxRequests: 200, PHP_FCGI_MAX_REQUESTS: 500 (대부분의 PHP 빌드에서)

    파라미터 값을 설정하려면 아래와 같은 명령문을 사용하시면 됩니다.
    c:\>%windir%\system32\inersrv\appcmd set config -section:system.webServer/fastCGI /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000

    c:\>%windir%\system32\inersrv\appcmd set config -section:system.webServer/fastCGI /
    [fullPath='c:\{php_folder}\php-cgi.exe'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']

    www.iis.net에서 참조

    Posted by 조이트리
    호스팅2008. 7. 2. 14:16

    사용자 삽입 이미지


    등록하기 (이 링크를 눌러주세요)

    7월 10일 섬유센터 17층 세미나실에서 제4회 마이크로소프트 호스팅 세미나를 개최합니다.
    이번 세미나는 KIDC와 함께 진행합니다. 이후에도 주요 IDC와 함께 세미나를 진행할 계획이며, 각 IDC의
    입주사가 아닌 IDC, 호스팅 업체, 고객사도 참가 가능합니다.

    Windows Server 2008, IIS7 웹서버, 실버라이트를 포함하여 호스팅 자동화 솔루션에 대한 발표 및 데모도 진행될 예정입니다. 많은 참여 부탁드립니다.

    감사합니다.
    Posted by 조이트리
    호스팅2008. 7. 2. 10:56
    IIS7을 사용하면 어느 정도의 성능 향상을 얻을 수 있는지 궁금하시죠? Microsoft.com이 IIS7에서 구동되고 있다는 것 아시죠? IIS6과 비교하여 어느정도의 성능이 향상됐는지 실제 데이터를 통해 보여드리겠습니다.

    Windows Server 2008이 올해 3월에 출시되었고 많은 기업에서는 지금 왜 Windows Server 2003에서 업그레이드를 해야하는지 다양한 각도로 분석을 하고 있습니다. 당연히 의사결정을 위해서는 실제로 구현하고 효과를 보는 업체의 레퍼런스를 보기 원하시죠. IIS7의 메타베이스가 아닌 파일 기반의 설정 환경, 모듈화 아키텍처는 웹서버 관리를 훨씬 유연하게 할 수 있게 되었죠. 그렇다면 IIS 6.0 / WS2003 보아 어느 정도 더 뛰어난 성능을 발휘하는지 살펴 보도록 하겠습니다.

    IIS7가 IIS6보다 초당 31% 정도의 더 많은 요청을 처리했습니다. 더 많은 처리를 하기때문에 CPU 사용량은 이전보다 조금 더 사용하게 됩니다.

    효과를 분석하기 위해 "효율성"과 "CPU 사이클 당 요청하는 처리 수"를 사용했습니다. 이 메트릭을 사용하면 IIS 7.0 / Windows Server 2008이 IIS 6.0 / Windows Server 2003 SP2 보다 10% 정도 더 효율적인 것으로 나타났고, 이 자료는 www.microsoft.com 사이트를 운영하면서 조사된 값입니다.

    Performance Metrics                                    WS2003  SP2     WS2008       Change
    RPS / CPU Utilization (%) = Requests per CPU Cycle            4.36                 4.84             10.9%

    Server Efficiency
     . WS2003 SP2: 4.36, WS2008 RTM: 4.84

    SRV Efficiency

    CPU Utilization (%)
     . WS2003 SP2: 44.8%, WS2008 RTM: 52.8% ~ 17.9% 더 많이 사용함
       (WS2008이 더많은 요청 처리하기 때문)
    CPU Utilization

    Web Service - 초당 총 요청 처리 수 (RPS)
     . WS2003 SP2: 194, WS2008 RTM: 255 ~ 31.4% 더 많은 트래픽을 처리함
    Web Svc Total Methods

    Web Service - 현재 커넥션 수
     . WS2003 SP2: 280, WS2008 RTM: 294 ~ 5% 증가
    WEBSvc Current Connections
    테스트에 사용된 www.microsoft.com 사이트는 총 80대의 서버로 구성되어 있습니다. 4개의 로드밸런싱 된 클러스터로 20대씩 서로 다른 데이터센터에서 구동되고 있지요. 그 중 하나의 클러스터, 즉 20대의 서버를 가지고 자료를 분석하였습니다.

    Hardware: 모델 HP DL585 G1 (4 듀얼 코어 CPU), RAM은 32GB 사용
    OS: Windows Server 2008 RTM (Build: 6.0.6001.18000) 64비트 엔터프라이즈 에디션
    로드밸런싱: 하드웨어 로드밸런싱을 사용함. 로드밸런싱 알고리즘은 "Least Current Client Connections"을 사용하였음 (즉, 클라이언트 커넥션 수가 가장 작은 서버로 요청을 보내는 방식)
    분석방식: 월요일 부터 수요일까지 72시간 동안의 로그를 모니터링함
     


    Posted by 조이트리
    호스팅2008. 6. 30. 17:20

     

    IIS는 CGI(Common Gateway Interface)를 지원했죠. CGI는 IIS가 외부 어플리케이션과 의사소통할 수 있는 표준 기반의 프로토콜입니다. ISAPI도 비슷하게 사용될 수 있죠. 그러나 이 두가지 방식은 약간의 제약이 있었고 이를 해결하기 위해 FastCGI 라는 모듈이 개발되었습니다. 조금 자세하게 살펴보기로 하죠.

    CGI

    CGI는 IIS가 외부 어플리케이션과 인터페이스하기 위한 프로토콜 입니다. 그런데, HTTP는 stateless(상태를 가지고 있지 않음)이기 때문에 HTTP를 통해 들어오는 요청을 처리하기 위해 운영체제에서 새로운 프로세스를 구동하여 외부 어플리케이션의 인스턴스를 만들어야 합니다.
    바로 이 프로세스 내부에는 stdin(스탠다드 입력)이 클라이언트의 요청 데이터를 받고, stdout(스탠다드 출력)은 해당 응답 데이터를 클라이언트로 내보내며 커맨드라인과 운영체제의 환경 변수들이 다른 서버 및 요청들을 CGI 프로세스에 보내기 위해 사용됩니다. IIS에서 CGI를 사용할 때의 단점은 윈도우 운영체제가 프로세스를 만들 때 비교적 자원 소모량이 크다는 것이죠. 모든 HTTP 요청이 새로운 프로세스를 띄우고 CGI 어플리케이션 내부에서 해당 작업을 수행하고, 작업 완료 후 프로세스를 종료하게 됩니다. 따라서, 웹에서의 응답속도가 느려질 수 밖에 없습니다. 쉽게 풀이하면 10개의 요청에 10개의 프로세스가 생성, 종료된다는 것이지요.

    ISAPI

    PHP를 IIS에서 구동될 수 있도록 하기 위해 다양한 시도가 이루어졌고, 그 중 나름대로 성공한 모델이 바로 ISAPI 입니다. ISAPI(Internet Server Application Programming Interface)는 CGI와는 다르게 웹서버 프로세스 내부에서 작업이 이루어집니다. 클라이언트의 요청이 있을 때 새로운 프로세스가 생성되지 않고, 웹서버 프로세스에 로딩된 DLL의 초입 포인트를 Call 하는 방식으로 이루어집니다. 만약, ISAPI 어플리케이션이 운영체제가 Thread를 어떻게 처리하는지를 고려하여 만들어져 있다면 성능이 놀라울 정도로 뛰어납니다. 수년동안 PHP는 CGI와 ISAPI 방식을 통해 구동이 되고 있지만, 두가지 방식은 단점이 있습니다.
    앞에서 말했듯 CGI 방식은 속도가 느리고 ISAPI 방식은 Thread 이슈가 있습니다. 예를들면 PHP가 ISAPI 방식으로 구동될 때 웹서버 프로세스 내에서 멀티 Thread 환경에서 처리가 됩니다. PHP가 Thread-safe 방식으로 구현되었지만, 많은 인기있는 PHP 어플리케이션들은 non Thread-safe 방식으로 이루어져 있습니다. 만약 ISAPI 방식의 PHP 환경에서 non Thread-safe 방식으로 개발된 어플리케이션을 구동하면, 서버가 불안정해지는 위험이 있습니다.

    FastCGI

    FastCGI는 성능과 안정성 모두를 보장합니다. FastCGI 방식을 사용하면 프로세스가 해당 요청을 완료한 이후에도 종료되지 않고 그대로 살아서 다른 요청을 처리합니다. 기존 CGI 방식의 단점인 프로세스 생성 및 종료할 때의 응답 속도 지연이 사라지는 것이죠.

    CGI 방식과 FastCGI 방식의 기술적인 차이는 FastCGI는 stdin, stdout과 CGI 사용하던 자원들에 매핑하는 작업을 수행하는 Layer가 존재한다는 것입니다. 현재 사용되고 있는 CGI 소스코드들은 아주 적은 수정만으로도 FastCGI에서 사용될 수 있습니다. 웹서버가 여러개의 동시 요청을 처리하기 때문에 가용한 프로세스 풀을 가져야 하고, 들어오는 요청들을 처리할 준비를 하고 있어야 합니다. FastCGI 처리기에서는 이 프로세스 풀을 application이라고 부릅니다. (일명 "프로세스 풀") 프로세스 풀의 프로세스의 갯수, 하나의 프로세스가 처리할 요청의 수 등을 설정할 수 있습니다.
    FastCGI 처리기는 여러개의 프로세스 풀을 지원합니다. 하나의 웹서버에서 여러 종류의 FastCGI를 구동할 수 있기 때문이지요. PHP와 Ruby를 동시에 지원하기 원할 경우가 해당 될 것입니다.

    PHP

    PHP에 관해 몇 가지 설명을 해보겠습니다. PHP는 두가지 버전이 있죠, Thred-safe와 non Thread-safe가 바로 그것입니다. Thread-safe 버전은 thread 들이 서로 경쟁하지 않도록 하는 작업이 이루어지므로 반응속도가 느린 반면, non Thread-safe 버전은 응답속도가 빠른 것이 특징입니다. non Thread-safe PHP를 사용하는 경우 php5ts.dll을 디렉토리에서 보실 수 있고, Thread-safe PHP를 사용하신다면 php5.dll을 찾으실 수 있을 겁니다. Apache의 mod_php 또는 IIS 웹서버로 ISAPI를 사용하시려면 thread-safe PHP 버전을 사용하셔야 합니다.

    IIS 웹서버에서 PHP를 사용하시려면 non Thread-safe 방식을 사용하시는 것이 가장 최적의 성능을 제공합니다. www.php.net/download 사이트에 가셔서 PHP5.2.X 버전의 non-Thread safe 바이너리를 다운받으셔서 사용하시면 최적의 환경에서 PHP를 구동하실 수 있습니다.

    이전 글을 보시면 FastCGI 설정에 대해 확인하실 수 있지만, 몇 가지 추가된 내용을 포함하여 다시 글을 써보도록 하겠습니다.

    Posted by 조이트리