PHP 팩터 30 Linux와 Windows의 성능 차이

PHP 팩터 30 Linux와 Windows의 성능 차이

저희 팀은 WordPress 플러그인을 개발하고 있으며, 몇 개의 독립된 서버에서 호스팅된 인스턴스를 제공하고 있습니다.WordPress 설치는 Git에 의해 관리되며, 모든 서버가 동일한 소스 및 WordPress 설정을 가지고 있으며, 데이터베이스 내의 도메인과 실제 데이터만 다릅니다.각 설치에 대해 MySql은 동일한 호스트에서 실행됩니다.WordPress는 각 서버에서만 실행됩니다.

다만, Windows Server 2008 RC2 에 이 설정을 도입하고 나서, 다른 서버에 비해 큰 퍼포먼스의 차이를 알 수 있었습니다.PHP 로 생성된 페이지의 페이지 생성 시간이 평균 400밀리초에서 4000~5000밀리초로 증가했습니다.Apache에서 제공하는 정적 리소스에 대해서만 속도는 리눅스와 거의 동일합니다.

그래서 문제를 좁히기 위해 몇 가지 조치를 취했습니다.

1. 바이러스 대책 소프트웨어가 실행되고 있지 않은지, 또는 다른 Windows 도메인 관련 정보가 간섭하고 있지 않은지 확인합니다.
2. 프로파일링 데이터를 수집하여 스크립트 실행 중 타임킬러를 식별하다
3. 다양한 서버 및 하드웨어 설정 테스트
4. Apache 구성과 PHP 구성 모두에서 명백한 구성 오류가 없는지 다시 확인합니다.

몇 가지 프로파일링 후, 우리는 윈도우 머신에서 정규 표현에 대한 평가가 끔찍하게 느리다는 것을 금방 알아차렸습니다.10, 평가 (,000 정규 표현preg_matchLinux 에밀90 、 Windows 에3000 、 linux linux linux linux linux 。

프로파일링, 시스템 테스트 및 구성에 대한 자세한 내용은 다음과 같습니다.이 스크립트를 최적화하고 싶지 않습니다(실제로 이 방법을 알고 있습니다). Windows에서 Linux와 거의 같은 속도로 스크립트를 실행할 수 있도록 하고 싶습니다(opcache/...에 대해서는 같은 설정으로 합니다).스크립트의 메모리 설치 공간도 최적화할 필요가 없습니다.

업데이트: 시간이 지나면 시스템의 메모리가 부족해져 메모리 예외와 랜덤 할당이 트리거됩니다.자세한 내용은 아래를 참조하십시오.Apache/PHP를 재기동하면, 현시점에서는 문제가 해결되었습니다.

: " " "_get_browser 말합니다

File (called from)
require wp-blog-header.php (index.php:17)
wp (wp-blog-header.php:14)
WP->main (functions.php:808)
php::do_action_ref_array (class-wp.php:616)
php::call_user_func_array (wp-includes/plugin:507)
wp_slimstat::slimtrack  (php::internal (507))
wp_slimstat::_get_browser (wp-slimstat.php:385)

업데이트 2: PHP를 서버에서 Apache 모듈로 활성화한 것을 기억할 수 없는 이유가 있습니다(같은 이유로 성능이 저하됨).그러나 오늘날에는 매우 빠르게 실행됩니다(요청당 1초).Opcache를 추가하면 최대 400ms/req로 감소합니다.Apache/PHP/Windows는 그대로였다.

1) 프로파일링 결과

프로파일링은 모든 기계에서 XDebug를 사용하여 수행되었습니다. 몇 했는데, 이상)이를 알 수 있을 했습니다. : 통통몇 몇몇 몇 usually usually usually usually usually usually usually usually usually usually usually usually usually 。 대부분의 시간(50% 이상)이 소비된 위치를 밝히기에 충분했습니다. 방법[get_browser][1] 플러그인의 WordPress 러 of of of 。wp-slimstats:

