[閒聊] 效率最高的動態網頁處理法

[erspicu (.)]

想討論的是比較極端的狀況,意思是說特例.


前面有人說拿組語寫網頁,我還真的看過....

大概是cgi那種時代,除了用perl和一些script撰寫cgi script外,

也可以直接用c寫,c裡面可以崁入asm,更甚至你直接用asm寫執行檔,

給cgi去跑也是ok.... 就看過有教學教你如何在win32上寫asm給cgi印hello word,

然後處理post跟get讀取.

不過cgi這種運作概念就有它的天生缺陷,比較後期的技術叫fastcgi,

其實fastcgi我個人是很看好,只是跟後來出的網頁技術相比,大時代潮流和硬體性能提升,

大家就比較不在意了和鑽這種牛角尖了... 我覺得fastcgi還滿強的,

是那種執行第一次就掛載到記憶體(底下印象有誤請修正一下)

永存的東西,所以IO時間就是記憶體存取的時間,印象中大概架構是

//never stop
while(true)
{
  wait for request
  .
  .
  .
}


如果有一個變數叫counter是廣域變數,初始為0,啟動網頁++一次,

傳統cgi每次執行網頁process重建 , print出來都永遠是 1

而fastcgi你執行幾次, counter出來就一直累積下去.....

如果這種東西改用asm,應該更可怕.....

重覆啟動直譯器讀SCRIPT時間省了

或是VM處理bytecode時間也省了

反正就啟動 程式就掛住

我相信應該有不少特殊網站是fastcgi+c的技術,不過用組語的就不太清楚了...

只是據說組語寫得爛,效率可能會比C加優化出來效果差就是.

其實如果要再極端一點,我覺得直接把WEB SERVICE跟動態網頁直接綁到

http server程式核心的部分去(當然如此一來變成要自撰夠穩固的http server了...),

少掉幾層中介,應該又更快了.


--
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 編輯: erspicu         來自: 61.70.105.149        (06/29 12:09)
※ 編輯: erspicu         來自: 61.70.105.149        (06/29 12:10)
推 CRPKT:這也要看你考慮的目標是哪種類型的動態網頁
→ CRPKT:因為有時候瓶頸不是在 dhtml 產生本身
現在我猜似乎都數都是卡在DB這環就是
不過我覺得也別太小看建立動態網頁本身的邏輯環節
FB有聽過是PHP轉成C後編譯的.轉換器叫hiphop
※ 編輯: erspicu         來自: 61.70.105.149        (06/29 14:07)
→ aaroms:FB 現在改HHVM了 直接是 PHP -> Bytecode 在特製 VM 裡面跑
不太懂 直接搞出實際硬體的opcode給實體cpu跑不是更好嗎? 多了一層
可能有特殊原因吧?
※ 編輯: erspicu         來自: 61.70.105.149        (06/29 14:59)
推 CRPKT:看 1.網站類別 2.測量標的 3.環境與條件 瓶頸會不太一樣
推 CRPKT:例如快是指 server 回 request 快還是 client 整頁 load 完
→ CRPKT:網站硬體資源如何, 預計撐每秒多少 request, 多少在線 user
推 leoace:用C的話例如使用Mongoose, nginx, lighttpd將HTTP訊息
→ leoace:直接寫在code裡面，適用在embedded system。
→ leoace:另外使用nginx寫額外的模組在加載到核心，也有相同的效果
→ leoace:比較有彈性是可使用config或xml檔來設定req/rep的URL。
→ leoace:我目前就是採這種做法，將一些處理POST GET等程序寫成Class
→ leoace:寫程式的時候就使用這些不同服務的Class產生不同的模組
→ leoace:有新的需求時，再新增新的Class, 缺點就是所有的Rep/Req都
→ leoace:不能動態產生，只能重新編譯..從C/C++的角度切入Web開發
推 ClareQ:動態的需求愈高，就愈需要使用client的資源來執行
也得看哪種類型的動態需求就是
※ 編輯: erspicu         來自: 61.70.105.149        (06/30 01:39)
推 xvid:java applet?
→ gname:memory leak:...
推 godgunman:http://goo.gl/ZGgYZ Facebook 的 HipHop VM for PHP