홈페이지 속도에 도움이되는 팁 > 그누4 팁자료실

그누4 팁자료실

그누보드4와 관련된 팁을 여러분들과 함께 공유하세요.
나누면 즐거움이 커집니다.

홈페이지 속도에 도움이되는 팁 정보

홈페이지 속도에 도움이되는 팁

첨부파일

minify-2.1.7.zip (532.5K) 89회 다운로드 2013-11-01 18:55:18

본문

구글에서 받아온 파일입니다 minify 최신버전을 다운받습니다. 현재는 minify 2.1.5 버전입니다.

2. 압축해제 한후, min 폴더내의 config.php 파일을 에디터에서 불러오기 합니다.

3. 47번째쯤 라인의 //$min_cachePath = '/tmp'; 라는 부분을 $min_cachePath = './tmp'; 로 수정합니다.

4. min 폴더안에 tmp 라는 폴더를 새로 만들기합니다.

5. min 폴더를 FTP 로 서버의 루트디렉토리에 업로드합니다.

6. 서버에 업로드된 min 폴더안의 tmp 폴더의 퍼미션을 707 로 권한 변경합니다.

7. g5 설치폴더안의 .htaccess 파일을 에디터에서 불러오기합니다.

8. 아래의 2가지 경우중 해당되는 구문을 .htaccess 파일의 맨 아랫줄에 추가합니다.

g5 설치경로가 /g5/ 로 사용되는 경우
RewriteRule ^(.*\.(css|js))$ ../min/index.php?f=xe/$1 [L]

g5 설치경로가 루트디렉토리인 경우
RewriteRule ^(.*\.(css|js))$ /min/index.php?f=$1 [L]

9. 수정한 .htaccess 파일을 g5 폴더에 덮어쓰기 합니다.


아주 작은 팁이지만 트래픽에 유용합니다.

적도 쓰고 있는데요 속도도 좋아서요 그리고 트래픽에서도 도움이되니다.
추천
4

댓글 43개

자스, css 압축, HTTP request 를 줄이고, 웹캐싱하고, CDN 사용하고... 자스는 pre로더로 asynchronously 로딩해주고... 이미지는 스프라이트 처리해주고.... 이딴 거 서버 기술자가 보면 그냥 피식 웃게되는 것 들 입니다.

아파치 쓰면서 이런 잡스러운 것들을 하는 것 보다 그냥 엔진X 로 서버 옮기면 저 잡스러운 모든일을 해서 얻어지는 속도향상보다 한방에 더 많은 속도향상을 얻습니다.

 http://hackya.com/ko/nginx-vs-apache/
HackYa님이 제작하신것들 전문가들이 보면 참 잡스럽겠네요^^.
왜 팁게시판에서 이리 날리 피우시는지?
잘알면 잘아는 사람답게 이렇게 사용하면 더좋을껍니다. 라는말은 냅두고
굳이 이게 좋다니 저게 좋다니

그누보드 초보자들이 많이들 팁게시판 애용하실텐데 하는짓이 잡스러운짓을 하시네요^^

팁이라는 단어 모르세요?
말뜻 이해부터 하시고 오세요^^

엔진X 좋은거 압니다.
근데 그거랑 팁이랑 뭔상관입니까?

어린분들이 보면 왜저러나 하실껍니다.
저부터 저런 실행착오들을 오랫동안 겪어 왔기에 이런 "잡" 스러운 대응들이 큰 효과가 없다는 걸 얘기하려고 한 겁니다.

근본적인 문제해결을 하지 않고, 반창고만 덕지 덕지 붙여놓으면 그 상처를 치료하는데 큰 도움이 되지 않습니다.

상처가 곪아서 자꾸 고름이 세어나오는데, 아 그럴때는 더 큰 반창고를 붙이세요. - 네 이것도 물론 도움이 되는 팁일수도 있겠죠. 

