데이타베이스가 오래되면 파편화가 생길 수 있고, 어디인지 모르게 꼬일 수도 있습니다. 그래서 데이타베이스를 최적화 시켜주는데요.
이는 컴퓨터 하드디스크 정리와 비슷합니다. 컴퓨터 하드디스크에 기록되는 정보들은 순서대로 차곡차곡 정보가 쌓이는 것이 아니라 여기 저기 분산되어 빈 공간에 데이타를 저장하게 됩니다. 그러다보면 정보를 찾는데 시간이 걸리먄서 속도가 저하되는 것처럼 데이타베이스도 여기저기에 정보가 저장되다보면 속도가 느려지게 됩니다.
이렇게 명령을 수행하다보면 “Table does not support optimize, doing recreate + analyze instead”라는 메세지를 만나게 되는데요. 이는 MariaDB에게는 이런 메세지를 보여준다고 합니다.
wp.wp_commentmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_comments
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_links
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_options
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_postmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_posts
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_term_relationships
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_term_taxonomy
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_termmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_terms
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_usermeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_users
note : Table does not support optimize, doing recreate + analyze instead
status : OK
4. 주기적으로 최적화하기
그러면 데이타베이스를 최적화한다면 조금 더 성능이 좋아진다고 하는데요. 이를 정기적으로 수행할 수 있는 방법이 없을까요?
바로 리눅스에서 제공하는 cron 명령을 사용하면 가능합니다.
매일 새벽 3시에 모든 데이타베이스를 최적화하고 오류가 있으면 자동으로 복구하도록 하겠습니다.
아래와 같이 cron에 등록해주면 매일 새벽 3시 30부나다 모든 데이터베이스를 최적화, 오류가 있으면 오류복구를 실행하게 됩니다.
먼저 cron에 주기적으로 최적화 및 오류 복구 명령을 수행하기 위해서 crontab -e 명령을 사용합니다.
가상서버호스팅을 시작했다면 서버를 설치해보고 기본 세팅 정도는 할 수 있어야 할것 입니다. 저도 이 분야를 전혀 모르는 문외한 이었지만 구글링의 힘을 빌어서 거의 1년 반동안 서버를 운영해 오고 있습니다. 물론 상당히 많은 시간 투자를 해야 합니다.
서버 설치 시 엔트리급 서버를 운영한다면 아래 내용을 참고하는 게 좋을 것 같습니다. 엔트리급은 Vultr아나 Linode 기준으로 월 2.5$,또는 5$ 플랜으로 디스크 용량은 크지만 메모리가 작은 경우입니다.
메모리가 적은 엔트리급에서는 32비트 운영체제를 사용하는게 도움이 됩니다. 원래 윈도우즈에서도 32비트 운영체제는 기본 4GB만 지원할 정도로 적은 메모리에서 작동하도록 만들어져 있습니다. 그렇기에 램 512MB, 765MB, 1GB등 엔트리급 사양으로 워드프레스 사이트를 운영한다면 32비트 Ubuntu나 Centos등 운영 체제를 선택하면 조금 도움이 됩니다. 요즘 대세인 64비트 운영체제는 풍부한 메모리사용을 지원하기 위해서 개발되었고 그러다보니 기본적으로사용하는 메모리가 큽니다. 운영 체제별 최소 사양을보니 Centos/ Ubuntu 32비트는 최소 메모리로 512MB를 권장합니다. 64비트는 1GB를 권장하는데 예전 경험으로 보면 512MG나 756MB도 돌아가긴 하더라구요.
데이타베이스 설치 시 메모리를적게 사용하는 MyISAM 같은 데이타베이스를 선택할 필요가 있습니다. 요즘 InnoDB가 대세이고, 이를 적용하는 것중에 MariaDB가 가장 좋다고 많이 선택합니다, 그런데 이게 기본적으로 예전에 사용하던 것에 비해서 많은 메모리를 사용합니다. 그래서 조금 성능은 떨어지지만 MyISAM를 적용할 수 있습니다.
사이트 운용에서 빠른 메모리를 많이 확보하는것이 성능을 높일 수 있는 지름길이므로 엔트리 사양이라면 가능하면 많은 메모리를 확보할 수 있는 운영체제, 데이타베이스, 플러그인등을 선택하는 게 좋습니다.
이렇게 말씀드리지만 저는 1GB 메모리지만 이미 64비트 운영체제,MariaDB를 설치해 적용하고 있어서 이를 중심으로 설명드릴 예정입니다. 그리고 조만간 RAM을 2GB로 업그레이드할 예정입니다.
저도 Newspaper를 사용하다 진짜 가볍고 단순하면서도 디자인적으로 나쁘지 않은 테마로 변경 사용을 시도했습니다. 처음에는 가볍기 때문에 만족하면서 사용했는데요. 어느 순간 이것도 문제가 있다는 것을 알았습니다.
어느날 사이트가 갑자기 이상하게 작동하기 시작하는 것 입니다. 어떤 주소를 입력해도 똑같은 페이지로 이동해버리는 문제가 발생했는데요. 원인을 알기 위해 이런 저런 시도를했지만 워드프로세스를다시 설치하는 것외는 방법을 찾지 못했습니다. 그런데 테마를 Newspaper와 같은 최신 유료 테마로 변경하니 단박에 문제가 해결되더군요.
제가 적용했던 가벼운 테마들은 개인이 무료로 공개하는 것들이었는데요. 이들은 업데이트가 거의 없었고 특히 보안 이슈로 반드시 업데이트가 필요한 경우에도 대응을 않하거나 못하는 경우가 많은 것 같았습니다.
이런 경험을 하니 꼭 속도가 빠른 가벼운 무료 테마가 좋은 것은 아니다라는 생각이 들었습니다. 어느 정도 돈이 들더라도 꾸준히 기능 및 보안 업데이트가 빨리 빨리 이루어지는 테마를 사용하는 게 장기적으로는 이익이라는 결론을 얻었습니다. 그래서 다시 유료 테마인 Newspaper 8.5로 돌아왔습니다.
결론은 안정성있는 유료 테마중에서 꼭 필요한 기능 중심으로 커스터마이징해서 사용하는 게 좋습니다.
[업데이트] 워드프레스를 사용한지 5년 가까이 되면서 생각해보묜 Newspaper와 같은 완전한 유료보다는 위에서 언급한 Astra, GeneratePress, OceanWP와 같은 무료 버전과 유료 버전이 같이 있는 테마를 사용하는 것이 좋다는 생각을 합니다.
이러한 테마들은 무료 버젼도 유료 버전을 유지하기 위해서는 계속 업데이트 및 업그레이드를 해야 하기 때문에 상대적으로 안전합니다.
5. 웹브라우저에서 서버까지 길 빨리 찾기
앞에서 사용자가 워드프레스 컨텐츠를 보기 위해 인터넷 브라우저에서 명령을 내리면 브라우저는 컨텐츠가 있는 사이트 서버가 어디에 있는지를 찾습니다. 이를 전문 용어로 DNS Lookup이라고 하는데요. 브라우저가 사이트 서버가 있는 곳을 빠르게 찾을 수 있도록 만들어 것이 필요합니다.
그러면 DNS Lookup 시간을 어떻게 줄일 수 있을까요?
일반적으로 한국 업체에서 도메인을 구입하고 한국 서버를 사용하면 DNS Lookup 시간은 거의 걸리지 않는 것 같습니다. 네이버의 경우 30ms가 나오네요.
저는 미국 업체인 LuckyRegister 에서 도메인을 구입하고 서버도 일본에 있는 vultr을 사용해서인지 처음엔 DNS Lookup 시간이 250ms까지 나오더군요.
이 결과(솔직히 어는 항목이 효과를 보았는지 분간이 잘 안됩니다.) DNS lookup 시간은 30ms 정도로 줄었습니다. 물론 때에 따라서는 100ms가까이 가는 경우도 간혹 나오지만 30ms 정도로 안정적인 속도가 나옵니다.
[업데이트] 여기서 이야기하는 구글 페이지스피드 모듈(Google PageSpeed Module)은 구글에서 야심(?) 시작한 웹 개선 프로젝트였지만 몇년전부터 중단되었습니다. 그리고 서버에서 엄청난 자원을 사용하면서 오히려 성능이 낮아지는ㅁ 누제도 있기 때문에 거의 사용하지 않습니다.
6. 캐시 플러그인?
이 단계부터는 서버단에서 작업 효율을 높이는 방법에 대해서 살펴 보겠습니다.
가장 먼저 살펴볼 것이 cache를 잘 활용하는 것인데요. 어쩌면 가장 극적으로 성능이 개선 되는 것을 볼 수 있는 것이 바로 이 캐시(cache) 사용이 아닐까 합니다.
앞에서 설명했지만 서버는 브라우저에게서 받은 요청을 수행하려고 이 내용이 어디에 있는지를 찾고, PHP에게 사람들이 이해할 수 있는 HTML 파일로 만들도록 시키죠. 그러면 PHP는 데이타베이스에서 정보를 찾아 HTML 파일을 만드는데요. 이런 과정을 건너 뛰게 하거나 쉽게 할 수 있도록 만드는 게 캐시의 역활입니다.
이 캐시에는 여러 가지 종류가 있는데요. 제가 보기엔 3가지로 정리할 수 있습니다.
HTML 파일 전체를 cache하는 Full Page Cache
PHP Script한 결과를 보관하고 있는 PHP Script Cache
데이타베이스 관련해 Query 결과를 모아 두는 Query Cache
일반적으로 cache라고하면 캐시 플러그인(cache plug-in)을 떠올리는데요. 저는 이런 캐시 플러그인들이 충돌을 많이 일으켜서 가능하면 서버에서 제공하는 cgche 기능을 활용하는 것을 선호합니다.
6.1. Full page caching – FastCGI
Full page caching은 완성된 HTML 페이지를 디스크(RAM 용량이 많다면 RAM Disk)에 저장하고 있어서 브라우저로부터 요청 시 여기서 바로 컨텐츠를 보여주므로 실제로 속도도 빨라지고 체감 속도도 엄청 빨라 집니다.
이러한 Full page caching은 웹서버를 설치시 같이 설치되는 FastCGI의 성능이 우수하다고 알려져 있습니다.
아래는 FastCGI가 작동하는 다이어그램인데요. NGINX, PHP-FPM, MySQL 사이의 관계를 잘 보여주고 있습니다. 이 다이어그램은 ashleys라는 곳에서 배포한 것입니다.
FastCGI cache는 서버 부하를 줄여주고, 사이트 속도를 빠르게 해주는데요. cache된 페이지 중심으로 로딩 속도가 빨라지고, TTFB(Time To First Byte, 서버에 요청해 첫 데이타를 받기까지 걸리는 시간)가 절반 이하로 줄어듭니다.
NGINX 요청은 받은 PHP는 PHP script를 수행하게 되는데요. PHP Interpreter는 PHP Script를 컴파일하고 그 결과를 Shared Memory에 저장한 후 결과를 수행하게 됩니다. 나증에 똑같은 요청이 오면 Shared Memory에 Cache된 결과물을 이용하므로 속도를 증대시킬 수 있습니다.
아래는 PHP Script를 처리하는 과정에 대한 플로우 차트인데 Cache와 PHP Script 컴파일이 잔행되는 프로세스를 살펴볼 수 있습니다. 이 플로우 차트는 Basics of PHP opcode cache 에서 가져왔습니다.
이런 PHP Script 결과를 Cache해주는 프로그램에는 여러가지가 있지만 PHP에 기본 내장되는 OPcache가 가장 성능적으로 우수하다고 합니다. OPcache 사용에 대해서는 아래 포스팅을 참조하시기 바랍니다.
위에서 거론한 방식들은 서버단에서 직접 적용하는 것이라서 일방 웹호스팅에서는 적용하기 어려울 수 있습니다.
이럴 경우는 비슷한 효과를 내주는 캐시 플러그인을 설치할 수 있는데요. 여기에는 WP Super Cache, W3 Total Cache, WP Rocket 등등이 있습니다.
이러한 캐쉬 플러그인들은 각기 독특한 특징을 가지고 워드프레스 성능을 높여주고 있는데요. 각기 특징이 다르고 운영하고 있는 사이트와 잘 맞는지를 점검해서 사용해야 합니다.
기능이 많다고 좋은 성과를 내는 것도 아닙니다. W3 Total Cache는 캐쉬 플러그인중에서 가장 다양한 기능들을 적용하고 있습니다. 그렇다고 W3 Total Cache가 가장 좋은 성과를 보여 준다는 것은 아닙니다. 우수한 편이지만 가장 우수하다고 볼 수는 업죠. 그리고 복잡한 기능을 적용하다보니 충돌이 많은 편입니다.
캐쉬 플러그인에 대한 여러가지 벤치마킹한 자료들을 보면 이 테스트 결과에서 수위를 차지하는 것은 CacheEnabler, WP Rocket 또는 WP Super Cache등이 많이 거론되고 있습니다.
다운 받을 파일에서 필요 없는 부분, 예를 들어 주석이라든지, 빈 공간이라든지를 지워 용량을 가볍게 하는 방법입니다. 이를 Minify라고 부르는데요.
이렇게 minify하는 방법에는 여러가지가 있습니다.
가장 무식한 방법으로 서버 운영자가 각각 CSS 파일, Java Script 파일 등등을 줄일 수도 있습니다. 이는 것은 너무 힘들고 비효율적입니다. 그리고 수시로 업데이트되기 때문에 대응 불가능하죠. 저도 Newspaper 테마의 style.css 파일이 무려 1MB에 육박하기 때문에 필요없는 부분을 지워서 0.5MB로 만들어서 사용한적이 있습니다. 우선 속도가 얼마나 빨라졌는지 차이가 나지않고요. 업데이트될때마다 이런 작업을 매번 다는 할 수는 없어서 포기 했습니다.
다음으로는 Minify를 해주는 워드프레스 플러그인을 활용하는 방법입니다. 널리쓰이는 Autoptimize는 이런 파일들을 minify해주고 caching해 줍니다. 다만 이 방법은 다소 느리기 때문에 별로 권장하지 않는 방식입니다.
가장 속도가 빠른 것은 NGINX나 APACHE 서버를 설치 시 구글 페이지스피드 모듈(Google PageSpeed Module)을 포함해 컴파일해서 서버에서 직접 알아서 minify 하도록 하는 방식입니다. 이는 제가 사용하는 방식인데요. 뒤에서 소개하는 구글 페이지스피드 모듈(Google PageSpeed Module)을 참조하시기 바랍니다. 이 방식의 단점은 컴파일이 다소 복잡하고 조금(20분정도?) 시간이 걸립니다.
렌더링이 시작되면 다운 받는 내용중 가장 많은 비중을 차지하는 것 중의 하나가 이미지입니다.
아래는 제 사이트 메인의 컨텐츠 종류별 요청 비중과 다운받은 용량 비중을 나타낸 그래프인데요. 이미지 요청은 68개로 비중이 52.3%나 차지하지만, 실제 다운 용량 비중은 35%로 오히려 적어지고 있습니다.
이렇게 68개나 되는 많은 이미지이지만 적절하게 압축해서 다운 용량을 0.4MB로 최적화했기 때문에 비중이 줄어드는 효과를 본 것입니다.
그러면 여기서 제가 어떻게 이미지를 최적하하고 있는지 이야기 해보겠습니다.
먼저 포스팅 시 이미지는 가능하면 jpg 중심으로 사용합니다. 가장 압축율이 높기 때문입니다.
JPG라도 압축율을 70%~85%로 높여 이미지를 가볍게 만듭니다. 이반 이미지는 70% 압축율을 적용하고, 글씨들이 많이 포함된 이미지는 85% 정도로 압축을 약하게 합니다. 압축율이 높아지면 글자가 흐릿해지더군요. jpg 아축율은 80%정도가 적절하고 하는데 80% 압축하면 구글 페이비스피드로 측정해보면 압축을 더하라고 가이드하더군요.
서버단에 적용된 구글 페이지스피드 모듈(Googke PageSpeed Module)에서 각종 이미지 압축 기술을 적용토록 옵션을 두고 있고 특히 크롬등에서 적용하는 webP 포맷을 적ㅇ요토록 하고 있습니다. 이에 대해서는 아래 포스팅을 참조하세요.
외국이라면 전체 속도에 효과 있고, 트래픽이 절감되며 보안에도 유리한 방법이 바로 CDN(contents delivery network)인데요,
위키에서 CDN(contents delivery network)을 아래와 같이 정의하고 있습니다.
콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network (CDN))는 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말한다.
서버와 사용자사이 인터넷 중간에 CDN이라는 별도 cache 역활을 하는 다수의 서버에 컨텐츠를 저장해놓고 사용자는 가장 가까운 CDN 서버에서 컨텐츠를 받을 수 있도록 한 것으로 먼곳의 사용자가 빨리 접속할 수 있습니다.
그러나 이 서비스에는 두가지 문제가 있다고 알려져 있습니다.
첫째는 CDN을 걸쳐서 컨텐츠를 받기 때문에 TTFB가 느리게 나옵니다. 이 TTFB 속도에 대해서 CDN 서비스의 대표격인 클라우드 플레어에서는 TTFB가 중요하지 않다고 발표했었고 구글에서 반박하는 해프닝이 있었습니다. 이에 대해서는 hackYa님의 글 클라우드플레어 (CloudFlare)를 쓰지 말아야 하는이유를 참고하세요.
둘째는 클라우드플레어 (CloudFlare)같은 글러벌 서비스는 여러가지 정책 상 비지니스 플랜이외에는 한국 서버가 아닌 해외 심지어는 유럽 서버로 연결되어 속도가 엄청 느려 진다고 합니다. 특별히 트래픽 절약 목적이 아니라면 사용하지 말자는 이야기가 많습니다. 이에 대해서는 XETOWN 가진곰님의 글을 참고해 보세요. 제발 해외 CDN 좀 사용하지 맙시다.
이러한 이유로 저는 CDN(contents delivery network)은 사용하고 있지 않습니다. 아직 트래픽을 5%(월 1TB 트래픽 중 약 60GB 사용)밖에 사용하지 않아서 트래픽을 절약할 이유도 없구요.
8. 워드프레스 군더더기 없애기
다음으로 생각할 게 워드프레스에 불필요한 군더더기를 최소화 하는 것 입니다.
이러한 군더더기에는 무엇이 있을까요? 군더더기라고 표현하니 쓸모없는 것이라고 생각하기 쉽지만 정확히 표현해서 중요성이 떨어지는 것입니다.
8.1. 워드프레스 리비젼(Revision) 갯수 제한
워드프레스로 글을 작성하다보면 계속 내용을 업뎅트 하게 됩니다. 그러면 워드프레스는 무한적으로 수정 버젼을 기록하는데요. 이를 리비젼(Revision)이라고 부릅니다.
정말 중요한 문서가 아닌 이상 글의 히스토리를 기록할 필요가 없고 대부분 이전 버젼을 참고하므로 리비젼(Revision)이 거의 필요 없거나 최소로 남겨 놓는 게 효율적입니다.
가장 쉽게는 wp-config.php에서 아래 문구를 넣어 리비젼(Revision) 갯수를 제한 합니다.
워드프레스는 2.9버젼부터 휴지통 기능이 생겨 포스팅, 댓글, 미디어 등을 삭제하면 휴지통으로 이동해 치종 39알 경과하면 완전히 없어집니다.
자주 포스팅, 댓글, 미디어등을 지운다면 휴지통에 많은 정보들이 모여 데이타베이스 공간을 차지하고 데이타베이스가 커지면 실행 속도가 느려질 수 있습니다.
따라서 주기적으로 휴기통을 지워주든지 휴지통에서 비워주는 기간을 30일보다 앞당기는 것도 한 방법입니다.
워드프레스 wp-config.php에서 아래 문구를 넣어 휴지통에서 완전 삭제하는 기간을 단축합니다.
/** 휴지통 완전 삭제 기간을 10일로 단축하기 */
define ('EMPTY_TRASH_DAYS', 10);
Code language:PHP(php)
8.3. 트랙백과 핑백 알림을 사용하지 않기
워드프레스는 커뮤니케이션 활성화를 위해 트랙백과 핑백을 기본으로 알려주는 기능을 적용하고 있습니다.
그러나 스팸등의 이유로 이런 기능을 없애는 블로그 툴들이 늘어나고 있습니다. 네이버 블로그나 티스토리는 아예 트랙백 기능을 없앴습니다.
워드프레스에서도 스팸 위험이나 데이타베이스를 가볍게 만들기 위해 트랙백과 핑백 알림을 사용하지 않토록 설정할 수 있습니다.
워드프레스 설정 – 토론의 기본글 설정에서 “새로운 글에 다른 블로그에서 오는 링크알림(핑백이나 트랙백)을 허용”부분의 체크를 없애면 됩니다.
저는 이게 워드프레스 속도에 미치는 영향이 크지 않다고 생각하며, 스팸의 위협도 Disqus 등을 적용하면 거의 없으며 블로그의 본질이 커뮤니케이션에 있다고 생각해서 아직은 유지하고 있습니다.
8.4. 플러그인 최소화, 가벼운 플러그인 사용
워드프레스로 사이트를 운영하다보면 매력적인 기능을 제공하는 다양한 플러그인을 만나게 됩니다. 그러면 그 기능과 디자인에 혹해서 하나 둘씩 플러그인을 늘랴가게 되죠.
하지만 워드프레스는 이러한 플로그인이 늘어날수록 이런 플러그인을 모두 처리하고 컨텐츠를 보여주므로 워드프레스를 느리게 할 수 있습니다.
앞에서 계속 강조했던 최적화를 위해서 요청 명령수를 최소화하자는 원칙에서 벗어나 요청 명령수를 늘리고 속도를 저하하게 됩니다. 따라서 정말 꼭 필요한 플로그인인지 심사 숙고한 후 설치해야 합니다.
저는 플러그인을 7개 내외로 최소화하고 있습니다.
그리고 꼭 필요한 플러그인이라면 상대적으로 가벼운 플러그인이 무엇인지를 고민할 필요가 있습니다.
SNS 공유 플러그인을 검토한 예를 말씀드리면 플러그인에 따라 로딩 속도차이가 컸습니다. 당시 Monarch, AddThis, AddToAny 그리고 Sassy Social Share를 검토했는데요. 플러그인에 따라서 로딩 시간이 최대 1초까지 차이가 났습니다. 기능이나 멋진 디자인에도 불구하고 0.5초 ~1초 까지 감수할 이유는 없었습니다. 결국 가장 가벼워 보이면서도 커스터마이징이 가능한 Sassy Social Share를 적용했습니다.
이런 여러가지 최적화를 통해서 최종 속도는 어느정도 나올까? 아래는 여러 측정도구 중 가장 잘 나왔던 Webpagetest.org에서 측정한 값 입니다. 로딩 타임 1.42초, TTFN 0.47초, 렌더링 시작 시간 1.09초로 비교적 양호합니다.
10. 마치며
이상으로 간단하게 워드프레스 최적화 방안에 대해서 정리해 보았습니다.
개인적으로는 (아마 많은 원드프레스 사용자들이 공감할 것입니다. FastCGI를 제대로 적용했을 시 가장 급격하게 속도가 좋아졌습니다. 아마 이와 비슷하게 Full page cache에 집중해주는 cache enabler 등이 속도가 좋았던 이유도 마찬가지라고 생각합니다.
다음으로는 이미지 압축을 통해서 약 2.5GB의 이미지를 0.9GB로 줄였는데요. 이 때도 확실하게 다운 이미지 용량이 감소하니 도움이 되었던 것 같습니다.
1992년 10월 31일 Jean-loup Gailly와 마크 애들러가 만들어 처음 배포하였다.
압축 구현 방법은 LZ77과 허프만 코딩을 조합한 DEFLATE알고리즘에 기반한다고 알려져 있다.
즉 gzip은 웹서버에서 사용하는 압축 프로그램으로 여기서 압축한 방식을 대부분의 웹 브라우저에서 지원하는 범용성때문에 웹서버 최적화 시 많이 사용하는 소프트웨어입니다. 리눅스계열등을 설치 시 기본으로 배포하는 프로그램으로 이를 사용하기 위해 프로그램을 설치할 필요가 없습니다.
2. gzip설정 옵션
gzip의 옵션에는 아래와 같은 것들이 있습니다.
gzip [on/orr] : gzip의 설정을 on/off하는 명령
gzip_disable [regex] : 해당 명령어 다음에 오는 문장이 요청 헤더에 User-Agent와 일치 시 압축하지 않음
gzip_vary [on/off] : gzip, gzip_static, or gunzip 설정이 on일 시 응답 헤더에 “Vary: Accept-Encoding”를 넣을지 말지에 대한 명령
gzip_proxied : 요청과 응답에 따라서 프록시된 요청을 압축할지 말지에 대한 설정으로 “any”로 설정하면 모든 응답에 대해 gzipping 압축을 수행
gzip_comp_level [level] : 응답에 대한 압축의 정도를 의미하며 level의 값은 1부터 9까지 가능
gzip_buffers [num] [size] : num은 버퍼의 갯수, size는 버퍼의 크기를 의미
gzip_http_version [versino] : minimum HTTP 통신 버전
gzip_types [types in array] : “text/html”외 추가로 gizip항 타입 정의
3. nginx에서 gzip설정
nginx에서 gzip을 설정하는 방법은 /etc/nginx 경로에 있는 nginx.conf 파일을 수정해서 설정합니다.
gzip을 적용 시 주의할 점이라고면 욕심에 모든 파일 압축을 요구하는데 이는 오히려 서버의 부하를 가중시켜 속도를 떨어뜨린다고 합니다.
gzip_min_length 1024;와 같이 압축해야 할 최소 크기를 지정, 어느 정도 큰 파일만 압축하라고 가이드 함
이미지 파일은 압축이 안되기 때문에 압축 타입에서 빼라고 함
단 이미지 파일이지만 SVG 파일은 코드 형태로 되어 있으므로 적용 가능
3.1. SVG 파일 압축 가능한지 확인
SVG 파일을 gzip 압축이 가능하게 하려면 먼저 NGINX에 이를 가능케 되어 있는지 mime types을 확인해야 합니다.
/etc/nginx/mime.types 파일을 열어 image/svg+xml svg svgz;가 있는지 확인하고 없으면 추가
오늘은 워드프레스 속도를 빠르게 하는 방법 중 상당히 효과가 좋다고 알려진 FastCGI 적용 방법에 대해서 알아보도록 하겠습니다. 이는 웹서버로 NGINX를 사용하는 경우 유용합니다.
웹서버로 아파치를 많이 사용하고 점유율도 높지만 얼마 전부터는 단순하면서 성능이 좋은 NGINX를 웹서버로 사용하는 경우도 늘었습니다. 특히 동접자가 많은 경우 NGINX가 메모리 관리 등에서 효율성이 있다고 알려져 그런 흐름이 가속화 되기도 했습니다.
그렇지만 아파치에서도 NGINX만의 장점들을 쉽게 구현하는 방법들이 등장해 아파치를 사용에도 별 문제가 없어져 차별화가 많이 희석되기도 했습니다.
1. FastCGI cache란?
일반적으로 사용자가 브라우저를 통해서 특정 페이지를 보겠다고 요청하면 NGINX는 PHP와 MySQL이라는 데이타베이스에게 명령을 내려 사용자가 요청한 페이지를 구성하게 하는데요. FastCGI는 NGINX와 PHP 사이에서 기존에 불러왔던 페이지를 저장해 놓고 있다가 사용자 요청이 오면 PHP나 MySQL의 도움없이 바로 사용자에게 보여주어 굉장히 빨리 처리해 속도를 높이고 시스템의 부하를 줄이는 역활을 합니다. 이를 업계에선 Full page caching이라고 부르고 있네요.
아래는 FastCGI가 작동하는 다이어그램인데요. NGINX, PHP-FPM, MySQ 사이의 관계를 잘 보여주고 있습니다.
FastCGI cache는 서버 부하를 줄여주고, 사이트 속도를 빠르게 해주는데요. cache된 페이지 중심이긴 하지만 속도가 빨라지고 TTFB(Time To First Byte, 서버에 요청해 첫 데이타를 받기까지 걸리는 시간)가 절반 이하로 줄어듭니다.
2. FastCGI 적용 방법
그러면 이런 FastCGI cache를 적용하려면 어떻게 해야 할까요?
아래와 같이 순서대로 적용해 보시지요. FastCGI cache는 서버를 설치(NGINX, PHP, MariaDB 등) 시 자동으로 설치되므로 설되어 있는 기준으로 세팅을 어떻게 하는냐를 말씀드리겠습니다.
2.1. Nginx의 설정파일 nginx.conf 설정하기
먼저 Nginx의 설정파일인 nginx.conf에서 FastCGI cache 관련 내용을 설정합니다.
여기는 Nginx의 설정 파일 중 http 구간에 적용하는 코드가 되겠습니다.
FastCGI cache path 위치 지정
FastCGI cache path 위치는 아무 곳이라도 상관이 없습니다. 심지어 별도로 위치를 지정하지 않아도 NGINX가메모리 여유가 있으면 자동으로 Cache를 램에 올려 사용하고 모자라면 스압을 사용한다고 합니다.
그렇지만 필요에 따라서 FastCGI Cache 파일을 지우는 등 Cache 관리를 하려면 일정 폴더를 지정해 주어야 합니다. FastCGI Cache를 관리해주는 플러그인들은 대부분 Cache 폴더를 지정토록 하고 있습니다.
물론 폴더와 상관없이 FastCGI cache를 관리하는 방법이 있기는 한데 불안정하고 설치 버젼에 따라서 작동하지 않은 경우도 많기 때문에 cache 폴더 지정해 관리하는 것이 좋습니다.
그리고 몇가지 옵션을 테스트했지만 명확히 메모리 폴더를 지정하지 않으면, 우선 순위에서 밀리기 때문에 램에서 작동하지 않는 경우도 많아지는 것 같습니다.
그렇기 때문에 램에서 작동토록 하려면 Cache 폴더를 지정해 주어 확실하게 우선 순위를 설정하는 것이 나은 선택입니다.
또한 메모리가 충분하지 않다면 SSD로 구성된 스토리에 FastCGI cache 폴더를 지정해 운영하는 것도 차선책이 될 수 있습니다. 그렇지만 예전 느려빠진 HDD 스토리지라면 별로 추천하고 싶지는 않습니다. 콘텐츠 내용이 많지만 자주 업데이트 되지 않는 사이트의 경우 Cache 기간을 며칠 정도로 길데 잡아 효율성을 높일 때 유용할 것 같습니다.
제가 아는 사이트는 콘텐츠 양이 많다보니 8시간 정도로 길게 잡으니 cache 용량이 2GB를 넘어 버리드라구요. 이런 경우는 램을 업그레이드 할 수 없다면 SSD 스토리에 Cache 폴더를 설정해 운영하는 것도 아주 나쁘지는 않습니다.
당연히 비즈니스 사이트라면 램을 업그레이드해서 Cache 전체를 램에 올리는게 좋겠죠.
저는 용량은 적지만 빠른 RAM 메모리에 했는데요. 여기서는 두가지 경우를 모두 표현 했습니다.
# 일반 디스크에 6999MB 용량에 cache해 캐시 유효기간을 10분으로 유지하는 WORDPRESS라는 캐시 이름#fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=WORDPRESS:2048mb inactive=8h; # Disk애 적용 시 # RAM 메모리 512MB 용량을 할당, 10분동안 유지하는 WORDPRESS라는 캐시 이름
fastcgi_cache_path /dev/shm/fastcgi levels=1:2 keys_zone=WORDPRESS:512m inactive=10m; #RAM에 적용 시Code language:PHP(php)
여기서 정말 강조하고 싶은 것은 위치 지정 후 정말 제대로 작동하는지를 꼭 확인하라는 것입니다. path 설정해 놓는다고 다 작동하지는 않으며 RAM에 올리는 방식 또는 Disk에 설정 시 스왑등이 제대로 설정되어 있는지에 따라서 제대로 작동하지 않을 수 있습니다.
FastCGI cache 중 발생 상황 대응 지정
그 다음은 FastCGI가 디스크에 파일을 배치하는 방법, FastCGI 서버와의 통신 중에 오류 발생 시 하는 경우 등 오래된 캐시를 사용할 수 있는 경우, 워드프레스 테마 중 종종 부적절한 헤더값을 보내주는 경우 무시하라는 옵션을 표기합니다.
여기서 fastcgi_cache_valid 200 301 302 60m;은 응답코드가 200 301 302인 것을 캐시하고 그 캐시파일의 유효기간을 60분을 잡는 것입니다. 개인 사이트는 변경 내용이 많지 않으니 넉넉하게 시간을 주어도 좋을 것이고, 커뮤니티 사이트는 빨리 내용이 갱신되므로 1m(1분) 또는 30s(30초) 단위로 짧은 시간을 주는게 좋다고 합니다.
fastcgi_cache_valid 404 30s;은 응답코드가 404인 것은 30초마다 다시 갱신토록 했습니다.
fastcgi_buffers 16 16k; , fastcgi_buffer_size 32k;는 캐시 버터 크기 설정입니다.
FastCGI 캐시를 메모리에서 작동시키기
FastCGI를 일반 디스크에서 실행하는 것보다도 RAM 메모리에서 실행시키면 더욱 빠르겠죠. RAM 시스템 메모리는 디스크보다 훨씬 빠르니 반응시간도 훨씬 빨라질 것 입니다.
먼저 RAM 디스크를 등록해 줍니다. /etc/fstab 파일을 nano 편집기를 열어 편집할 수 있도록 합니다.
이렇게 별도 폴더를 만들지 않고 우분투 설치 시 자동으로 만들어지는 /dev/shm 폴더를 그대로 사용하는 것도 방법입니다. 별도 폴더를 만들지 않아도 되기 때문에 더욱 간편하긴 한데요. 이 폴더에 다른 프로그램도 사용할 수 있어 fastcgi 폴더를 만드는 것도 나쁘진 않습니다.
2.2. 서버 블락에서 FastCGI cache 설정
지금부터는 서버 블락에서 FastCGI cache 관련 옵션 정리 방법입니다.
캐싱을 하지 말아야 할 경우 설정
캐싱을 하지 말아야 할 경우가 있는데 이 구간을 정의하는 부분입니다.
set $skip_cache 0;
# ---------------------------------------------------------------------# 캐싱을 하지 말아야 할 경우가 있는데 이를 정의하는 구간 CACHE SKIP RULES - START# ---------------------------------------------------------------------# Do not cache POST requests - they should always go to PHPif ($request_method = POST) {
set $skip_cache 1;
}
# Do not cache URLs with a query string - they should always go to PHPif ($query_string != "") {
set $skip_cache 1;
}
# WooCommerce-specific cache skip rulesif ($request_uri ~* "/store.*|/cart.*|/my-account.*|/checkout.*|/addons.*") {
set $skip_cache 1;
set $skip_cache_reason WP_WooCommerce;
}
if ($cookie_woocommerce_items_in_cart) {
set $skip_cache 1;
set $skip_cache_reason WP_WooCommerce;
}
if ($request_uri ~* ("/cart.*")) {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments (admin panel, sitemaps, feeds, etc.)if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commentersif ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
# ---------------------------------------------------------------------# CACHE SKIP RULES - END# ---------------------------------------------------------------------Code language:PHP(php)
FastCGI와 PHP-FPM과 통합
이제 FastCGI cache와 PHP간 통합을 정의합니다. 이 부분도 마찬가지로 server 블락에 아래 내용을 추가 합니다.
# Add PHP handler
location ~ \.php$ {
try_files $uri =404; # comment out this line if php-fpm is hosted on a remote machineinclude /etc/nginx/fastcgi.conf;
fastcgi_cache WORDPRESS;
add_header X-Cache $upstream_cache_status;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return404;
}
}
Code language:PHP(php)
3. NGINX 재가동 및 작동 테스트
FastCGI 설정이 완료되면 nginx를 다시 가동시키고 제대로 작동하는지 테스트 해 봅니다.
먼저 문법 상 충돌되거나 오류가 없는지 config test를 진행합니다.
service nginx configtest
Code language:PHP(php)
“the configuration file /etc/nginx/nginx.conf syntax is ok” 라는 문구가 나오면 정상적으로 작동 가능한 것이므로 nginx를 다시 가동시킴니다.
service nginx restart
Code language:PHP(php)
이제 FastCGI가 제대로 작동하는지 확인해 봅니다.
ls -alhR /dev/shm/fastcgi
Code language:PHP(php)
그러면 현재 cache되고 있는 리스트가 주욱 나옵니다. 그러면 정상적으로 작동하는 것이니 기쁜 마음으로 마무리 합니다.
4. 시행 착오
무사히 FastCGI를 설치하고 작동하는 것을 확인하고부터 사이트의 속도가 굉장히 빨라졌습니다. 그리고 욕심을 내어서 몇가지를 조정했습니다.
먼저 cache를 램에 올리고 메모리를 512MB을 할당했습니다.
다음 cache 교체 시간을 1440m으로 상당히 길게 잡았습니다. 내용이 많이 바뀌지 않기 때문에 여유있게 잡아본 것입니다.
이렇게 설정을 바꾼 후 처음 엄청 빠른 속도를 보여 주었던 것이 시간이 지나면서 엄청 느려지기 시작했습니다. 사이트 메인의 TTFB가 처음에는 0.3ms정도였는데 어느 순간 1.3s까지 느려지더군요.
왜 이런 문제가 발생했을까 여러가지 설정 테스트를 해보니 cache 유지 시간이 길고, RAM 512MB에 세팅한 cache가 꽉 찬 상태에서는 무엇인가가 제대로 작동하지 않는다는 결론을 얻었습니다. cache를 비우고 cache 설정 시간을 30m 정도로 줄이니 제대로 작동했으니깐요.
결국 cache 메모리가 적다면 cache 교체 시간을 짧게 설정해야 한다는 결론을 얻었습니다.
하지만 나중에 생각해보면 Fastcgi는 설정한 용량이 차면 순서대로 Cache를 지우도록 되어 있기 때문에 위와 같은 해석은 근거가 없습니다. 어느 분이 스왑으로 변경하기 때문에 그럴 것이라는 의견을 주셨는데 앞에서 설명드린대로 SSD도 상당히 빠르기 때문에 설령 나머지가 스왑으로 전환되어 SSDㅇ서 작동한다고 해도 그 정도로 느려지지는 않습닏.
그후 FastCGI와 구글 모드 페이지 스피드를 같이 운영 시 나타나는 문제라는 것을 알았습니다. 구글 모드 페이지 스피드는 너무 열심히 일을 해서 구글 모드 페이지 스피드 캐시를 끊임없이 업데으이트하면서 CPU자원을 100%이상으로 사용하고 여기에 FastCGI Cache도 만드느라 이중 일을 하면서 속도가 느려지는 현상이었습니다. 이후 구글 모드 페이지 스피드를 제거 후 이런 문제를 만나적은 없습니다.
Vultr 가상서버호스팅(VPS)에서 워드프레스 운영 중 메모리 스왑 파일을 적용해 속도를 향상시키는 방안에 대해서 알아 보겠습니다.
사이트 운영을 위해 서버를 설치 시 운영체제나 데이타베이스 종류는 최신의 트렌드를 반영하여 선택하기 마련입니다. 예를 들어 운영체제는 대부분 64비트를 선택하죠. 그리고 데이타베이스로 InnoDB가 적용된 MariaDB를 선택하곤 합니다. 이들은 가장 최신이고 가장 성능에서 앞선다고 알려진 것들 입니다.
그런데 여기에 함정이 있네요. 본격적인 사이트 운영을 위해 서버 사양을 빵빵하게 운영한다면 별로 문제가 되지 않겠지만 엔트리급을 선택하는 경우는 조금 다릅니다. 예를 들어 Vultr의 756MB 메모리를 가진 2.5$ 플랜이나 1GB 메모리를 가진 5$ 플랜을 선택하는 경우 잘못하면 메모리 부족에 허덕일 수 있기에 가장 적은 메모리를 사용하는 사양을 선택해야 합니다. 그런 관점에서 최소 메모리 요구 조건은 64비트보다는 32비트 운영체제가 더 낫고, InnoDB가 적용된 MariaDB보다는 MyISAM를 적용한 일반 MySQL이 차라리 낫습니다.
그러나 이미 64비트에 MariaDB를 적용해 사용하고 있는데 다시 설치하고 최적화시키는 것은 무지 귀찮은 일이죠. 선수가 아니라면 또 엄청난 시간을 들여서 구글링을 해야겠지요.
서두가 조금 길었는데요. 이렇게 엔트리 사양에서 메모리 부족이 발생하는 경우가 많은데 이를 해결하는 방법으로 디스크를 이용 스왑 메모리를 만드는 방법에 대해 간략히 살펴 봅니다.
1. 시스템 저장 공간 사용 현황 파악
다행히 요즘은 SSD로만 운영되는 상품이 많기 때문에 SSD 디스크에 스왑 메모리를 만들면 어느 정도 성능이 나오기 때문에 시도할 만합니다.
그러면 어떻게 이 스왑 메모리를 만들어 이용할 수 있을까요? 우선 시스템에 스왑 메모리를 적용할 여유가 있는지 확인합니다.
이때 시스템 내 디스크 및 메모리 사용 현황을 파악하기 위해서 df -h라는 명령을 사용합니다. 이 명령을 내리면 시스템에 구성된 각종 디스크와 RAM 메모리 사용 현황을 보여 줍니다.
이에 따르면 SSD 디스크 공간 25GB중에서 16GB가 남아있다는 것을 알 수 있습니다.
2. 스왑 메모리 파일 만들기
16GB 용량이 남아 있다는 것을 확인했으면 어느 정도 크기의 스왑 파일을 만들 것인지를 결정해야 합니다.
저의 경우 1GB 메모리가 있는데 조금 넉넉한 스왑 메모리를 확보하고 싶어서 4GB를 선택했습니다. 어짜피 놀고있는 SSD 공간이므로..
아래와 같은 명령을 사용해 스왑 파일을 만듭니다. 스왑 메모리 파일을 만들고, 권한을 부여하고 포맷하는 일련의 과정을 바로 이어서 진행 합니다.
fallocate -l 4G /swapfile # 4GB 스왑 메모리 파일을 만든다.
chmod 600 /swapfile # 스왑 메모리 파일에 쓰기 권한을 부여한다.
mkswap /swapfile # 스왑 메모리 파일을 포맷한다.
swapon /swapfile # 스왑 메모리 파일을 활성화 한다.
위와 같은 작업을 통해서 4GB의 스왑 메모리 파일이 생성되었습니다. 그러면 정말로 스왑 메모리가 만들어졌는지 확인을 해봅니다. 이때 사용하는 명령은 free -m 또는 swapon -s 명령입니다. free -m 명령은 일반 메모리와 스왑 메모리 상태를 보여줍니다. 스왑 메모리가 없다면 0으로 표기됩니다. 아래에서는 생성된 스왑파일 4095가 보이네요.
@happist:~# free -m
total used free shared buff/cache available
Mem: 988 540 85 117 362 187
Swap: 4095 108 3987
swapon -s 명령을 사용하면 아래와 같은 결과를 보여 줍니다.
@happist:~# swapon -s
Filename Type Size Used Priority
/swapfile file 4194300 108288 -1
3. 영구 스왑 메모리 파일로 만들기
위와 같이 만들어진 스왐 메모리는 다시 부팅하면 없어져 버립니다. 따라서 시스템이 존재하는 한 계속 사용할 수 있도록 만드는 작업이 필요합니다. 이는 /etc/fstab의 파일에 아래 내용을 추가하는 것입니다.
nano /etc/fstab # fstab 파일을 편집
fstab 파일 맨 아래 부분에 아래 내용을 추가
/swapfile none swap sw 0 0
4. 스왑 메모리 죽이기
메모리를 충분히 증설했거나 스왑 파일을 활용함에도 별로 성능에 도움이 되지 않은다면 과감히 지워버릴 필요가 있겠죠. 스왑 메모리 파일을 지우는 것은 아래 rm 명령을 사용합니다.
오늘은 워드프레스 운영을 위해 Vultr 가상서버호스팅(VPS)에 서버 설치 후 최적화하는 방안에 대해서 살펴보고 있습니다.
서버 최적화는 웹서버 최적화, DB 최적화 그리고 PHP 최적화등으로 나누어질 수 있는데요. 오늘은 이 중 DB 최적화에 대해 살펴 보겠습니다.
여기 워드프레스를 설치한 서버에는 MariaDB가 기본으로 설치되어 있으므로 MariaDB 최적화 방안 중심으로 살펴 보겠습니다.
사실 그동안 DB 부분은 접근할 엄두가 나지 않았고, 최적화가 크게 필요 없다는 생각을 했는데, 자료를 보다보니 여기에서의 최적화가 절대적으로 필요하다고 하고, 여기까지 최적화하지 않으면 두고 두고 후회할 것 같아 없는 시간을 내서 시도해 보았습니다.
1. my.cnf 위치
MariaDB를 설치했기 때문에 InnoDB 최적화에 대한 내용이니 참고하시는게 좋겠습니다.
다 아시는 것처럼 MariaDB를최적화하기 위해서는 my.cnf에서 설정을 변경해 주는데요.
이 파일은 /etc/my.cnf 또는 /etc/mysql/my.cnf에 위치하고 있습니다.
2. 최적 메모리에 대한 생각
MariaDB 최적화를 위해서 자료를 조사하다보니 메모이이야기 많이 나옵니다. 메모리는 많으면 많을수록 좋다는게 일반적인 상식이고, 이 DB와 관련해서도 마찬가지입니다.
DB가 작업하는 공간이 속도가 빠른 메모리에서 모두 진행하는게 속도를 올릴 수 있는 지름길이기 때문이죠.
그러면 도대체 어느 정도 메모리를 가지고 있어야 할까요?
일반적으로 메모리의 크기는 최소 데이타베이스 크기 정도는 확보해야 한다고 합니다. 데이타베이스 크기와 RAM의 크기가 비숫하면 별다른 세팅을 하지 않고도 어느 정도 성능을 낼 수 있다고 합니다. 만약 6GB의 데이타베이스가 있다면 메모리도 최소 6GB가 있어야 하고 이보다도 20%~30%정도 더 메모리가 있다면 최상이라는 것이죠.
그러나 일반적으로 비용의 문제이기 때문에 충분한 메모리를 가지지 못하는 경우가 생기죠. 이렇게 서버에 충분한 메모리가 없는 경우 제대로 된 MySQL/MarianDB가 작동하지 않을 수 있습니다. 그렇기에 최적화가 필요합니다.
3. MariaDB 필수 최적화 항목들
my.cnf에는 많은 설정 변수들이 있는데요. 이러한 설정들을 최적화해서 적은 메모리로 가능하는한 최고의 성능을 낼 수 있는 옵션이 무엇이 있는지 살펴 보겠습니다.
이는 가능하면 디스크 대신 빠른 메모리 영역에서 작업을 처리할 수 있도록 설정을 유도함으로써 CPU 성능과 조화를 이루어 전체 성능을 높일 수 있습니다.
3.1. innodb_buffer_pool_size
이 설정은 데이카베이스가 얼마만큼의 메모리를 가져다 쓸 것이냐를 지정하는 것으로 가장 중요한 설정 중의 하나입니다.
설치 시 기본으로 세팅되어 있는 값은 128k인데요. 많은 문헌에서 시스템 메모리의 65%~75% 권장하고 있습니다.
일반적으로 5~6GB (8GB RAM)
20~25GB (32GB RAM)
100~120GB(128GB RAM)
Vultr에서 사용하는 5$ 플랜은 기껏 1GB 시스템 메모리를 가지고 있으므로 750MB를 할당하였습니다.
innodb_buffer_pool_size= 750M
3.2. innodb_log_file_size
innodb_log_file_size는 데이타베이스 충돌 발생 시 다시 실행하거나 이전으로 되돌릴 때 사용하는 메모리이빈다.
이 사이즈는 기본으로 48M이 할당되어 있는데요. 일반적으로 앞서 설정한 innodb_buffer_pool_size의 25% ~ 50% 정도 할당하는 게 좋다고 합니다. 다만 너무 클 필요는 없다는 지적이 있네요.
innodb_buffer_pool_size= 185MB
3.3. innodb_flush_log_at_trx_commit
이는 데이타베이스가 작동을 어떤 방식으로 기록하느냐를 설정하는 것이죠.
설정값은 1, 2, 0의 세가지가 있는데 기본은 1로 설정되어 있습니다.
1로 설정되면 트랜잭션을 수행할때마다 버퍼가 로그 파일에 기록되고 로그 파일은 다시 디스크로 플러시 됩니다.
2로 설정되면 데이타베이스가 각 트랜잭션을 완료 시 로그 파일에 기록되고 로그 파일은 1초마다 디스크로 플러시 됩니다.
0으로 설정되면 각 트랜젝션 시 아무런 기록을 하지 않고 로그 버퍼는 로그 파일에 기록되어 1초마다 디스크로 플러시 됩니다.
가장 성능이 좋은 것은 0을 선택하는 것이고, 1을 선택하면 가장 높은 신뢰성을 보여 준다고 합니다.
정전 등에 대비가 잘 되어 있다면 성능을 중요시해 0을 선택할 수도 있는데요. 저는 성능 지상주의이므로 0을 선택했습니다.
3.4. query_cache_size
query_cache_size는 SQL 실행 결과를 미리 특정 공간에 저장해 놓고, 다음 번 같은 문장으로 호출 시 빠르게 해당 결과를 보여주는 것인데요.
query_cache_size가 너무 크다면 갑자기 엄청난 쓰기 작업이 발생하면 서버는 바로 쿼리 작업을 하는 대신 cache를 찾아 작동하는데 집중해 오히려 속도가 느려집니다.
query_cache 때문에 발생하는 병목 현상은 자주 나타나는 현상으로 아주 악명이 높다고 알려졌는데요. query_cache_size는 너무 크지 않게 설정하는 게 좋으며 최고 512M이면 충분하다는 의견입니다.
또 어떤 가이드는 차라리 query_cache_size를 0으로 놓는 것을 고려하라고 충고하고 있습니다.
3.5. Disable MySQL DNS Lookups
DNS lookups 호스트 네임과 IP를 매번 확인후 작동하므로 느려질 수 있다고 합니다. 따라서 skip-name-resolve 명령어를 추가해서 이를 방지합니다.
skip-name-resolve
3.6. innodb_io_capacity
SSD와 같은 성능 좋은 Disk를 사용하고 있다면 이를 크게 올려주는 게 성능에 좋다고 합니다.
Vultr는 모두 SSD로 운영되므로 nnodb_io_capacity를 105000 이상으로 설정했습니다.
innodb_io_capacity = 15000
3.7. tmpdir
데이타베이스 서버에서 작동하는 많은 수의 쿼리를 디스크에서 메모리로 MySQL 임시 디렉통리를 변경하면 획기적으로 속도를 개선 가능합니다.
로드가 느린 쿼리가 포함된 일반적으로 최적화되지 않은 워드프레스 데이타베이스인 경우 이 설정은 큰 성능 개선이 가능하다고 하는데요.
이를 위해서 는 tmpdir을 램디스크인 tmpfs 디렉토리로 설정하면 성능을 개선할 수 있습니다.
램디스크인 tmpfs 위치가 어디인지를 확인하려면 df -h 명령어를 사용합니다.
일반적으로 linux의 fstab 파일에는 tmpfs가 /dev/shm가 기본으로 지정되어 있습니다.
이 램디스크가 리부팅해도 계속 존재하려면 fstab에 등록을 해야하죠. 그러기 위해서 먼저 MySql id를 찾습니다.
아래 명령를 사용하면 uid 및 gid 값을 알 수 있습니다.
id mysql
uid=114(mysql) gid=116(mysql) groups=116(mysql)
fstab 파일 편집
편집기를 통해서 fstab 파일을 편집 상태로 만들어 램디스크를 등록합니다.
여기에서 여기서는 위에서 검색했던 uid와 gid 정보를 활용합니다. nano /etc/fstab
tmpfs /dev/shm/mysql tmpfs rw,gid=116,uid=114,size=768M,nr_inodes=50k,mode=0700 0 0
램디스크 마운트
이렇게 만들어진 램디스크를 마운트 합니다.
그 전에 nginx를 재부팅합니다.
service nginx restart
mount -a
4. 시스템 적용하기
위와 같이 데이타베이스 최적화 옵션을 반영했다면 마지막으로 MySQL 등을 다시 시작합니다. 그러면 위 설정들이 반영되게 됩니다.
service mysql restart
service php7.2-fpm restart
service nginx restart
그러면 제대로 반영되고 있는지 확인해 볼까요?
먼저 MariaDB로 접속합니다. 패스워드를 치고 들어갑니다.
@happist:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g. 이하 생략
~
다음으로는 SHOW VARIABLES LIKE 'tmpdir'; 명령으로 tempdir을 출역토록 합니다.
~~~javascript
MariaDB [(none)]> SHOW VARIABLES LIKE 'tmpdir';
+---------------+----------------+
| Variable_name | Value |
+---------------+----------------+
| tmpdir | /dev/shm/mysql |
+---------------+----------------+
1 row in set (0.02 sec)
음 , 정상적으로 tmpdir은 설정한대로 /dev/shm/mysql에 위치하고 있음을 알 수 있습니다.
2018년 새해 벽두부터 300여명의 헐리우드 여배우들을 비롯한 많은 여성들이 직장에서의 성희롱과 부정행위를 근절하기 위한 운동에 나셨다고 하네요.
그들은 블루 컬러 여성 노동자들을 지원하기 위해 1300만달러 법적 방어 기금을 모금했습니다.
이 운동은 #TIMESUP으로 명명되어 벌써 트위털를 통해서 활발하게 전파되고 있고 여기에는 Shonda Rhimes, Ashley Judd, Eva Longoria, Reese Witherspoon과 같은 할리우드 배우들이 동참하고 있습니다.
이 운동은 특히 블루 컬러에 초점을 맞추고 이들이 종사하는 미국 전역의 직장에서의 성희롱 퇴치, 성평등을 지지하는 캠페인을 지원하고 있습니다. 그동안 성희롱 문제가 주로 영향력이 큰 헐리우드 중심으로 전개된 데에 대한 비판이 있었는데 이에 대한 반작용인지는 모르지만 이번에는 그동안 외면받았던 블루 컬러 여성 노동자를 중심에 두고 시작되고 있습니다.
300여명의 헐리우드 여배우들이 서명한 공개 서한을 담은 편지가 2018년 1월 1일자 뉴욕타임즈와 스페인어신문 라 오피니언 (La Opinion)에 전면광고로 실렸습니다. 아래 그 편지 내용중 일부입니다.
“Harassment too often persists because perpetrators and employers never face any consequences. This is often because survivors, particularly those working in low-wage industries, don’t have the resources to fight back,”
직장에서 가해자나 고용주 모두 아무런 책임을 지지 않았기 때문에 직장에서 성히롱은 너무 자주 발생합니다. 이는 저임금 산업에 종사하는 노동자들이 이러한 성희롱에 반격할 아무런 힘이 없기 때문에 더욱 더 그렇습니다.
I stand with women across every industry to say #TIMESUP on abuse, harassment, marginalization and underrepresentation. START YOURYEAR OFF RIGHT. Join me! Sign the statement of solidarity & donate to the @TIMESUPNW Legal Defense Fund: https://t.co/BYckTp8eNmpic.twitter.com/pNfLvsz8xV
I signed this letter of solidarity 2 stand with women across every industry: #TIMESUP. The @TIMESUPNOW Legal Defense Fund provides subsidized legal support across industries 2 those who have experienced sexual harassment, assault, or abuse in the workplace. #DueProcesspic.twitter.com/NyTN7iKwuf
스냅챗은 받는 사람이 메세지를 확인하면 바로 사라지는 일명 ‘단명 메시지’로 뜬 미국의 메세지 서비스죠. 10대를 비롯한 사생활이 노출되는 것을 꺼리는 사람들에게 인기를 끌었습니다.
그리고 2013년 10월 스냅챗은 “Snapchat Stories”라는 기능을 추가하면서 한번 더 도약할 수 있는 계기를 만들었습니다. 이 기능은 사진이나 동영상을 스냅샷에 공유하면 24시간 후에는 자동 삭제되는 기능으로 24시간 동안은 누구나 시청할 수 있습니다.
▽ 요즘 핫한 방탄소년단 스냅챗 스토리 동영상
https://youtu.be/jfHWcKOfHLs
그런데 2016년 8월, 페이스북은 인스타그램 스토리 기능을 런칭합니다. 스냅챗의 카피라는 욕을 먹었지만 인스타그램의 특성과 페이스북 인프라에 힘입어 단숨에 스냅챗을 앞지르게 됩니다. 아마 2017년 중반부터는 인스타그램 스토리 사용자가 스냅챗 스토리 사용자를 능가하게 되죠.
▽ 스냅챗 사용자 및 인스타그램 스토리 사용자 증가 추이 Graph by recode
이러한 인스타그램의 추격을 뿌리치고자 스냅챗은 “Stories Everywhere”라는 서비스를 준비하고 있습니다.
아직 개발 단계이긴하지만 이 서비스는 스냅챗에서 만든 비디오를 다른 플랫폼에 올릴 수 있도록하며, 또한 스냅챗 공개 큐레이션 컬렉션인 “Our Stories”에 다름 앱이 접속해서 스토리를 공유할 수 있도록 기획되고 있다고 합니다.
Executive Summary
스냅챗이 ‘Stories Everywhere’ 서비스를 강화하는 이유는 아래와 같이 3가지로 정리할 수 있습니다.
첫째, 스냅챗 이외의 플랫폼에서 스냅챗 컨텐츠를 경험해보고 스냅챗으로 넘어오는 스냅챗 신규 사용자 유입 강화
둘째, 스냅채 외 플랫폼에 컨텐츠를 노출함으로써, 더 많은 노출 확대를 원하는 인플러언서(influencers)를 확대하고 스냅챗 중심으로 컨텐츠 배포
셋째, 스냅챗 컨텐츠가 다양한 플랫폼 및 사이트에 노출됨으로서 광고 수익 기회 확대
1. 스냅챗이 ‘Stories Everywhere’ 서비스를 강화하는 이유
왜 스냅챗이 이런 시도를 강화하는지를 BI Inteeligence에서 분석했는데요. 이 내용을 간략 공유해 보겟습니다.
첫째, 스냅챗 앱에 들어있는 풍부한 사용자 제작 컨텐츠를 무료로 풀면서 새로운 사용자를 유치할 수 있습니다. 스냅챗에는 매일 35억 개의 스냅이 만들어지며, 스냅챗은 검색 및 스냅 맵을 위해 하루 수백만개의 스토리 인덱스를 만듭니다. 이는 스냅챗이 광범위한 잠재 고객에게 어필 할 수 있는 중요 컨텐츠를 보유하고 있다는 것을 보여 줍니다. Stories Everywhere를 사용하는 스냅챗 미가입자는 스냅챗에 가입해 자신의 관심사에 맞는 이야기기들을 더 볼 수 있습니다. 이것으로 스냅챗은 치근 가입자가 둔화된 현 상황을 타개 할수 있습니다.
1.2. 노출 확대를 통한 인플러언서(influencers) 확대
둘째, 스냅챗 헤비 사용자의 앱 검색 능력을 강화할 수 있습니다. Stories Everywhere는 스냅챗 사용자의 컨텐츠가 스냅챗 사용자 1억 7천 8백만명외의 사람들에게도 노출 할 수 있는 기회를 제공합니다. 이는 콘텐츠 제작을 촉진할 수 있고, 스냅챗의 영향력을 강화할 수 있습니다. 스냅챗은 주요 인플러언서(influencers)들에게 플랫폼에서 검색이 더 잘 될 수 있도록 그들이 사용하는 앱 리스트를 재조정하도록 설득하고 있습니다. 인플러언서(influencers)을 확대하는 것은 스냅챗에게 커다란 도우움을 줍니다. 인플러언서(influencers)와 같은 인기있는 사용자는 엄청나게 많은 팔로워를 스냅챗 플랫폼으로 가져올 수 있기 때문입니다.
1.3. 광고 수익 기회 확대
셋째, Stories Everywhere는 더 많은 광고 수익 기회를 만들 수 있습니다. 예를 들어 스냅챗 스토리를 배포하는 제3자 웹 사이트에서 광고를 운영할 수 있습니다. 페이스북과 인스타그램은 다른 플랫폼에 스토리 공유를 허용하지 않기 때문에 브랜드들은 여기에 광고를 집행하는 경향이 있습니다. 추가 광고 수익을 얻는 것은 기업 공개 후 매분기마다 기대 수익을 맞추지 못했기 때문에 스냅챗으로서는 매우 중요합니다.
2. 스냅챗 Stories Everywhere 문제점
스냅챗이 Stories Everywhere는 친한 친구끼리 상호 작용할 수있는 플랫폼으로써의 Snapchat의 핵심 정체성을 벗어날 수 있습니다. 2017년 11월 스냅챗이 밝힌 바에 따르면 스냅의 60%가 매우 가까운 친구끼리 주고 받은 스냅이었으며, 이러한 스냅가운데서 자연스럽게 브랜드 광고가 이루어지는 프랫폼이 되었다고 합니다. Stories Everywhere는 스냅챗의 폐쇄성을 약화시킬 것이며 스냅챗 앱의 친밀성에 익숙한 사용자들을 실망시킬 수 있습니다.
2018년 연초, 격변하고 있는 이 시점에 미디어의 미래에 대해서 잠시 생각해 보는 것도 나쁘지 않은 것 같습니다. 특히 마케터라면 말이죠.
미국의 마케팅 조사 및 컨셜팅 업체인 BI Intelligence는 “14 Things You’ll Want to Know About the Future of Media”라는 보고서를 공개했습니다. 이 보고서는 BI Intelligence 회원에게 무료로 배포하느 보고서임데요. EXCLUSIVE FREE SLIDE DECK: 14 Things You’ll Want to Know About the Future of Media 이 주소로 접속하면 얻을 수 있습니다. 혹시 몰라서 이 포스티의 마지막에 PDF를 첨부해 놓았습니다. 다만 조회만 가능하게 해 놓았습니다. 제가 저작권자가 아니라서 배포할 수는 없을 것 같습니다.
내용은 매우 평이하게 PT 덱 형식으로 되어 있어서 잠깐이면 전체 내용을 살펴볼 수 있습니다. 그 동안 알려진 내용을 토대로 BI Intelligence의 인사이트를 담았으므로 일독할 만합니다.
여기서는 간단하게 그 내용을 소개하도록 하겠습니다. 좀 더 자세한 내용은(워낙 간단하게 작성된 덱이라 복잡하지는 않습니다.)
다만 아직 공력이 부족해서인지 BI Intelligence에서 주장하는 바가 다 이해되는 것은 아닙니다. 미국 중심이라고 그렇까요?
Executive Summary
미디어의 미래에 대한 BI Intelligence의 인사이트는 아래와 같이 list-up될 수 있습니다.
이미 미디어 사용은 역대 최고치에 도달하고 있음. 멀티 태스킹으로 매일 31시간 활동하면 이중 12신을 미디어에 사용.
앞으로는 경쟁력 있는 미디어를 가장 편한 방식으로 소비, 공유, 이야기할 것이다.
미디어 증가는 개발도상국에서 활발하게 진행할 것이다.
디지탈 광고는 선진국에서도 성장중이며, 아시아의 성장이 매우 빠르다.
새로운 TV 네트워크가 동영상을 포함한 비디오 보급을 지배할 것이다.
기존 인쇄 매체의 비디오 미디어로의 전환만이 답은 아니다.
미래에 모든 미디어는 곧 비디오 미디어가 되는 것은 아니다.
스마트 스피커 및 자가 운전 자동차에서 미디어 사용 증가는 과장 되었다.
AR은 도처에서 구현될 것
“social stories.”에서 거대한 성장 예상
광고 독점은 현실이다.
광고 유통 플랫폼은 유통 컨텐츠에 책임을 져야.
이제 혁신적 디지탈 광고가 등장하고 있다.
아직 최적의 디지탈 미디어 광고 모델은 없다.
1. 최고치에 달한 미디어 사용, In the US, we’re nearing “peak media.”
미국에서 미디어 사용은 역대 최고치에 도달하고 있습니다. 사람들은 멀티태스킹을 통해서 매일 31시간 활동을 합니다. 이 중에서 12시간은 미디어와 테크 디바이스를 사용합니다.
업무 5시간
요리, 청소, 식사 등등 7시간
취침 7시간
미디어 및 테크 사용 12시간
디지탈 미디어 사용 시간이 6시간으로 가장 길다.
이마케터에 따르면 미디어 사용 시간중 가장 많은 시간(약 6시간)을 디지탈 미디어에 사용합니다.
향후 미디어 사용 시간 증가는 제한적
디지탈 미디어 사용이 이마케터의 조사대로 6시간까지 증가한 것은 데스크탑과 모바일 사용 증가에 따른 것입니다. 그러나 향후 미디어 사용 시간 증가는 제한적일 것입니다. 5년후인 2021년의 매일 매일의 미디어 사용 및 테크 디바이스 사용 시간은 현재에 비해 겨우 18분 증가에 그칠 것입니다. (Over the next 5 years, our daily media and tech consumption will grow by only 18 minutes)
미디어에서 디지탈 비중은 점점 증가하나 성장율은 둔화
이마케터에 따르면 미디어에서 디지탈 비중은 점점 증가하고 아날로그는 지속 감소할 것입니다. 그러나 디지탈의 성장율도 해를 거듭할 수록 둔화되고 있습니다. (2017년 2% 성장)
인터넷은 지역적 물리적 경계을 없애고 있음
인터넷은 그동안 기존 미디어 회사들을 보호해왔던 지역적 물리적 장벽을 날려 버리고 있습니다.
이제 모든 회사들은 제한된 사람들의 관심을 끌기 위해서 경쟁하고 있습니다.
광고주들은 몇개의 빅 파트너와 협력하기를 원하며, 사람들은 역시 몇개의 빅 구독처만을 갖기를 원합니다.
그래서 무슨일이 일어날까요?
미래에는 더 많은 (미디어 회사간) 통합이 일어날 것입니다.
2. 경쟁력 있는 미디어를 가장 편한 방식으로 소비, 공유, 이야기할 것이다.
사람들은 항상 매력적인 이야기와 정보( “미디어”)를 원하며, 가능한 가장 편리한 방법으로 정보를 소비, 공유 및 이야기하고 싶어 합니다.
3. 미디어 증가는 개발도상국에서 활발
앞서 이야기한 미디어가 최고치에 달했다는 평가는 오직 선진국에만 해답하는 이야기입니다. 곧 40억명에 달하는 사람들이 온라인에 합류합니다.
4. 디지탈 광고는 선진국에서도 성장하며, 아시아의 성장이 빠르다.
사실, 아시아-태평양 지역은 조만간 가장 큰 디지털 광고 시장이 될 것입니다. 동쪽을 주시해야 합니다.
디지털은 글로벌로 확산되고 있습니다. 넷플릭스 가입자의 절반은 이제 미국외 글로벌에서 나오고 있습니다.
5. 새로운 TV 네트워크가 비디오 보급을 지배할 것
미국에서 기존 유료 TV 가입을 지속적으로 감소할 것입니다. 대부분 예상하는 내용이긴 합니다.
젊은 층에서 TV 시청이 살아지고 있습니다. 감소하는 게 아닌… 매년 30%~40%씩 감소하고 있으니깐요.
이에 반해서 새로운 TV 네트워크는 빠르게 증가하고 있습니다. 넷플릭스 가입자, 아마존 프라임 멤버쉽, 애플 TV 설치수 그리고 Hulu 가입자가 빠르게 증가하고 있습니다. 특히 2017년에 Hulu의 증가세가 눈부시군요.
새로운 TV 네트워크는 사용하기가 더 편하며 더많은 가격대비 가치를 가지고 있습니다. 그리고 전통 미디어를 발라버리고 있습니다. 예를 들어 애플 TV나 넷플릭스는 AMC같은 전통 케이블 네트웍을 압도하고 있습니다. 또한 유튜브는 광고 매출에서 CBS를 압도하고 있습니다.
디지탈 라디오도 천천히 성장하고 있습니다. 미국에서 2017년 매주 온라인 라디오를 듣는 비율이 53%로 5년전 29%에 비해서 크게 증가했습니다.
디자탈 오디오인 Podcast 광고도 급증하고 있습니다.
6. 인쇄 미디어의 비디오 미디어로의 전환만이 답은 아니다.
비디오 미디오로 전환이 어려움을 격고있는 인쇄 미디어를 구할 수 있다는 이론은 틀릴지도 모릅니다. The theory that a “pivot to video” will save struggling text publishers is nuts.
7. 미래에 모든 미디어는 곧 비디오가 되는 것은 아니다.
마찬가지로 모든 미디어는 곧 비디오 미디어가 된다는 이론 역시 틀렸습니다. The theory that all media will soon be video is also nuts.
8. 스마트 스피커 및 자가 운전 자동차에서 미디어 사용 증가는 과장 되었다.
스마트 스피커 및 자가 운전 자동차가 미디어 소비를 증가시키겠지만 생각만큼 증가하지는 않을 것입니다.
스마트 스피커 사용자들은 미디어를 더 소비하겠지만 그렇게 많지는 않습니다. 현재 많은 소비는 음악에서 일어나고 있습니다.
사람들은 1년에 2주에 해당하는 시간을 차안에서 보내지만, 이미 운전자들은 이미 음악을 듣고 있으며, 승객들은 스마트폰으로 미디어를 소비하고 있습니다. 그렇기에 자율운전자동차가 등장해도 미디어 소비가 폭발적으로 증가하지는 않습니다.
9. AR은 도처에서 구현될 것
AR은 도처에서 구현되고 가상 현실(VR)은 대부분 게임과 교육 훈련에서 활용될 것입니다.
10. “social stories.”에서 거대한 성장 예상
소셜 비디오 시청이 폭발적으로 증가하고 있습니다. 이속에서 “social stories.”가 새로운 종류의 스토리로 확대되고 있습니다.
11. 광고 독점은 현실이다.
구글과 페이스북에 의한 광고 독점은 새로운 것이 아닌 사실 그 자체입니다.
거대 광고 배급자는 항상 미디어에서 엄청한 파워를 가지고 있습니다. 그리고 거대 미디어 유통업체는 거대 미디어를 필요로 합니다. 대형 디지털 유통 업체는 이미 콘텐츠 제작자와 실질적인 자본을 공유하고 있으며, 이러한 정도는 매년 강화되고 있습니다.
12. 광고 유통 플랫폼은 유통 컨텐츠에 책임을 져야.
예전처럼 광고 유통 플랫폼은 유통시키는 컨텐츠에 대해서 책임을 져야 합니다.
13. 이제 혁신적 디지탈 광고가 등장하고 있다.
우리는 마침내 혁신적인 디지털 비디오 광고를 보기 시작했습니다!
스마트폰에서 30초 광고를는 TV에서 한시간짜리 정보를 전달하는 광고 즉 Informercial과 같은 같습니다.
소비자들은 건너 뛸 수 있는(skippable) 짧은 디지털 비디오 광고를 더 잘 수용합니다.
사람들은 관심있는 ‘건너 뛸 수 있는(skippable)’광고만 보면, 어떤 사람들은 이를 끝까지 시청합니다.
14. 아직 최적의 디지탈 미디오 광고 모델은 없다.
광고, 구독, 전자상거래 및 하드웨어가 모두 작동하는 최적의 디지탈 미디어 광고 모델은 없습니다.
미디어 미래는 더 한층 좋아질 것입니다. The future of media is getting better all the time.
![[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck](https://happist.com/wp-content/uploads/2018/01/Featured_Fast-터널-tunnel-mathew-schwartz-397471-768x345.jpg "[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck")
![[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck 1](https://www.vultr.com/media/banner_3.png "[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck 1")
![[워드프레스 최적화] MySQLTuner 사용 워드프레스 데이타베이스 튜닝 방법](https://happist.com/wp-content/uploads/2018/01/Featured_Fast-자동차-toine-garnier-396670-768x345.jpg "[워드프레스 최적화] MySQLTuner 사용 워드프레스 데이타베이스 튜닝 방법")
![[워드프레스 최적화] gzip 압축으로 워드프레스 로딩 속도를 개선 방법](https://happist.com/wp-content/uploads/2018/01/nxinx-서버에서-gzip-압축-설정법-768x345.jpg "[워드프레스 최적화] gzip 압축으로 워드프레스 로딩 속도를 개선 방법")
![[워드프레스 최적화] FastCGI 적용 워드프레스 반응 속도 및 서버 로드 줄이기](https://happist.com/wp-content/uploads/2017/05/Featured_고속도로_야경_highway-216090-1-768x327.jpg "[워드프레스 최적화] FastCGI 적용 워드프레스 반응 속도 및 서버 로드 줄이기")
![[워드프레스 최적화] 스왑 메모리 설정으로 워드프레스를 안정적으로 운영 하기](https://happist.com/wp-content/uploads/2011/05/Featured_파텍-필립Patek-Philppe-Patek-Philippe-Institutional-close-up-of-mens-black-watch-768x338.jpg "[워드프레스 최적화] 스왑 메모리 설정으로 워드프레스를 안정적으로 운영 하기")
![[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법](https://happist.com/wp-content/uploads/2016/08/마리안디비-MarianDB-1-768x453.jpg "[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법")
![[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법 4](https://happist.com/wp-content/uploads/2019/05/워드프레스-최적화_시스템-폴더-리스트.png "[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법 13")
Reload document 
Open in new tab