제목처럼 Opcache가 오히려 속도를 느리게 할 수 있나요?
Opcache를 적용했더니 때떄로 TTFB가 10초 이상 걸릴 때가 있습니다.
제가 생각하기론... 장시간 접속이 없는 사이트는 Opcache가 비워지고,
다시 접속할 때, Opcache가 캐싱하는 과정에서 시간이 많이 소요되는 거 같습니다.
제가 생각한 게 맞는지....
그렇다면 이런 현상을 막을 방법은 없는가요?
-
-
Opcache를 비활성화 하면 TTFB가 300ms안입니다.
서버의 여러 사이트 중 몇 개가 방문자가 드문데, Opcache를 쓰니까 이런 일이 발생하네요... -
그러니까.. Opcache 쓴다고 평상시 때에 따라 10초 정도 지연이 생긴다면 여러 보고가 있었을 겁니다. 묵과할 수 없는 그런 상황이 벌어지는 것 일꺼니까요.
Opcache의 사용의 문제가 아니라 어떤 다른 문제가 있는 것 아닐까 하는 생각이 드네요.
물론 저는 서버전문가도 아니고 그냥 일반 사이트운영자 입장에서 생각해 봤습니다. -
다른 문제가 있을수도 있긴 하겠네요... 아직 문제를 찾아보는 중이라...
먼가 하나를 해결하면 하나가 튀어나오고 재밌네요 ㅋㅋ -
Opcache 설정은 이렇습니다.
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1
; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli=1
; The OPcache shared memory storage size.
opcache.memory_consumption=128
; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=16
; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
opcache.max_accelerated_files=4000
; The maximum percentage of "wasted" memory until a restart is scheduled.
opcache.max_wasted_percentage=5
; When this directive is enabled, the OPcache appends the current working
; directory to the script key, thus eliminating possible collisions between
; files with the same name (basename). Disabling the directive improves
; performance, but may break existing applications.
opcache.use_cwd=1
; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
opcache.validate_timestamps=1
; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=2
; Enables or disables file search in include_path optimization
opcache.revalidate_path=1
; If disabled, all PHPDoc comments are dropped from the code to reduce the
; size of the optimized code.
;opcache.save_comments=1
; If disabled, PHPDoc comments are not loaded from SHM, so "Doc Comments"
; may be always stored (save_comments=1), but not loaded by applications
; that don't need them anyway.
;opcache.load_comments=1
; If enabled, a fast shutdown sequence is used for the accelerated code
opcache.fast_shutdown=1
; Allow file existence override (file_exists, etc.) performance feature.
opcache.enable_file_override=0
; A bitmask, where each bit enables or disables the appropriate OPcache
; passes
;opcache.optimization_level=0xffffffff
;opcache.inherited_hack=1
;opcache.dups_fix=0 -
?
consistency_checks가 켜져있거나 opcache.revalidate_freq 수치가 지나치게 낮아서 그런것같습니다.
revalidate_freq를 300 이상으로 늘려보세요. -
?
validate_timestamps를 0으로 바꾸시고 정상적으로 속도가 나면 오버헤드로 생각하시면 될듯합니다.
-
?
댓글 감사합니다 ㅎㅎ
opcache.validate_timestamps=0 으로 하거나
opcache.validate_timestamps=1 으로 설정하고 opcache.revalidate_freq=0 으로 변경하였더니 조금 현상이 줄어든 거 같습니다.다만 opcache.revalidate_freq 같은 경우에 0으로 하면 항상 검증하는데 의아하긴 합니다.
가끔 보니까 Opcache가 캐싱한 걸 전부 비워버리는 거 같던데 이 경우는 왜 그런지 아시나요? -
최근 버전의 XE에서 불필요하게 opcache_invalidate를 호출하는 부분이 있습니다. index.php 아니면 config.inc.php에 들어 있던 것으로 기억하는데, 해당 부분을 주석처리해 보세요. -
생각하지 못한 곳에서 발생했네요...
php파일이 있는 웹쪽은 HDD 블록스토리지 상품을 사용하고 있었습니다.
속도는 괜찮게 나오는 편이였으나, IOPS가 많이 부족해서, 특히 저용량 파일에서 아주 느려졌습니다.
Opcache가 계속 캐싱을 갱신하고 이러는 과정에서 저용량 파일을 랜덤하게 읽어오다 보니 블록스토리지 응답이 지연된 거 같습니다. (공지되지 않은 장애로 인한 속도 저하도 있을 수 있겠네요.)
그래서 웹쪽을 SSD 블록스토리지 상품으로 변경하고, 재설정 해주니까 TTFB가 100ms대로 줄었습니다.
완전히 다른 곳을 삽질한 후기였습니다.
이건 Opcache 뿐 아니라 어떠한 다른 것에서도 일어나기 힘든 현상입니다.
설정이 잘못되어도 뭔가 단단히 잘못되지 않고서야..
10초라면 기다릴 방문자는 거의 없을테니까요.