protected static function _get_browser(){
    // Load cache
    @include_once(plugin_dir_path( __FILE__ ).'databases/browscap.php');
    // browscap.php contains $slimstat_patterns and $slimstat_browsers

    $browser = array('browser' => 'Default Browser', 'version' => '1', 'platform' => 'unknown', 'css_version' => 1, 'type' => 1);
    if (empty($slimstat_patterns) || !is_array($slimstat_patterns)) return $browser;

    $user_agent = isset($_SERVER['HTTP_USER_AGENT'])?$_SERVER['HTTP_USER_AGENT']:'';
    $search = array();
    foreach ($slimstat_patterns as $key => $pattern){
        if (preg_match($pattern . 'i', $user_agent)){
            $search = $value = $search + $slimstat_browsers[$key];
            while (array_key_exists(3, $value) && $value[3]) {
                $value = $slimstat_browsers[$value[3]];
                $search += $value;
            }
            break;
        }
    }

    // Lots of other lines to relevant to the profiling results
  }

의 PHP와 합니다.get_browser합니다. 실행 은 이 실행 됩니다.foreach 그 「」, 「」의 를 실시합니다.preg_match(1,000엔~8,000엔).에에 、 Linux 、 90 、 Windows 、 3000 、 3000밀밀밀밀밀밀밀밀밀밀밀 。결과는 테스트된 모든 설정에서 동일했습니다(그림은 2개의 실행 데이터를 보여줍니다).

네, 2개의 대용량 어레이를 로드하는 데 시간이 걸립니다.정규 표현도 평가합니다.그러나 Linux와 Windows에서는 거의 같은 시간이 소요될 것으로 예상됩니다.이것은 Linux VM에서의 프로파일링 결과입니다(1페이지 요청만).차이는 매우 명백합니다.

Object-Cache WordPress가 실제로 사용하는 또 다른 시간적 요인:

function get( $key, $group = 'default', $force = false, &$found = null ) {
    if ( empty( $group ) )
        $group = 'default';

    if ( $this->multisite && ! isset( $this->global_groups[ $group ] ) )
        $key = $this->blog_prefix . $key;

    if ( $this->_exists( $key, $group ) ) {
        $found = true;
        $this->cache_hits += 1;
        if ( is_object($this->cache[$group][$key]) )
            return clone $this->cache[$group][$key];
        else
            return $this->cache[$group][$key];
    }

    $found = false;
    $this->cache_misses += 1;
    return false;
}

시간은 이 기능 자체(3개의 스크립트 실행) 내에서 소요됩니다.

Linux의 경우:

각 번역은메모리에서 로드되며의 0.2ms에서4ms까지의 임의의값을 .

Linux의 경우:

2) 테스트 완료 시스템

가상화 또는 Apache가 이에 영향을 미치는지 확인하기 위해 여러 설정에서 테스트했습니다.안티바이러스 기능이 모든 설정에서 비활성화되었습니다.

• Linux Debian, Apache 2 및 PHP를 최신 안정적인 릴리스로 제공합니다.이는 스테이징/라이브 서버와 마찬가지로 가상 머신에서 실행 중인 개발자도 마찬가지입니다.바람직한 퍼포먼스의 기준 시스템으로서 기능합니다.사무실 또는 호스팅 제공(공유 공간)에서 실행할 수 있습니다.Windows Systems의 RAM은 4GB에서 8GB 사이이며 메모리 사용량은 항상 50% 미만이었습니다.가상화는 Windows와 Apache를 동시에 실행할 수 없습니다.
• T-시스템즈(VMWare Player), Life-Server
  • 2008년 R2를 획득.Apache 2.2.25 + PHP 5.4.26 NTS, VC9(fastcgi 모듈)
  • 2008년 R2를 획득.Apache 2.2.25 + PHP 5.5.1 NTS, VC11을 fastcgi 모듈로 사용
  • 2008년 R2를 획득.Apache 2.2.25 + PHP 5.5.1 NTS, VC11을 Apache 모듈로 사용
  • Apache 모듈로서의 Win 2008 R2, Apache 2.2.25 + PHP 5.5.11 TS, VC11 (업데이트 2에서 언급한 가장 빠른 모듈)
