Home » Computer » Archive by category "Programming" (Page 86)

Web Developer

會裝 上的 ,其實是因為 深情推薦,裝了以後也不知道幹嘛 XD

直到這陣子寫 HTML code 寫到受不了,決定來看 有什麼功能可以用,才發現這個 Extension 是個神兵利器 XD

第一個,看某個物件的屬性。

在畫面上按下 Ctrl-Shift-F (或是用 Toolbar 上的 Information,選 Display Element Information) 之後,移動游標,在左上角就會出現這個區塊的各種屬性,像是字體資料 (逛網頁時看到喜歡的字型不用再翻 HTML 與 CSS)、物件的巢狀架構 (想要變更 CSS 時超方便,在找 CSS 靈異現象時也超方便):

Web Developer

第二個,看 Javascript 產生出來的 HTML code。

有時候會透過 Javascript 產生一些 code,但產生出來的 HTML 在最簡單的 View Source (即 Ctrl-U 所跳出來的視窗) 裡面看不到。而 Web Developer 提供了 View Generated Source 的功能:

Web Developer (View Generated Source)

第三個,看網站的結構性。

用 View Topographic Information (在 Information 下) 可以看出來網站的結構性,舉布丁大長輩的網站當範例,上面這張是原來的頁面,而下面這張是點選 View Topographic Information 後的頁面。

下面那張裡,預設是黑色,每多一層就變白一點。 算是比較乾淨的網頁,如果你拿 blog.yam.com 的首頁抓出來看,你會看到在奇怪的地方多出一堆奇怪的白色框框 XD:

Web Developer (Original)

Web Developer (View Topographic Information)

當然,還有很多很好用的功能,有空的時候可以隨便抓兩個網頁對照看看,其實會利用 學到不少東西 (以及對於網頁設計的感覺)。

用 GPU 跑 FFT

遲早會有人把腦筋動到 GPU 強大的運算能力上 :p

這次是利用 的 GPU 弄出一個數學函示庫 ,利用 GPU 計算 FFT 的基本運算加速:High performance FFT on GPUs

在 Benchmark 中,透過 GPU 加速可以使得 FFT 整體的速度大約是純用 CPU 計算的四倍,但顯示卡的價錢卻只有 CPU 的 1/3。換句話說,把這類運算丟給 GPU 做,讓 CPU 計算其他的事情。

不過還是有些限制:

  • 只有 32-bits (single-precision) float point 可以用,這是 GPU 所造成的限制,如果以後有 GPU 支援 64-bits 才有辦法支援上去。
  • 只能跑 1-D FFT。
  • 在科學計算上面還要考慮到「正確性」的問題:GPU 計算時可能會有誤差,在畫圖的時候差一些沒關係,但科學計算的時候是不被允許的...

所以這個 Math Library 實際能應用的領域其實就小很多了...

DreamHost 的 CPU 限制

剛剛看到 The Truth About Overselling! 這篇,突然想起有些積了很久的東西要寫 :p

主要有兩個要注意的:

  1. 我們先計算出來:一天有 1440 minutes,如果有兩顆 CPU 就有 2880 CPU minutes,60 CPU mins 佔了 2%+,換句話說,一台雙 CPU 的機器只夠給五十個用滿 2%+ 的客戶用。
  2. 提供了兩種模式跑 :CGI mode (可以跑 PHP4 或 PHP5) 或 mod_php4,前者是預設值,跑 PHP4。

在 CGI mode 下會以 suexec 轉到 user 的身份跑,當然比較安全:所有的檔案權限都可以設定為 600,但是比較慢:因為要先 fork()execl() 到 suexec,再 execl() 到 php.cgi。

而 mod_php4 當然就快多了,少了 fork() + execl() + execl(),但 就是以 apache 的身份在跑,CPU resource 不會掛在 user 帳上,只要不要吃的太兇,其實都不太管。這時 安全上的問題則是透過 裡設定 safe_mode,在這個模式下無法透過 fopen() 開啟目錄外的檔案或 symbolic link,以及種種限制。

回過頭來說 Blog Software 以及我對於 開發者心態不以為然。

