Extra Form
PHP PHP 7.2
CMS Rhymix

실력이 미천하여 질문만 계속 올리네요. 일단 죄송합니다.

 

Windows + NginX + PHP 7.2.12 + Rhymix 서버입니다.

 

가끔씩 게시판 로딩이 지나치게 느려지는 경우가 발생합니다.

(질문 검색해봤는데 완전히 동일한 내용은 없어서 질문 올립니다.)

 

클릭 후 빨리 열리는 경우는 1초 내외로 열리는데,

느려지는 경우는 15 ~ 20초 까지도 순간적으로 느려지네요.

(개인 서버라 사용자는 없다고 봐도 됩니다.)

 

캐쉬는 opcache / memecache 사용중입니다.

 

XE에서 버전업한 건 데, 기존에는 가끔 느려도 이렇게까지 느리진 않았던 거 같아서요.

혹시 해서 질문 올립니다.

도무지 뭘 뒤져봐야 할 지 모르겠네요.

 

이런 식 입니다.

Query Time을 보면 DB에서 읽어오는 건 큰 문제 없는 거 같습니다.

error_01.jpg

 

error_02.jpg

 

error_03.jpg

 

혹시 잘못 설정되었거나 살펴볼만한 내용이 있다면 알려주시면 좋겠습니다.

