^^; 저도 자바를 좋아하고, php옹호론자는아닙니다만, 용도의 문제겠죠?

몇가지 궁금한것은 , 1. 적재,초기화,실행 -> 스크립트 언어의 특성을 말하시는건가요? 2. 설계가 복잡하다는것은 언어비종속적 사양에 관한 말씀이신가요? 아님 php를 고려하여 설계하려니 복잡하다는 이야기이신가요? 3. 성능저하문제는 오래된 이슈인듯해요. 보통 이야기가나오면 생산성 및 compile module(JNI같은)이야기를 같이 언급하죠^^;

APM이냐, J2EE냐? 말씀하시니 생각나는데, PHP 기반으로 사업하던 후배에게 서비스 부하는 어쩌냐 하고 물어보니까… '형… 그건 어차피 값싼 서버 주욱 늘리면 되요' 라고 답변하더군요. 장단점이 있기도 하고, 설계하기 나름이라는 생각도 들고…

아시모프님 질문 보니, 이거 토론방이라도 따로 만들거나 블로그에서 토론해야 할까요? 재밌을 듯... (뒤에서 애인한테 문자왔냐, 왜 이리 실실 쪼개냐고 하네요)

제가 php 를 버리지 못한 계기는 외주인력 써먹기 좋아서 인듯

1. 스크립트 언어라고 다 PHP 같지는 않죠. JSP나 ASP 같은 Serverside script page 방식의 기술에서 그런 방식을 사용합니다.

2. 객체지향적으로 SRP 원칙에 맞춰 개발을 하고 (특히 PHP5에 추가된 인터페이스를 사용한다면) 웹 프레임워크나 DB 추상화 기술을 사용한다면 한번의 Request에 수십에서 100여개의 php script 파일을 메모리에 적재해야하는 경우도 있는데 매번 이런 작업을 하는 것은 비록 중간코드 캐쉬를 쓴다고 해도 엄청난 부하가 됩니다. 특히 thread safe하지 않기 때문에 메모리 사용량도 만만하지 않죠.

3. 물론 성능 저하 문제를 해결할 수 있는 방법은 많이 있습니다. Java나 .NET과 바인딩하는 것도 한가지 방법이고요. 하지만 그렇게 된다면 더 이상 PHP를 쓴다고 하기 힘들어지죠. ^^

K-Dog : 예 맞습니다. 하지만 그런 인력의 평균적인 수준 문제를 봤을 때 차라리 그런 인력을 써야만 하는 업계를 벗어나는 것이 더 나을 듯 하더군요. 그러다 보니 이민을 생각하게 되기도...ㅠ.ㅠ

써니 : 뭐. 비교하는 건 의미 없을 수도 있죠. PHP라고 쓸모 없다고 할 수는 없으니까요. 어쩌면 제가 PHP에 한계를 느낀 것은 제가 다른 영역으로 이동했기 때문일 수도 있습니다. 당시에 엄청난 실패를 맛 보았으니까요.

말씀하신대로 뭔가 새로운 시도를 하는 계기의 상당수는 실패 때문인거 같아요. 저도 CVS만 내리 쓰다 요즘 subversion을 도입하려는게 실패를 겪어서...

써니 : 이왕 바꾸시는 거 Mercurial 로 해보세요. ㅎㅎ subversion은 계속 이클립스 plugin이 불안하고 CVS보다 빠르기는 하지만 여전히 느리고...

결론은 1,2,3은 PHP만의 문제가 아니군요^^;

위의 여러 이슈(thread safe , 메모리등등)들이 문제가 될때에는 안쓰는게 정답인듯해요. 하지만 제가 개발한 php 프로젝트가 다행히(?) 소규모라 그런지는 몰라도 아직 위의것들이 이슈가된적은 없었어요.

아시모프 : 사실 좀 대충 얘기해서 그렇지 PHP가 좀 특이 합니다. 여기서 토론하기에는 너무 한정적이네요. ^^

예 단순한 사이트에는 효과적인 좋은 기술입니다.

공감합니다. 가벼운 사이트 개발하는데 EJB라도 들고 나오면 정말 길에다 돈 버리는 일이죠.

Mercurial 보다는 Git가 더 좋은거 같은데 (개인적인 취향문제일수도.)

예전 flickr 의 scale-out 관련 자료에서는 request 기반 생명주기가 손쉬운 scale-out 을 가능케 하였다고 했습니다.. 그 관점에서는 "php라서 쉽게 원하는 성능을 얻었다"고 말할 수 있을 것 같네요.

저도 복잡한 business-logic 이라면 java를 선호하겠지만, 짧고 많은 request 라면 php가 더 좋을 수도 있지 않을까요. 흐음, '단순한 사이트' 가 이런 사이트까지 말씀하시는 것이겠죠? (단순한 사이트라는 표현이 너무 모호하네요 ^^;)

자바 리플렉션은 나름 재밌음.

마소에서 연재된 예전 기사를 찾아보면, 딜리셔스 개발자도 PHP로 개발하고 운영하면서 하등의 문제가 없었다는 얘기가 나오더군요.

페이스북도 PHP인걸요? :-)

php를 버리시고 무얼쓰시나효? 뭐하나 재대로 하능게 없어서 한번 배워보려구요 ㅋ (겉핧기 좋아합니다 —ㅅ—;) [ 글보러가기 ]

아까 쓸까 말까 했는데 디토님도 등장하셨으니… 지금까지 본 PHP 코드 중에 MetaBBS가 가장 아름답고 감동적이었습니다.^^);;

직접 서비스를 하는 경우에는 값싼 서버를 탄력적으로 운영하는 것이 가능해서 PHP의 한계를 비교적 쉽게 극복할 수 있지만 일반 기업에서는 서버를 보강하는 일이 예산 등의 일로 쉽지 않기 때문에 제한된 박스로 최대의 성능을 이끌어내야 하는 문제가 있습니다. 결국 위에서도 말했지만 제 사정이 PHP로 적당하지 않은 곳으로 옮겨갔다고 보시면 되겠네요.

맹수 : Git는 아직 이클립스 플러긴이 초기라서...-_-

오리대마왕 : 예 규모가 아니라 비지니스로직의 복잡성을 두고 말한 것입니다. 게시판 수준의 서로 독립적인 모듈들로 구성된 서비스라면 그 모듈 숫자가 100개든 1000개든 단순한 사이트라고 할 수 있는 거죠. 그런데 짧게 쓰려니 자꾸 오해를 일으킬만한 소지를 남기게 되네요. ^^

써니 저도 5년 넘게 PHP로 별별짓하면서 잘 벌어 먹었습니다. 아마 저희가 PHP로 작업한 사이트 말씀 드리면 그런 곳도 PHP 쓰냐고 물어보실 거에요. ^^

상용 환경에서도 코드 캐쉬 잘 사용하고 있는데... 적재 탓은 좀...

세라비 : 적재만 탓하는 것은 아니죠. 코드 캐쉬를 쓴다고 해도 적재의 절반(컴파일 부분)만 해결되는 것이고요. 또 서버 환경에 따라서 불안한 경우가 많아요.