在發展時就都有考慮到 safe_mode 的問題,所以在 上可以直接使用 mod_php4。另外一方面, 在發展新功能的同時,也在控制 CPU resource 與 resource 的消耗量。在 還沒搬家前,就是以這種方式在跑。(在更早之前我也跑過 php.cgi 的模式,後來收到通知 CPU 超量的信,就改到 mod_php4,一直到四月底搬家)

反過來看當年的 pLog (現在叫 ),這是 2005/06 時裝好 pLog 1.0 後覺得很慢,拿出工具追蹤所發現的紀錄:

03:29 <@Ben_> 救命喔...讀取首頁就要用到 272 個 php 檔案...

到了 2006/02/19,DreamHost Sucks! 我的惡夢! 這篇最後面提到:

PS 2:我的 CPU Minuts 是多少? 195 Minutes 而已啦!他們規定只能用 60 Minutes。

用了整台主機 6%+ 的 CPU resource 還可以大喊人家爛,而且是自己在維護的 ... *無言*

為什麼要使用 mod_rewrite?

來講什麼是 mod_rewrite (或是其他類似的東西),以 為例,RSS feed 的輸出大致上會長這樣:

http://group.nctu.edu.tw/rss10/darkkiller

我希望把這類的連線要求都交給 rss10.php 處理,變成這樣:

http://group.nctu.edu.tw/rss10.php?g=darkkiller

這就是 mod_rewrite 要做的事情。

那麼用 mod_rewrite 有什麼好處?我可以想到這幾點:

  • 服務的穩定性:對於發展中的平台而言,mod_rewrite 提供了彈性,使得底層的改變 (譬如 rss10.php 變成 rss10-2.php) 不會影響到上層的 URL,對於使用者而言不會有感覺。
  • SEO:Search Engine 會比較偏好沒有 ?& 的 URL。

像無名的 RSS 與文章 (以彎彎的 Blog 為例) 就做的不太好:

  • http://www.wretch.cc/blog/cwwany&rss20=1
  • http://www.wretch.cc/blog/cwwany&article_id=5576574

比較好的作法可能是改成這樣:

  • http://www.wretch.cc/blog/cwwany/rss20
  • http://www.wretch.cc/blog/cwwany/5576574

甚至改成 feed.wretch.cc,一開始先用 VirtualHost 跑在同一台上,以後如果發現 RSS 愈來愈吃重,需要以獨立的機器分出來就更方便了。

純打屁聊天...

最近寫了一些 Javascript 有關的東西,用 找了一堆資料發現都在 裡,但是又不知道這個網站的品質到底好不好,於是就跑去問 ...

14:31 <@gslin> hlb_: 怎樣?用 找了一堆資料發現都在這邊找到 XD
14:33 <@hlb_> gslin: 怎樣喔... 我兩年前就跟你提過這個網站了 :p
14:33 <@gslin> @_@
14:33 * hlb_ 逃

平常都沒在聽大師教誨... (到牆角懺悔)

Cache 的技巧?

Your Message on Gaxed.com 看到一個 Cache 技巧:

For Gaxed I’m using some heavy caching to prevent it from going down to easily. The basic algorithm is: when a picture is viewed more than 50 times, it’s moving into the cache folder as a static JPG (the page URL will stay the same of course, acting as a permalink). This way, I don’t need to poll the PHP, the database, and I also don’t need to recreate the image using PHP image/ GD.

問題是 counting 要怎麼做比較好?用 直接做似乎不錯?反正掉了再去抓就好。

FreeBSD 下的 PHP

的 PHP 一直都有一個很嚴重的問題:沒有辦法生出同時支援 與 apache module 的 PHP 版本。

這個問題終於在前幾天解決了:

20060506:
AFFECTS: users of PHP
AUTHOR: ale@FreeBSD.org

The old PHP slave ports (phpN-cli, phpN-cgi and mod_phpN) were removed in favour of unified PHP ports that allow building any combination of PHP SAPIs (cli, cgi and apache module). The PHP CGI binary was renamed to php-cgi, so you should update the path in your script. To simplify the update process, *only* for this release a 'php' compatibility symlink to php-cgi will be created if you don't select the CLI SAPI. Before the upgrade you *should* run 'make config' in lang/php4 or lang/php5 to configure the SAPIs you want to install. As a consequence the default binary packages include the CLI and the FastCGI SAPIs.

先用 make config 重新設定,再用 portupgrade -f 更新,這樣應該沒什麼大問題...。

Archives