Why Events Are A Bad Idea (for high-concurrency servers) 을 읽고
After reading article or paper 2012. 2. 3. 11:36
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf
이 paper를 읽으니, 재미가 있었다. 기억에 남는 것은 thread 방식의 문제를 compiler가 고치면 된다고 했다. dynamic stack growth, live state management, synchronization 등의 문제에 대해서 compiler의 도움을 얻는다면 성능이 잘 나올 수 것 같다고 작성했다.
------
내가 다니고 있는 회사의 웹 서버에서 사용하는 수많은 서버들의 web 서버들은 여전히 apache http가 가장 편하고 안정적이기 때문에 이를 사용하고 있다. 또한 nginx를 일부 사용하고 있다. was인 tomcat과 연동해서 사용할 때는 대부분 apache http 서버를 사용하고 있고, 주로 static 서버로 사용할 때는 nginx 를 사용하고 있다. 물론 nginx는 tomcat과 연동해서 쓰고 있다.
event-driven이든, fork/thread 방식이든 상관없이 이미 안전하고 운영하기 편리한 것으로 검증 받는 것으로 가는 것은 사람의 기본 심리인 것 같다.
2003년도에 thread나 event 방식의 개발 중에 어느 것이 더 좋은 것인지 학자들끼리 토론하는 것이 있었던 것 같다. 나는 그 때 머했나? 음. 당시에 다니던 전직 회사에서는 thread에 대한 부담감이 많이 있었다. 미들웨어 개발 당시에 thread의 남발로 인한 부작용이 심각했다. 너무 많은 thread들이 돌아다니면서 conditional 코드들이 생기고 코드는 점점 복잡해져 갔고, 무거워져 갔다. 성능이 느려지기 시작했다. 또한 코드 또한 복잡해졌다. 당시에 쓰레드를 남발하고 synchronized 블럭을 잘 써서 개발자라면 능력 있는 개발자로 여기는 행태도 있었다.
운영체제에서 쓰는 one thread에서 동작하는 polling 방식의 event 방식으로 구현하는 것은 어떨까 고민하고 구현하던 중이던 시점인 것 같다. event driven 구현 방식도 api를 제공이나 내부 구현의 복잡성, 속도에 대해서 한계가 존재했다.
구현 후 느낀 점은.. 어떻게 구현해도 만족시키지 못했던 것 같다. 각각 장/단점이 있었던 것 같다. 그 틀에서 어떻게 좀더 성능을 높인다는 것은 뼈를 깎는 고통인 것으로 기억한다. 나의 무식과 무지가 많이 드러나서 힘들었다. 웹 환경에서는 장비를 늘리고, scalabity를 지원하는 오픈소스를 사용하는 지금의 모습과는 많이 다른 것 같다.
'After reading article or paper' 카테고리의 다른 글
소프트웨어 장인에서 좋은 내용 발췌 (0) | 2019.04.11 |
---|---|
구글 TCP Fast Open paper (TFO)를 읽고 (1) | 2012.02.09 |
Bytecodes meet Combinators: invokedynamic on the JVM (0) | 2011.07.28 |
Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers 한글 번역 (0) | 2011.07.11 |
Virtual Machine Showdown: Stack Versus Registers (0) | 2011.01.22 |