그런데 반창고를 큰거를 사용하는 것은 근본적 문제 해결이 아니니 항생제를 처방받아서 드세요 라고 말하는게 "잡스러운 짓" 입니까?

그리고 제가 scripting 해놓은것들도 전문가들이 보면 그냥 피식 웃음이 나오죠.  당연한거죠. 그런데요?
같은 말이라도 "아"다르고 "어" 다르다고 합니다..
사람의 말투에서 그 사람의 인격을 알수 있듯이 글도 그와 같다고 생각합니다..
HackYA님이 보시기에 비록 이건 맞고 저건 틀릴지언정 상대방의 입장을 조금이라도 생각을 하고 말씀을 하신다면 HackYA님의 글을 본 다른 사람들도 또 하나의 조언을 듣고 또 다른것을 배우게 될 것입니다..

아무리 많은 지식을 가졌던들 표현하는데 있어 부적합하다면 누가 그 사람을 따르고 그 사람에게 배우려 하겠습니까..
물론 HackYA님께서 누구에게 존경받고 대우받으로고 이러한 조언을 하는 것이 아니라고 생각을 합니다..

다 SIR회원님들과 프로그래밍을 하는 회원님들께 도움이 되고자 한다는 것도 알지만 좀더 부드러운 말투로 임해주시면 당사자 뿐만 아니라 다른이들도 반감을 사는 일은 없을 것이라 생각이 됩니다..
또한 이것이 지식인으로서 갖춰야 할 자세라고 감히 생각도 해봅니다..

HackYa님께서도 실행착오들을 오랫동안 겪어 왔기에 이런 "잡" 스러운 대응들이 큰 효과가 없다는 걸 얘기하려고 했다고 했습니다...
제가 보기에는 HackYa님께서는 프로그래밍에 있어 실행착오를 최소화 하고 있다고 생각은 들지만 한편으로는 살아가는데 있어 대인관계에서 만큼은 큰 실행착오를 겪고 계신듯 합니다..

부디 이것이 웹상에서만 그런 것이지 실제 삶에서는 그러지 마시길 감히 조언해 드리겠습니다..
직설적인 표현은 얼굴 맞대고 욕해도 다음날 웃으면서 술한잔 할 수 있는 친구에게나 통하는 것입니다..
얼굴 한번 보지 못하고 알지 못하는 사람에게 그리한다면.. 음....... 아시죠? ㅎㅎ

이글을 읽고 기분 상하셨다면 대단히 죄송합니다..
하지만 저희들도 HackYa님의 글을 읽으면 이건 아닌데... 하는 생각이 들곤 한답니다..
부디 이점 이해해 주시고 다음에는 더 멋진 표현 더 멋진 팁 기대하겠습니다..^^
?? 죄송합니다.

제가 뭐가 문제인지 이해를 하지 못하고 있는듯합니다.

님이 쓰신 글을 자세히 다시 읽어 보았는데

아무래도 trivial 한 ("잡"스러운) 부분에 신경쓰는게 큰 도움이 되지 않는 표현이 부정적으로 받아들여지고 있는 듯 합니다.

아 다르고 어 다르다는 말씀을 하시는 것 보니... 그렇게 밖에 이해가 되지 않네요.

제 생각이 맞다면 어떻게 표현을 하는게 더 좋은 표현인지 구체적인 예를 들어주시면 감사하겠습니다.

scripting 할때도 example 을 누가 보여주면 쉽게 따라할 수 있어서요...

구글 번역기를 돌려보니 trivial 이 "하찮은" 으로 번역됩니다.

"잡"스러운 이라고 표현하지 말고 "하찮은 것들에" 라고 표현을 하는게 더 옳은 표현이었나요?

정말 몰라서 여쭈어 봅니다.
trivial 이 어디서 튀어나온거지요.?

하찮은 이라고 번역되는데, 잡스러운은 어디서 나온건지......

http://translate.google.co.kr/#auto/ko/trivial
그러니까 잡스러운  보다 하찮은 이란 표현이라고 하는게 더 바람직한 표현이란 말씀이시죠?