• 호스트: OpenSuse, 가상화: VMWare Player(@T-Systems)「 」 、 「 」 、 「 」 、 「 」 、 「 」 。
  • 2008년 R2를 획득.Apache 2.2.25 + PHP 5.4.26 NTS, VC9(fastcgi 모듈)
  • 2008년 R2를 획득.IIS7 + PHP 5.4.26 NTS, VC9 (wincache 유무에 관계없이)
  • 2012년 우승IIS * + PHP 5.5.10 NTS, VC11을 fastcgi 모듈로 사용(wincache 유무)
• 가상화를 사용하지 않는 로컬 머신에서
  • 2008년 R2를 획득.Apache 2.2.25 + PHP 5.4.26 NTS, VC9(fastcgi 모듈)

상기와 같은 프로파일링 결과는 다른 시스템에서도 동일합니다(최대 10%의 파생).윈도우즈는 항상 Linux보다 느린 중요한 요소였습니다.

Word Press & Slimstats를 새로 설치해도 거의 같은 결과를 얻을 수 있습니다.코드 재작성은 여기서 할 수 없습니다.

업데이트: 한편, 이 완전한 스택이 매우 빠르게 실행되는 다른 두 개의 Windows 시스템(Windows 2008 R2, VM 및 물리 시스템)을 발견했습니다.같은 설정입니다.

업데이트 2: Life-Servers에서 PHP를 아파치 모듈로 실행하는 것이 fastcgi 메서드보다 약간 더 빨랐습니다.최소 2초, 50% 더 적습니다.

메모리 부족

시간이 지나면 Live-Server가 전혀 작동하지 않고 메모리 부족 예외가 발생합니다.

PHP Fatal error:  Out of memory (allocated 4456448) (tried to allocate 136 bytes)
PHP Fatal error:  Out of memory (allocated 8650752) (tried to allocate 45 bytes) 
PHP Fatal error:  Out of memory (allocated 6815744) (tried to allocate 24 bytes) 

이 문제는 랜덤 스크립트 위치에서 발생합니다.스크립트에서는 메모리를 할당할 수 있지만 Zend Memory Manager에서는 메모리를 할당할 수 없습니다.사고 발생 시 서버의 빈 RAM은 약 50%(2GB 이상)였습니다.따라서 서버의 RAM이 실제로 부족하지는 않습니다.Apache/PHP 를 재기동하면, 현시점에서는 이 문제가 해결됩니다.

이 문제가 성능 문제와 관련이 있는지 잘 모르겠습니다.다만, 양쪽의 문제가 기억과 관련 있는 것 같기 때문에, 여기에 기재되어 있습니다.특히, 적절한 퍼포먼스를 실현한 Windows-Tests 의 설정을 재현합니다.

3) Apache 및 PHP 구성

...아마 일반적인 함정은 없을 것이다.Output-Buffering이 네이블(기본값), 멀티바이 오버라이드 디세이블...관심 있는 옵션이 있으면 기꺼이 제공해 드리겠습니다.

의 httpd.exe -V

Server version: Apache/2.4.7 (Win32)
Apache Lounge VC10 Server built:   Nov 26 2013 15:46:56
Server's Module Magic Number: 20120211:27
Server loaded:  APR 1.5.0, APR-UTIL 1.5.3
Compiled using: APR 1.5.0, APR-UTIL 1.5.3
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
    forked:     no
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SUEXEC_BIN="/apache/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error.log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

mpm_winnt_module★★★★

<IfModule mpm_winnt_module>
    ThreadsPerChild 150
    ThreadStackSize 8388608 
    MaxConnectionsPerChild 0
</IfModule>

php.ini 발췌:

realpath_cache_size = 12M
pcre.recursion_limit = 100000

4) 현재 의심되는 이유

오래된 전제 조건:

