라이트스피드 Nginx보다 단점이 뭔가요?
XE는 라이트스피드에서도 잘 돌아가던데 Nginx이 훨씬 주목 받는 이유는?
PHP7은 HHVM을 거의 따라잡았네요 ㅎㄷㄷ..
마지막..!
-
-
(감탄 이모티콘) - [ㅇ0ㅇ]! -
h2o 부탁드려요 -
부랄을 탁!!!!!!~~ -
ㅎㄷㄷ.. 이분 무서워요..ㅜㅜ
-
?
ㅋㅋㅋㅋ 한바탕 웃고갑니다
-
이분 또 이러시네 ㅋㅋ 저번에도 한번 하셨으니 이젠 더이상 탁!!! 할 부랄이 남아있지 않겠는데요? ㅠㅠ
-
h2o
- 개발을 시작한 지 1년밖에 되지 않아서 아직 대규모로 쓰이는 곳은 없어 보이지만, 처음부터 오픈소스로 개발되었고 라이선스도 자유롭기 때문에 해외 오픈소스 커뮤니티의 반응은 좋음. nginx와 경쟁하며 서로의 성능을 끌어올려줄 웹서버가 하나 더 생겼다는 것을 환영하는 눈치임
- 처음에는 HTTP/2 지원을 내세웠지만, 이제는 아파치와 nginx도 HTTP/2를 지원하기 때문에 이것으로 차별화하기는 곤란해 보임 (nginx 1.8 안정화버전은 아직 HTTP/2를 지원하지 않지만, nginx 1.9 개발중버전이 h2o보다 더 안정적이라는 것이 함정...)
- 성능이 빠르지만, 실제로 그 성능을 유지하면서 쓸 수 있는 기능은 별로 없음. 예를 들어 좀 복잡한 rewrite 기능을 사용하려면 mruby라는 핸들러를 사용해야 하는데, 스크립트 언어인 ruby에서 파생된 mruby가 C언어로 구현된 nginx의 rewrite 기능처럼 빠를 리가 없음
- 현대의 웹 어플리케이션들은 복잡한 rewrite에 의존하지 않는 추세이며, 모든 요청을 일괄적으로 index.php로 넘겨버리는 워드프레스나 Laravel 같은 방식이라면 h2o 기본 기능만으로도 처리할 수 있으므로 위의 문제가 치명적인 것은 아님
- 그래도 사실상 대부분의 사이트가 PHP와 DB의 성능에 발목이 잡혀 있는 상태에서 웹서버 성능만 2배 빨라진다고 눈에 띄는 차이가 있을 것 같지는 않음. CSS/JS/이미지 파일만 처리하는 파일서버라면 얘기가 다를 수도 있지만, 실제로 차이가 느껴질 만큼 대규모의 사이트라면 그냥 CDN을 붙여버리는 것이 편함
- 좀더 시간이 지나봐야 알겠지만, nginx를 대체하기보다는 선의의 경쟁을 하는 관계로 발전할 것으로 예상되고, 아마 "이럴 때는 nginx를 쓰고 이럴 때는 h2o를 쓰는 것이 좋다"는 식으로 나올 것 같음
-
만세!
-
혹시 오해하실까봐 한말씀 드리자면 본래 무릎을 탁! 치는건데 조준이 좀 잘못되어서 그런겁니다 ㅠㅠ
-
그게 뭐야... 해명을 하시니 훨씬 더 무서움ㅎㄷㄷ.. 2번이나 조준이 실패라니 ㅎㄷㄷ..;;
-
상습적 팀킬 ㅋㅋ
빠른데도 안 쓰는 것은 다 이유가 있지요.
Litespeed
- 얼마 전까지 상용 프로그램이라 오픈소스 개발자들의 접근성이 좋지 않았음.
- 최적의 성능을 얻으려면 PHP 개발팀에서 공식적으로 지원하지 않는 lsphp라는 실행방식을 사용해야 함. (별도 컴파일이 필요하므로 대부분의 리눅스 배포판에서 쉽게 설치할 수 없음.)
- 오픈소스 Litespeed는 상용 버전의 시장점유율을 유지하기 위해 상용 버전보다 일부러 다소 뒤처지게 만들 가능성이 있으며, 상용 버전 개발사의 정책에 따라 개발 방향이 결정되므로 아무나 개발에 참여하기가 불편함. 반면, nginx는 상용 버전과 별도로 매우 활발하게 오픈소스 개발자들의 참여가 이루어지고 있음.
- 구글에 검색해 보면 아파치나 nginx보다 튜토리얼의 수가 심하게 부족하고, 그나마 대부분 개발사에서 제공하는 매뉴얼에만 의존하고 있음.
- 벤치마크를 보면 초당 수천~수만 회의 요청을 소화할 수 있을 것 같지만, 실제로 운영하는 사이트에서는 PHP 버전별 속도차이와 DB 쿼리 소요시간이 서버의 응답시간을 좌우하므로 어차피 초당 수십회의 요청밖에 소화할 수 없음. 이런 상황에서는 웹서버의 성능이 아무리 좋아도 체감하기 어려움. 대부분의 사이트는 PHP, DB 성능의 한계에 부딪히지, nginx 성능의 한계에 부딪히는 경우는 거의 없음. (위의 벤치마크도 워드프레스 캐시를 켜놓은 상태에서 측정한 것임. 즉 DB 쿼리 소요시간을 전혀 감안하지 않은 비현실적인 시나리오임.)
Phalcon
- 빠른 건 좋은데, 자기네가 발명한 Zephir라는 프로그래밍 언어로 작성하여 C언어로 번역한 후 다시 컴파일하여 실행되는 형태임. 즉 웹서버에 특수한 모듈을 설치해야 하므로 대부분의 웹호스팅 환경에서는 호환성 제로임.
- PHP도 C도 아닌 듣보잡 언어로 개발되었기 때문에 프레임워크에 버그가 있거나 수정해서 써야 할 경우 완전 난감함. 고친다 해도 맨날 컴파일해야 함. 이럴 바에야 자바나 닷넷을 쓰지 왜 PHP를 쓰나?
Slim
- Phalcon과 달리 순정 PHP로 만들어진 프레임워크인데, 빠른 건 인정하지만 기능이 정말 없음. 쓸모있는 기능이 많으면서도 빠르면 인정하겠는데, 이건 그냥 기능이 없어서 빠른 것임 ㅡ.ㅡ;;
결론: 프레임워크 개발이라는 것은 축구와 같아서, 지 혼자 아무리 개인기가 좋아도 팀플레이를 하지 못하면 슈퍼스타가 될 수 없습니다. 대부분의 서버 환경에서 오랫동안 정착되어 온 PHP 실행 방식을 존중하고, 오픈소스 개발자들의 참여를 이끌어내려는 노력이 없으면 아무리 속도가 빨라도 왕따당할 뿐... 그래도 상관없다면 회사 내부적으로 사용하는 것까지 말리지는 않겠지만, 절대 다수에게 외면받는 기술을 고집하는 회사는 전문인력을 구하기가 힘들어지겠죠?