바꾸려고 해도 댓글이 달려 바꿀수가 없으니

잡스러운 => 하찮은 으로 이해해 주시면 감사하겠습니다.

This is what I wanted to say in Korean. 

Instead of focusing on trivial issues, people should change their server to Nginx.
제말은 이거죠.

아파치 쓰면서 저런 잡스러운 것들 다 해봐야, 엔진X 로 서버 한번 바꾸는 것 만큼도 못하다.

이게 자동차랑 똑같더라구요.  자동차의 성능을 높히기 위해서 엔진오일 좋은거 쓰고, 에이필터 깨끗하게 유지해 주고, 휘발유는 high octane 써주고, 이런건 어떤 자동차 주인이라도 물론 다 할수 있죠.

단지 이렇게 자동차의 성능을 최상으로 유지한다고 해서, 4기통짜리 자동차가 6기통짜리 자동차 성능을 내지 못하더라, 이 얘기 하는 것 입니다.

모바일 페이지의 경우 RWD 로 아무리 죽어라고 자스를 최소화 하고, 이미지 사이즈를 줄이고, 별짓을 다하더라도, 별 생각없이 RESS 로 짠 페이지에 비해도 현저하게 로딩이 늦어지는거죠.  태생적인 한계는 벗어날 수 가 없다고 생각합니다.

좋지않은 기술/플랫폼을 선택해 놓고, 그 플랫폼 위에서 사이트의 기능을 향상시키려고 해봤자 아무런 의미가 없다는 얘기 입니다.
아파치에 대해서 잘 모르면서 nginx 가 최고다라고 하죠.
웹서버의 성능으로만 따지면 nginx 가 더 빠릅니다만. 그렇게 따지면 lighttpd 가 더 빠르죠.

정적 컨텐츠만 다루는게 아니니 각 모듈이 붙어서 작동되는 상황을 봐야 합니다.

apache 에도 prefork, worker, event .. 작동방식이 상이한데,
벤치마크를 보면 prefork 상태의 아파치를 벤치마크로 선택합니다.
worker 나 event 방식으로 비교해보면 nginx 랑 큰 차이도 없을뿐더러.
부하가 심한 php 파일일 경우아파치가 더 빠릅니다.

아마존의 aws 에서 nginx 와 apache 의 성능 비교한 글인데, 서버 사양이 높아질수록 아파치가 더 빠릅니다.
memcached 를 적용하면 nginx 가 더 빨라지지만.
http://blog.celingest.com/en/2013/02/25/nginx-vs-apache-in-aws/
잘 아시겠지만, 엔진X 나 아파치나 php 처리속도는 비슷합니다.

그런데 웹사이트가 php 로만 이루어지지는 않죠. html 도 있고, css 도 있고, 자스도 있고 이미지도 있습니다.

속도의 차이가 나는 부분은 이 static file 처리에서 입니다.

그리고 reference 하신 페이지의 결론은 이렇습니다.

Conclusions:

As we can see from the graphics on small instances Nginx prevails always, especially on high concurrency where the Nginx event driven worker show its power running on one core showing a percentage increment between 49% and 201%. While on multicore instances we can see that Nginx, sometimes, suffers a small gap on “pure” WordPress (due to the workers = 1 setting) using file caching or memcached results are always favorable to nginx with a maximum percentage increments of 268%. Beside of the Nginx Vs Apache benchmark we clearly see that caching WordPress is imperative and a plugin that uses correctly Memcached is a must-have.

메모리가 작은 경우 항상 엔진X 가 더 앞선다.  multicore 인 경우 Nginx 가 약간의 갭 (성능저하) 가 나타나는데 이것은 worker_process 를 1 로 잡았기 때문이다.

worker_process 를 1로 잡은 이유는 순수하게 아파치와 성능을 비교하기 위해서 그렇게 한 것 같은데 실제로 worker_process 를 1로 잡는 사람은 없겠죠.  1은 그냥 default setting 일뿐 입니다. multicore 이면 core 숫자대로 worker_process 를 잡아야지 왜 1로 잡는지 이해불가...