이 세 가지 예 모두 대규모 어레이와 문자열 작업에 크게 의존하고 있습니다.어떤 종류의 것이 공동 공장인 것 같습니다.Linux 에서는 실장이 정상적으로 동작하고 있기 때문에, Windows 에서는 메모리상의 문제가 있을 가능성이 있습니다.핀 포인트의 로케이션에서는, 데이타베이스의 조작이 행해지지 않는 한, 데이타베이스나 서버<->PHP 통합의 문제는 아닌 것으로 생각됩니다.PHP의 메모리 상호 작용이 느린 것 같습니다.Windows 의 메모리에 간섭하는 사람이 있기 때문에, 액세스 속도가 큰폭으로 저하하고 있는 것은 아닐까요.

오래된 전제 조건 2:

다른 Windows 머신에서도 같은 스택이 정상적으로 동작하고 있기 때문에, Windows 설정의 어딘가에 문제가 있다고 생각됩니다.

새로운 전제 조건 3:

사실 나는 짐작이 가지 않는다.PHP가 아파치 모듈로서 fastcgi만큼 느리게 실행되는 이유는 무엇입니까?>

이 문제를 검증하거나 여기서 진짜 문제를 찾는 방법에 대한 의견이 있습니까?이 문제를 해결하기 위한 어떠한 도움이나 지시도 환영합니다.

Windows 에는, 모든 상황에서 컴퓨터의 사용의 제한, 방지, 보호, 제어등의 서비스/정책이 다수 준비되어 있습니다.

Microsoft 인증을 받은 우수한 전문가는 몇 분 안에 질문을 해결할 수 있습니다. 왜냐하면 그들은 PHP 스크립트가 더 빨리 실행되도록 어떤 설정/서비스/정책을 확인하고 비활성화/활성화/변경해야 하는지 정확하게 지시할 수 있기 때문입니다.

메모리 상으로는 RAM, 하드 드라이브 액세스, 환경 변수, 제한, 보안(방화벽 등)에 관한 모든 것을 체크할 것을 권장합니다.php 스크립트의 실행에 영향을 줄 수 있는 모든 것. Remote Procedure Call 정책에서 시작하여 운영 스택 메모리로 끝납니다.

이 논리는 php.exe가 외부 .dll 파일을 호출하여 작업을 실행한다는 것입니다.OS가 실행하는 도중에 체크가 있을 수 있기 때문에 이러한 .dll을 통해 요청을 보내는 것과 응답을 받는 것이 모두 느려집니다..dll이 하드 드라이브를 사용하여 무언가에 액세스하는 경우 - 하드 드라이브 액세스 정책이 화면에 표시됩니다.또한 RAM 또는 RAM의 하드 드라이브 캐시에서 모든 것이 메모리에 어떻게 배치되어 있는지에 대해서도 설명합니다.응용 프로그램정책정책을 스레드합니다.응용 프로그램에 사용할 수 있는 최대 비율 제한.

Windows 베이스의 호스트가 나쁘다고는 할 수 없습니다.일반 관리자에 대해서, 올바르게 셋업 하는 것이 훨씬 더 어렵다고 하는 것입니다.Microsoft 스페셜리스트가 있으면, Linux 베이스의 서버와 같은 속도로 서버를 조정할 수 있습니다.

• APC 활성화(PHP5.4 사용 시)

  • APC가 켜져 있을 때 속도 향상을 눈치채지 못할 경우 뭔가 잘못 설정되어 있습니다.

    [APC] extension=php_apc.dll apc.enabled=1 apc.shm_segments=1 apc.shm_size=128M apc.num_files_hint=7000 apc.user_entries_hint=4096 apc.ttl=7200 apc.user_ttl=7200

• PHP 5.5에서 Zend Opcode 사용

  [Zend] zend_extension=ext/php_zend.dll zend_optimizerplus.enable=1 zend_optimizerplus.use_cwd=1 zend_optimizerplus.validate_timestamp=0 zend_optimizerplus.revalidate_freq=2