감사합니다.

 

  • profile

    디버그에 그것밖에 안 나올 리가 없습니다. 답변에 필요한 정보를 일부러 잘라내셨거나, 시스템 설정 → 디버그 설정 메뉴에서 느린 트리거, 느린 외부 요청 등 원인 파악에 도움이 될 만한 항목을 모두 꺼놓으신 것 같네요.

  • profile ?

    아닙니다.
    저거 밖에 안 나왔습니다. 느린 트리거 / 느린 외부 요청 등 다 켜져 있는 상태입니다.

    느린 트리거 같은 게 로그로 나왔으면 제가 함께 문의로 올렸을겁니다.

     

    error_04.jpg

    error_05.jpg

     

    이렇게 밖에 안 나옵니다...

     

  • ? profile

    느린 트리거, 위젯, 외부 요청 등의 기준을 쿼리와 마찬가지로 0.05초 정도로 낮춰보세요. 각각의 항목은 1초 미만인데 여러 번 반복해서 10초가 걸릴 수도 있습니다.

  • profile ?
    말씀하신 대로 변경해봤는데(모든 항목 0.05초),
    추가로 나오는 로그는 없고 기존과 동일하게
    Total Time만 길게 나오는 상황입니다.

    이런 경우 혹시 어느 부분을 디버깅해야 잡을 수 있을까요... 뭔가 손댈 수 없어서 굉장히 답답하네요...
  • ? profile
    추가 항목이 하나도 안 나온다면 아예 디버그 기능에 문제가 있을 가능성도 생각해 봐야겠네요.
    패널이 아닌 소스에 표시하거나 파일에 기록하도록 하면 혹시 뭐가 나오나요?
  • profile ?

    소스와 파일에 기록하도록 해봤습니다.

    두 개 다 기록된 내용은 동일하네요.

     

    Total Time이 10초 이상으로 느리게 나온 경우입니다.

     

    error_06.jpg

     

    <!--
      [2018-12-05 10:02:19]
       
      Request / Response
      ==================
      Request URL: https://-개인서버라 지웠습니다.
      Request IP Address: ----
      Request Method: GET
      Request Body Size: 0
      Response Method: HTML
      Response Body Size: 167436
       
      Page Generation Time
      ====================
      Total Time: 0.3744 sec
      Template Compile Time: 0.2751 sec (count: 7)
      XML Parsing Time: 0.0100 sec
      DB Query Time: 0.0080 sec (count: 25)
      DB Processing Time: 0.0540 sec
      Layout Processing Time: 0.0041 sec
      Widget Processing Time: 0.0000 sec
      Remote Request Time: 0.0000 sec
      Content Transform Time: 0.0012 sec
       
      Resource Usage
      ==============
      Peak Memory Usage: 4.0 MB
      Included Files: 155
       
      Debug Entries
      =============
      None
       
      PHP Errors and Warnings
      =======================
      None
       
      Slow Queries
      ============
      None
       
      Slow Triggers
      =============
      None
       
      Slow Widgets
      ============
      None
       
      Slow Remote Requests
      ====================
      None
       
      -->
     

     

    이런 경우 cms보다는 서버 쪽의 문제일 가능성이 큰가요?

    어디를 확인하거나 찍어봐야 알 수 있을지 잘 모르겠네요.

     

    뭐라도 도움될만한 거 던져주시면 제가 좀 더 뒤져보겠습니다.

     

  • ? profile

    디버그에 잡히지 않는 부분 중 어딘가 느린 곳이 있는 모양이네요. 희귀한 경우인데요...

    nginx라면 PHP-FPM으로 연동하고 계시지요? PHP-FPM에 slow log 기능이 있습니다.
    slow log 기준을 10초로 해놓고 로그 파일명을 지정하면
    실행 시간 10초가 경과하는 시점에 어느 파일의 어느 함수를 실행하고 있었는지 기록됩니다.
    라이믹스 디버그처럼 친절하게 나오지는 않지만 꽤 쓸모있는 정보입니다.

     

    느린 곳이 여러 군데 있을지도 모르니 5초, 10초 등으로 설정을 바꿔가며 모두 찾아보는 것도 좋습니다.

    아주 느린 애드온이 9초 동안 실행된 후 10초째에는 아무 문제 없는 다른 애드온이 억울하게 걸릴 수도 있어요.

  • profile ?
    windows의 php-cgi.exe에서는 php-fpm용 slowlog를 지원하지 않는 것 같습니다.
    여러 모로 찾아봤는데 방법이 없네요. 어떻게 enable해서 로그를 잡을 수 없는 것 같아요...
    (당연히 error_log 같은 건 다 확인했는데 아무 것도 안 뜹니다....)

    그래서 nginx와 php 관련해서도 이렇게 저렇게 검색해봤는데... 도무지 모르겠네요.
    phpinfo 같은 건 잘 뜨는 걸 봐선... 서버 쪽 문제는 아닐지도 모르겠다는 생각이 들고...

    XE+Rhymix 게시판도 잘 뜰 때는 0.5~0.6s 안에 페이지 로딩이 완료되고,
    알 수 없이 느려질 때가 있는데 그 때가 보통 10 ~ 20s 사이에 뜨고 있습니다.

    같은 항목이라도 빠를 때도 느릴 때도 있는 걸로 봐선 딱히 항목의 문제도 아닌 것 같고...
    뭔가 제가 놓치고 있는 부분이 있는 것 같은데....
    이해를 못 하겠는 게 거의 동일한 서버 구성으로 XE 사용할 때는 이렇게까지 느리진 않았거든요...
    항상 100% 느리다 그러면 이거 뭔가 서버 문제일 수 있겠다 싶은데,
    그것도 아니라서... =ㅅ=;;; 어디를 어떻게 손봐야 할 지 도통 모르겠네요...

    게시판의 document를 만들어내는 시작과 끝 지점이 어디일까요?
    시작 지점부터 끝 지점까지 쫓아가면서 하나하나 확인해야 할 것 같다는 생각이 듭니다.
    느낌은 어딘가에서 Hang이 딱 걸렸다가 풀리면서 로딩되는 거 같은 느낌인데...

    딱히 추가로 사용하는 애드온이나 모듈도 없거든요(이번에 올리면서 하나하나 다 지웠어요...).
    제가 추가해서 쓰는 건 imageprocess 모듈이랑 contentextended / contentslist 위젯이랑
    sketchbook5 레이아웃이랑 게시판 스킨 정도거든요....
    (각각 약간씩 고친 상태인데 딱히 영향 줄 부분은 없을 거 같긴 하지만요...)

    뭐라도 좀 더 던져주시면 더 체크해보겠습니다.
    여러모로 귀찮게 해드려 죄송합니다.
  • ? profile

    혹시 하드디스크 상태가 랜덤하게 안좋거나 해서 io가 병목이 생기거나 하는건 아닐까요.. 아니면 네트워크가 불안정하거나요.. 저는 서버나 프로그램쪽은 지식이 없어 사이트를 운영하는 입장에서 그냥 생각나는게 이거라 적어봤습니다.

     

    3-4초도 아니고 10초 정도면 굉장히 특이하게 지연이 오래 생기는거고 XE,라이믹스 또는 서드파티프로그램 문제로 접하기 힘든 경우 같습니다.

  • profile ?
    웹서버는 ssd에서 돌고 있습니다. nginx및 php는 분리된 ssd에서 돌고 있구요...

    네트워크 불안정.... 음 그럴 수도 있을 거 같긴 합니다만....
    뭔가 로드를 많이 거는 상황도 아니고.... 도무지 모르겠네요...

    어쨌든 지연이 발생하는 상황을 보면 document를 만들어내는 부분에서 느려지는 것 같아서요...

    아무 정보라도 던져주시면 제가 찾아보도록 하겠습니다.
    뭐든지 감사합니다.
  • ? profile
    보통 게시글 열람 페이지에 위젯을 통해 많이 db에서 불러오거나 하지 않는 일반적인 게시글 열람하는 정도면 수백ms 이내에 끝납니다. 지금 뭔가 서버쪽이나 혹은 다른 문제가 있을 가능성이 높습니다.
  • profile ?
    그러게요... =ㅅ=a 저도 그렇게 알고 있는데....
    위에도 적었던 것처럼 대부분의 게시물은 0.5~1s 초 정도면 다 열리거든요....
    같은 게시물이나 게시판이 가끔씩 느리게 열리는 게 문제라서요...

    서버도 사실 뭐 별로 특별할 게 없어서.... =ㅅ=;;;;; 그러니 답답한 거죠...

    어디서 지연되는 것인지 알아야 그걸 한 번 파볼텐데요....

    참 답답하네요... 어디서부터 어디까지 확인해야 하는 건지 모르니...
  • ? profile

    제가 보기엔 XE던 라이믹스던 그정도 구성이면 프로그램에서 문제를 일으킬 확율은 제로에 가깝다고 생각합니다. XE로 7년 가까이 사이트를 운영하고 있는 경험적인 생각입니다.

    물론 라이믹스에서 윈도우서버를 공식적으로 지원하지 않는 것이라 라이믹스에서 발생하는 변수는....

  • ? profile

    혹시 curl을 사용하여 외부에 요청을 하는 애드온이나 모듈 등이 있다면 해당 부분을 지워보세요.
    FileHandler::getRemoteResource() 함수로 외부 요청을 하면 디버그에 찍히지만
    서드파티 자료가 curl을 사용하여 임의로 외부 요청을 하면 코어에서는 알 길이 없습니다.
    외부 요청이 랜덤으로 10초씩 지연되거나 타임아웃에 걸리고 있을지도...?

     

    캐시를 적용해 놓은 위젯이 있다면 해당 위젯 캐시가 갱신될 때마다 느려지고 있을 가능성도 있습니다.

    만약 위젯 캐시를 모두 0으로 설정했을 때 증상이 더 심해진다면 위젯 문제입니다.

    (슈퍼 캐시 모듈 사용시 이 테스트에 방해가 될 수도 있습니다.)

    slowlog를 사용할 수 없다면 XDebug를 사용하는 방법도 있는데,
    XDebug 자체가 느려지는 주범인데다 로그를 바로 열람할 수 있는 것이 아니라서;;;

    버츄얼박스 등을 사용해서 정상적인(=리눅스) 서버 환경을 구성하는 것이 오히려 더 쉬울 수도 있습니다.
    당장 해결되지는 않더라도 문제 파악은 훨씬 쉬워지겠네요 ㅎㅎ

  • profile profile
    딱히 추가로 사용하는 애드온이나 모듈도 없거든요(이번에 올리면서 하나하나 다 지웠어요...).
    제가 추가해서 쓰는 건 imageprocess 모듈이랑 contentextended / contentslist 위젯이랑

    ---------------------------
    위 댓글 중 내용.
    아주 날것의 상태 입니다. 특히 게시글 열람시에는 어느 서드파티도 관여하지 않구요...
  • profile profile
    ...라고 하시는 분들 중 실제로는 이것저것 많이 설치되어 있는 경우도 많아서... ㅋㅋ
  • profile ?
    윈도우에서가 관리가 편해서 일단 윈도우 서버를 사용하고는 있는데,
    이 문제가 잘 해결되지 않는다면 리눅스 서버를 깔아서 옮기는 것도 생각해봐야겠습니다.
    (물론 그 전에 어떤 식으로든 문제점을 찾아서 고치면 더 좋구요....)

    위에도 적었다시피 특별한 애드온이나 모듈을 추가해서 사용하지 않고 있습니다.
    서버 문제는 아닐 가능성이 높아 보입니다(다른 테스트 테스트 용도의 php 등은 금새 열립니다).

    현재 제가 생각해볼 수 있는 어떤 식으로든 cache 설정이 뭔가 영향을 준다든지...
    특정 서버 설정이랑 Rhymix랑 뭔가 안 맞는 상태가 있다든지...
    그 정도가 아닐까 싶은데요...

    아래 웹지기님이 써주신 것처럼....
    제가 일부 고친 소스들 말고는 거의 날 것의 서버 상태라서 =ㅅ=;;;;

    아 전혀 감이 안 오네요...

    혹시 위에서 문의 드린 내용에 대한 간단한 가이드 주실 수 있나요?
    외부에서 요청이 와서 Rhymix에서 Document를 생성하기 시작하는 위치랑
    생성이 끝나서 다시 돌려주는 위치를 알려주시면
    미천한 실력이지만 제가 한 번 디버그를 넣어서 쫓아가볼까 합니다.
    현재로서는 전혀 감이 안 잡혀서요....

    뭐 어떤 의견이라도 감사합니다.
  • ? profile

    Document를 생성하기 시작하고 끝낸다는 것은 의미있는 구분이 아닙니다. 한 화면에 관여하는 Document가 한두 개도 아니고... 지금 읽고 있는 문서 / 하단 목록의 문서들 / 우측 위젯의 문서들 등등 불러오는 경로도 다 다르니까요. (웹페이지 자체를 Document라고 부르신다면 더더욱 답이 없고요.)

  • profile ?
    알겠습니다. 뭐 딱히 수가 없네요.

    저는 좀 더 방법을 찾아보고 혹시 해결하게 되면 다시 댓글달러 오겠습니다.
    해결 못 하면 ... ㅎㅎㅎ 아마도 리눅스 서버로 갈아탈지도 모르겠네요.

    어쨌든 많은 답글 정말 감사합니다.
  • profile ?
    이것저것 해보다가 뭔가 원인을 찾은 것 같아서 답글 적습니다.

    일단 서버나 네트워크단 지연 문제일 수 있어서 그 부분을 확인해보니,
    네트워크는 계속 ping을 검사해서 확인해보니 반응에 문제가 없었고...

    NginX의 access log를 변경해서 upstream request time / upstream connect time / upstream header time / upstream response time 등을 확인해보니,
    upstream header time 즉, php fastcgi에서 처음 데이터를 읽어오는 게 느려지는 게 문제였습니다.

    [06/Dec/2018:15:41:29 +0900] - client=xxx.xxx.xxx.xxx method=GET request="GET /board_xxx HTTP/2.0" request_length=43 status=200 bytes_sent=27562 body_bytes_sent=27257 referer=xxx user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" upstream_addr=127.0.0.1:xxxx upstream_status=200
    request_time=13.767 upstream_connect_time=0.000 upstream_header_time=13.767 upstream_response_time=13.767

    그래서 일단 서버 설정 자체는 문제가 없다고 판단하고 PHP 디버깅을 위해
    Xdebug 설정을 해서 cachegrind.out 파일을 열어봤는데(역시 XE 기반은 복잡하긴 하군요...),
    이것도 상대적인 시간이 %로 나오는 거라 절대적으로 느려지는 걸 모르겠더라구요.

    그래서 PHP 설정값이나 Cache가 문제일 수 있을 듯 해서...
    zend opcache랑 memcache를 일단 사용하지 않게 변경하니,
    동작 속도가 일정하게 바뀌었습니다.

    둘 다 다시 enable 시켰는데 여전히 속도가 괜찮아서 확인해보니,
    session.save_path를 memcache로 해놓았는데,
    정확한 이유는 모르겠지만(sesstion locking??? 또는 memcache와 php 7.2 호환성 문제?),
    이 부분이 문제인 거 같더군요.

    설정은 이렇게 되어 있었구요...
    session.save_handler = memcache
    session.save_path = "tcp://127.0.0.1:11211"

    memcache 버전은 3.0.9-dev 입니다.

    위에 session 저장을 files로 변경하니 가끔씩 엄청나게 느려지는 현상 자체는 없어진 것 같습니다.
    그래서 좀 검색을 해보니...
    http://php.net/manual/en/book.memcache.php
    Note that the Memcache 3.0.8 module DOES NOT WORK WITH PHP 7 (or higher)

    저랑 거의 같은 증상인데 memcached 관련 문제도 있었더군요(패치된 듯).
    https://stackoverflow.com/questions/44686752/issue-with-memcached-with-session-storing

    session locking 관련해서 이런 글도...
    https://ma.ttias.be/php-session-locking-prevent-sessions-blocking-in-requests/


    아휴 이 분야 전문가가 아니어서 잘 모르겠네요....
    일단은 memcached로 변경해보든지 그냥 두든지 다른 방법을 찾아봐야겠습니다.

    일단 결론은....
    php.ini에서 session을 memcache에 저장했더니 가끔씩 느려진다는 것입니다.

    이 글은 참고로 남겨놓겠습니다.
    여러 모로 답변 달아주셔서 감사합니다.
  • ? profile

    upstream header time이 길다는 것은 그냥 PHP가 한참 걸린다는 뜻입니다.

    session_start()에서 락이 걸리고 있었다면 디버그에 잡히지 않았을 가능성이 충분히 있네요. 호환되지 않는 버전의 확장모듈을 세션 핸들러로 사용하고 있었다면 이상하게 작동하더라도 놀랄 일이 아니고요. 윈도우 서버에서 자잘한 문제가 많은 이유 중 하나가 바로 이렇게 호환성이 검증되지 않은 DLL 파일을 적당히 찾아서 다운받아 설치하는 관례 때문입니다. 리눅스는 현재 설치된 버전과 호환되는 것을 알아서 찾아주거든요. (참고로 PHP에서 멤캐시와 연동하는 확장모듈은 두 종류가 있습니다. 하나는 memcache이고 다른 하나는 memcached인데, 세션 핸들러로 사용할 경우 설정 방법이 다르기 때문에 혼동하기 쉽습니다.)

    최신 버전의 확장모듈들은 PHP 7에서도 잘 돌아갑니다만, 세션 핸들러로 사용하기에는 여전히 좀 문제가 있어서 저도 사용을 권장하지 않고 있습니다. 소규모 사이트라면 기본값인 files 세션 핸들러를 사용하시고, 중~대규모 사이트라면 Redis가 오히려 나아요.

  • profile ?
    Redis를 쓸 정도로 큰 규모는 아닙니다. 그냥 당분간은 files를 사용할 예정입니다.

    말씀하신 것처럼 windows에서는 호환성 검증이 안 된 dll 파일을 확장모듈로 다운받아 쓸 수 밖에 없는 상황이라(아니면 직접 일일이 빌드 툴을 깔아서 빌딩을 해야만 사용할 수 있기 때문에...),
    현재로서는 별 방법이 없네요.

    그 점에서는 분명히 리눅스가 우위에 있으며, 저도 서버는 당연히 리눅스가 낫다고 생각합니다.
    다만 제가 좀 편하고자 하다보니... =ㅅ=;

    어쨌든 문제가 해결되니 좋네요(이전엔 session을 memcache에 저장해도 괜찮았던 것 같은데.. 아쉽네요).

    앞으로도 개발 잘 부탁 드립니다.
    감사합니다.