저의 클라우드 서비스 제공자 rackspace 의 경우 4로 잡으라고 합니다.

http://www.rackspace.com/knowledge_center/article/ubuntu-and-debian-nginx-configuration

말이 좀 안되는 상황이죠.  메모리를 7.5GiB 으로 높게 잡으면서 core 가 1개 뿐이라니...  왜 저렇게 테스트를 했는지는 모르겠으나, 그럼에도 저 글은 Nginx 가 더 유리하다는 것을 말하고 있습니다.

"서버 사양이 높아질수록 아파치가 더 빠릅니다."

아닌데요.

마지막 bar graph 를 보셔도 아실 수 있듯이, HyperCache 와 memcached 가 동일하게 적용된 경우 7.5 GiB memory 에서 (사실 개인 홈피나 소규모 사이트에서 메모리를 이렇게 높게 잡는 경우는 없습니다.  일단 비용이.. ㅠㅠㅠㅠ) 엔진X 가 월등히 더 빠릅니다.


"그렇게 따지면 lighttpd 가 더 빠르죠."

아닌데요.


Nginx performed almost the same as lighttpd but cpu load was much better with nginx. (LA never got more than 5 while lighttpd bumped it up to ~10, and apache to 20+ while testing with the wordpress setup) Btw, can't even compare it to apache, which almost crashed my box when testing the sample wordpress install.( 10000 requests, 1000 concurrent)
 
엔진X 와 lighttpd 속도는 거의 동일하나 CPU 로드에 있어서 엔진X 가 더 우월하다. 

http://www.wikivs.com/wiki/Lighttpd_vs_nginx

가장 트래픽이 많은 순서로 1000개의 사이트를 살펴보면 아파치 보다 엔진X 를 쓰는 사이트들이 더많습니다.

http://wpengine.com/2013/07/08/nginx-overtakes-apache-as-the-server-of-choice-for-the-top-1000-trafficked-sites/

알찬돌삐님 말씀대로 메모리가 커질수록 아파치의 성능이 더 빨라진다면, 전세계에서 가장 규모가 큰 사이트 1000개 운영자들 중 엔진X 를 쓰는 사이트 관리자들은 뭐죠?

그들은 왜 엔진X 를 쓰는걸까요? 

네이버가 멍청해서 엔진X 를 사용하고 있지는 않을 겁니다.

더구나 엔진X 는 역사가 오래된 아파치보다 엔진X 를 다룰줄 아는 서버관리자가 턱없이 부족해서 비용면 (인건비)으로 봤을때 한국이나 미국이나 훨씬 더 불리합니다.

아파치 쓸줄 아는 사람보다 엔진X 를 쓸줄 아는 엔지니어들의 숫자가 부족하니 인건비가 오를수 밖에 없습니다.  그럼에도 불구하고 트래픽이 가장 많은 사이트들이 엔진X 를 더 많이 쓰고 있다는 사실은 무엇을 말하고 있습니까?

아파치가 성능면에서 더 유리하지 않다는 것 입니다.  인건비를 따진다면 아파치를 쓸수도 있겠지만, 성능을 따진다면 아파치를 쓸 이유가 없는 것 입니다.

//////////////////////////////////////////////////////////////////////////////////////////////////////

사용하기도 더 까다로운/낫설은 엔진X 의 시장점유율은 점점더 늘어가고 아파치의 시장점유율을 점점더 줄고 있습니다. -

이 사실 하나로도 사실 어느 서버가 더 성능이 우월한지 길게 얘기할 이유가 없다고 봅니다.
엔진x 엔진x ... 말들은 많은데 실상 사용해보면 그렇게 차이가 나지 않는거 같더라구요.
(물론 대형업체는 다르겠지만요.)