zend_optimizerplus.revalidate_path=0 zend_optimizerplus.dups_fix=0 zend_optimizerplus.log_verbosity_level=1 zend_optimizerplus.memory_consumption=128 zend_optimizerplus.interned_strings_buffer=16 zend_optimizerplus.max_accelerated_files=2000 zend_optimizerplus.max_wasted_percentage=25 zend_optimizerplus.consistency_checks=0 zend_optimizerplus.force_restart_timeout=60 zend_optimizerplus.blacklist_filename= zend_optimizerplus.fast_shutdown=0 zend_optimizerplus.optimization_level=0xfffffbbf zend_optimizerplus.enable_slow_optimizations=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 opcache.enable_cli=1

• Wordpress 확장자를 단계적으로 비활성화하여 메모리 사용량 몬스터를 찾습니다.

• Word press: 레 set set set set set set set set:define('WP_MEMORY_LIMIT', '128M'); 이미지 한
• 메모리를.ini php.ini로 설정합니다.ini_set('memory_limit', -1);
• Xdebug를 실행하지 않은 프로파일은 미친 소리 같지만 디버거 자체가 큰 영향을 미칩니다.
• memory_get_usage.
• 를 주다zend.enable_gc=1. 스크립트는 느려지지만 메모리 사용량은 줄어듭니다.
• SlimStats 설정에서 사용자 브라우저 체크를 비활성화하면 됩니다.
• 이것이 불가능할 경우 SlimStats getBrowser() 함수를 더 빠른 getBrowser() 대체로 덮어씁니다.
• user-agent fetcher의 속도 비교에 대해서는http://https://github.com/quentin389/ua-speed-tests 를 참조해 주세요.
• https://github.com/garetjax/phpbrowscap

Github에 있는 플러그인을 살펴봤습니다.

https://github.com/wp-plugins/wp-slimstat

문제가 되는 파일은 어느 정도 축소된 파일이며 실제로는 데이터(코드 아님)이며 각각 약 400KB의 5가지 종류가 있습니다.

maxmind.dat 파일도 400KB인데 둘 다 사용하는지는 모르겠습니다.

이전 버전의 플러그인 버전 3.2.3을 사용하고 있으며 문제를 해결할 수 있는 훨씬 새로운 버전이 있습니다.

작성자든 git 이력을 정리하지 않은 사람이든 비교가 어려워서 파일을 수동으로 구분해야 했습니다._get_browser와 관련된 변경의 대부분은 캐시를 추가하는 것 같습니다.

그 파일을 로드하는 것이 느린 것은 가능하지만, I/O 캐싱이 동작하고 있다면 PHP는 양쪽 플랫폼에서 비슷한 속도로 두 파일을 로드하게 될 것입니다.

편집 조금 더 자세히 살펴봐도 문제가 해결되지 않을 수 있습니다.이러한 파일은 기본적으로 큰 정규 표현 룩업 테이블입니다.Linux 시스템에 APC 캐시가 있는데 이 시스템에는 없습니까?APC 캐시는 (컴파일된 regex 패턴은 아니지만) PHP 파일 데이터를 캐시된 상태로 유지합니다.

(TCP 소켓이 아닌) UNIX 소켓을 통해 PHP에 NGINX 및 FCGI를 사용합니다.

http://wiki.nginx.org/PHPFcgiExample

액셀러레이터가 없어도 즉시 개선 속도를 알 수 있습니다.또, 상기의 설정에서는, 메모리 사용 면적이 큰폭으로 삭감됩니다.

이 문제의 트러블 슈팅에 도움이 되는 툴에는 sysinternals 스위트가 있습니다.http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

그러면 실행 중인 프로세스에 대해 상세 디버깅을 수행할 수 있습니다.이 문제는 php 런타임에 따라 스레드 안전과 관련이 있을 수 있습니다.

참조: https://learn.microsoft.com/en-us/iis/application-frameworks/running-php-applications-on-iis/best-practices-for-php-on-the-microsoft-web-platform#use-a-non-thread-safe-build-of-php

마지막으로 상기 기사는 IIS, Windows Server 2008 이상에서의 php 퍼포먼스 최적화에 관한 것입니다.

언급URL : https://stackoverflow.com/questions/22845321/php-factor-30-performance-difference-from-linux-to-windows