시간이 널널하면 엔진x 에 대한부분을 파보고 싶네요.
대형/소형 사이트 차이가 아니라, 사이트에 static 한 부분이 어느정도 되느냐에 따라서 그 차이가 납니다.

sir.co.kr 같은경우 css 도 매우 간단하고  사용하는 자스도 hoverIntent 가 좀 무겁긴 한데 (사실 드랍다운 메뉴에 사용할 필요가 없어보이는데 왜 사용하시는지 모르겠더라구요) 많이 사용하고 있지 않습니다.

이런경우 엔진X 로 바꾼다고 큰 혜택을 볼수 없을 수도 있습니다.  이건 lighttpd 도 마찬가지 입니다.

엔진X 는 이미지, css, 자스(jQuery 같은 자스 library 등) 사용이 많은 사이트 일수록 큰 혜택을 봅니다.  php 부분은 거의 차이가 없습니다.

사이트 속도에 목메는 사이트의 경우 (쇼핑몰 같은 경우 이게 매상과 직결되니까) html 이 php 보다 훨씬 더 빨리 로딩되는 점을 착안, 일단 php 로 사이트를 짠 후, 이 중 변동이 없는 부분을 아예 영구적으로 html 로 바꿉니다.  이렇게 해놓고 엔진X 로 돌리는 거죠.

미친듯한 속도 (광속)가 나옵니다. 빛"광" 인지 미친 "광" 인지 암튼 그렇습니다. ㅎㅎㅎㅎ
팁인데..좋은거 올려주셨는데 저런 댓글은 쫌...
둘다 쓰면 장땡이죠.. 뭘 하나 쓰든 둘을 쓰던. 쓰기좋고 편하면 짱인걸..
서버 500대 이상 관리해 본 경험이 있는 본인은 피식 안하게 되는데요? minify 개발자가 고작 잡스러운거때문에 개인적인 시간을 낭비했겠습니까.
팁 감사합니다...^^

말을 하는데 있어서 상대방이 어떻게 받아들일지도 고려를 해야하는데 그렇지 못한 분들도 간혹 계시드라구요...^^;
나이를 떠나서 말이죠...^^
세상에 정답이란 없는건데....
죄송합니다..

제가그누보드에 눈팅만하다 자료하나 올리자료가 분쟁이되어네요..

저는 그런 의도로 자료올리게 아닌니다.

그저 조금이나마 도움되려나 해서 자료나누어 쓰면 좋은거같아서 올려는데 그만

자료도 못올리겠네요
죄송합니다.

잡스러운 => 하찮은 으로 이해해 주시면 감사하겠습니다.

http://translate.google.co.kr/#auto/ko/trivial

어줍지않게 센스있는 한국어로 표현을 해보려다가 상당히 부적절한 표현이 된 것 같습니다.
음... 이딴 거에 잡스러운..;;;;
본인이 알고 있는 지식으로 남의 글을 저렇게 평가하는 건 보기 좋아 보이진 않습니다.
더 나은 방법이 있으면 관련 정보만 올리시면 될 걸 불필요한 표현을 쓰셨군요.
죄송합니다.

잡스러운 => 하찮은 으로 이해해 주시면 감사하겠습니다.

http://translate.google.co.kr/#auto/ko/trivial

어줍지않게 센스있는 한국어로 표현을 해보려다가 상당히 부적절한 표현이 된 것 같습니다.
"이것도 좋지만 이러이러한것도 좋습니다."

"x까 잘알지도 못하면서 이게 더좋아."
-------------------------------------

컴퓨터만으로는 배울 수 없는게 있는거죠.
물론 minify 같은 툴을 설치해서 얻을수있는 효과는 그지 크지 않습니다.
그러느니 nginx 를 올리라 라는 말이 꼭 틀린건 아니라고 생각합니다만,

프론트 엔드단에서 최적화는 오히려 nginx 냐 apache 냐의 차이보다 훨씬더 크다고 생각합니다.

자스, css 압축, HTTP request 를 줄이고, 웹캐싱하고, CDN 사용하고... 자스는 pre로더로 asynchronously 로딩해주고... 이미지는 스프라이트 처리해주고....

이딴거들 말이죠. :) 웹사이트의 로딩은 서버에서 처리해주는 시간만 존재하는게 아니거든요.
## CENT OS 6 에 엔진엑스 설치




기존 APM 으로 돌아가던 사이트의 웹서버를 nginx 로 교체

정확히 테스트 하지 않았지만 반응속도 빨라진게 느껴진다. (기분 탓일 수도 있다)




`추가작업`




아파치에서 접속자의 IP 를 제대로 가져오지 못하는 문제가 있습니다. 하단에 추가 기록을 남김.







# 작업 목표




웹서버 를 엔진엑스로 교체하고 기존 PHP 가 돌아가던 아파치를 그대로 프록시 서버로 사용.







# 작업 과정




1. 8080 포트 확인




netstat -tnl




으로 8080 이 어떤 상태인지 확인




2. iptables 수정





vi /etc/sysconfig/iptables




필요한 포트를 열어주자





/etc/init.d/iptables restart




재시작해주고 열렸는지 확인




3. 라이브 서버라 웹페이지가 죽으면 곤란하기 때문에 8080 포트로 nginx 를 구동하고 임시 페이지들을 생성하여 테스트




4. nginx 의 리버스 프록싱이 잘되는지 서브도메인을 하나 따서 접속해본다





server_name nginx.testsite.com:8080;




proxy_pass http://testsite.com:80/;




  8080 도메인으로 접속했을 때 기존의 APM 으로 구동되던 80 포트 사이트가 정상접속해 줘야 다음으로 진행 가능하기 때문에 꼼꼼히 테스트...




5. 아파치의 포트를 변경해준다.




listen 80 을 listen 8080 으로 변경 및 버추얼 호스트의 도메인에 8080 추가





# httpd.conf




Listen 8080

ServerName testsite.com:8080

NameVirtualHost *:8080






# vhost.conf




<VirtualHost *:8080>

ServerName onweekend.co.kr:8080

</VirtualHost>




6. 엔진엑스의 포트를 변경한다. 엔진엑스를 죽인다.





/etc/init.d/nginx stop




7. 재빠르게 두 서버를 시작 및 재시작 해준다.





/etc/init.d/httpd restart && /etc/init.d/nginx start




8. 테스트 좀 해보고 엔진엑스 튜닝(그냥 구굴링해서 정당히 세팅해주면 사이트가 빨라져보인다). 파일 오픈 리미트도 좀 더 늘려주면 좋다.


ulimit  -n 65536




9. 8080 테스트가 끝났으니 8080 포트를 닫아둔다.




10. 엔진엑스를 리버스프록시로 두다보니 아파치가 사용자의 IP 값을 정확히 가져오지 못하는 문제가 있음




리버스프록시에 대응하는 아파치 모듈을 추가해야 함. 보통 함께 컴파일 되지 않은 경우가 많음.




Cent 계열은 아래 링크를 참고

http://stderr.net/apache/rpaf/

http://thegioinguonmo.com/os/linux/howto-install-modrpaf-apache-22.html




우분투 계열은 아래 링크를 참고

http://chrismorris.org/passing-ip-from-nginx-to-apache/

http://www.daveperrett.com/articles/2009/08/10/passing-ips-to-apache-with-nginx-proxy/




소스를 받아 설치






wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz

tar xvfz mod_rpaf-0.6.tar.gz

cd mod_rpaf-0.6

sed -ie 's/apxs2/apxs/' Makefile

make rpaf-2.0

make install-2.0





설치를 마치고 아파치 conf 를 수정

추가된 세팅 값은 하단에 기록




아파치를 리스타트 하고 아이피가 잘 들어오는지 확인   










엔진엑스 세팅값





노드 코드를 돌릴 때와 같은 방식으로 파라미터는 세팅하였다.

단, 기존 NAMED 버추얼 서버 세팅에서 메인 사이트만 로컬도메인으로 세팅하여 도메인 룩업 타임을 줄여보자라고 생각하여 메인 사이트는 로컬 도메인으로 프록시 세팅.

나머지 잡다한 서브도메인들은 그냥 사용하던 도메인+8080포트로 매핑






user  nginx;

worker_processes  4;




error_log  /var/log/nginx/error.log warn;

pid        /var/run/nginx.pid;







events {

        use epoll;

    worker_connections  2048;

}




http {

    include      /etc/nginx/mime.types;

    default_type  application/octet-stream;




    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';




    #access_log  /var/log/nginx/access.log  main;

    access_log off;




    sendfile      on;

    tcp_nopush    on;




    keepalive_timeout  30;




    gzip  on;

    gzip_min_length 10240;

        gzip_proxied expired no-cache no-store private auth;

        gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

        gzip_disable "MSIE [1-6]\.";




    include /etc/nginx/conf.d/*.conf;

}











# for legacy site damn it php




server {

    server_name testsite.com www.testsite.com;

    root        /home/testsite/major;




        location / {

                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_set_header Host $http_host;

                proxy_set_header X-NginX-Proxy true;

                proxy_pass http://127.0.0.1:8080/;

                proxy_redirect off;

        }

}







server {

    server_name minor.testsite.com;

    root        /home/testsite/minor;




        location / {

                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_set_header Host $http_host;

                proxy_set_header X-NginX-Proxy true;

                proxy_pass http://minor.testsite.com:8080/;

                proxy_redirect off;

        }

}







추가된 아파치 conf 세팅







# Use apache behind nginx proxy




LoadModule rpaf_module modules/mod_rpaf-2.0.so




RPAFenable On

RPAFsethostname On

RPAFproxy_ips 127.0.0.1

RPAFheader X-Forwarded-For


한국은 많이 없네요 조금이나마 제글을 보고 도움이 되었습으면 합니다.
엔진 x는 조금 다루기가 힘들어요

아직은 한국분들도 많이는 사용하지안네요

미국 엔진x모듈로도 개발되어다고 하네요
2.domain.com으로 접근하면 192.168.74.2로 요청을 돌려주는 역할을 한다.
다만 도메인은 그대로 사용한다.
그리고 2.domain.com/test로 접근해도 192.168.74.2/test로 접근이 가능하겠다.


server {

listen  80;
server_name 2.domain.com;
location / {
proxy_pass http://192.168.74.2/;
index  index.php index.html index.htm;
}
}
비교대상이 잘못되었네요.
비교대상 apache 2.2 vs nginx 1.2 인데요.
비교할려면 apache 2.4 와 비교해야 합니다. nginx 는 비동기 io 를 쓰는데, 이건 동기식 io랑 비교하면 넘사벽입니다.
apache 는 2.4에서 비동기 io를 지원하니, 2.4랑 비교하는게 맞을것 같습니다.
php 5.2.1 버전 이상 사용하는 소스... 이하 버전도 있다고 하네요.

카페24 호스팅 사용자인데 영카트에서 적용이 안되더군요.
tmp 폴더에 파일이 쌓여야 정상이라고 하는데...

그러다 해결했습니다. 제대로 한 것인지는 몰라도...

www(root)폴더에 .htaccess 파일을 만들어 아래와 같이 수정
RewriteEngine On
RewriteRule ^(.*\.(css|js))$ /min/index.php?f=$1 [L]

www 폴더 상위 폴더에 .htaccess 파일이 원래 있더군요.
맨 아래 한줄 추가
RewriteEngine On

이러니 tmp 폴더에 파일이 생기더라구요. ^^ 카페24 호스팅 유저는 참조하세요!

혹 서브도메인에서 문제가 발생하면 심볼릭으로 해결해 보세요...
전체 3,313 |RSS
그누4 팁자료실 내용 검색

회원로그인

(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT