NGINX作為 reverse proxy 效果非常的好。最近一場暴增的流量讓我們遇到了 502 Bad Gateway 的狀況。於是著手釐清為何會發生 502 Bad Gateway 、及如何解決？ 為何502 首先，先說明NGINX為何會丟出 502 Bad Gateway ？說穿了，就是NGINX認為後端的WEB主機都無法提供服務時…當下，NGINX的錯誤log也會留下以下記錄… no live upstreams while connecting to upstream NGINX是如何判斷後端的WEB主機無法提供服務呢？目前有提供以下兩種方式

如有使用 CodeIgniter Web Framework 的經驗，也許會遇到disallowed key characters錯誤的經驗。會出現這樣的訊息，是因為 CodeIgniter 會檢查client端送來的cookie名稱。 如果先不分析問題發生原因、想馬上解決，可下手調整判斷程式的正規表達式即可

最近有個系統的WEB環境升級，主要是將PHP升級到新版本。上線後，藉由網管系統的監測，發現到這些升級後的主機，他們的TCP連線數都會呈現上升、隔一段時間後下降，一直循環的狀況。 以往遇到這種狀況的經驗，都和connection pool這種架構有關。原以為是和資料庫有關，但比對該系統所使用的資料庫主機，TCP連線數卻沒有相同的趨勢。卻在memcache主機看到相同的TCP連線數趨勢。 找了專業的IT同事協助，他們在升級後的主機上執行以下指令，果然看到很多memcache的連線（ESTABLISHED） netstat -na|grep 11211

NGINX有提供以下專用的header，讓後端的程式可以藉由這些HTTP header和NGINX溝通。這些HTTP header都不會傳送到client端。 X-Accel-Expires: set the parameters of response caching; X-Accel-Redirect: performs an internal redirect to the specified URI; X-Accel-Limit-Rate: sets the rate limit for transmission of a response to a client; X-Accel-Buffering: enables or disables buffering of a response; X-Accel-Charset: sets the desired charset of a response. 導入NGINX後都沒什麼情境去使用這些專用header。最近發現到有個情境可使用到X-Accel-Expires。簡單說明如下…

在 前一篇文章 ，提到了如何藉由重新設定NGINX Cache Key，移除不會影響網頁內容的參數。這樣的作法雖然可以提升hit rate，但實務上仍會有所限制，這篇就稍做說明… 首先，我使用瀏覽器瀏覽以下網頁 https://test.com.tw/?para1=123&fbcld=XXXXXXXXXX&para2=456 Nginx Cache Key的組成是否如 前一篇文章 所說的呢？這疑問可以觀察NGINX的cache檔案內容得到答案。 以下節錄Cache檔案的部分內容，可見fbcld已經不見 KEY: test.com.tw/?para1=123&para2=456 HTTP/1.1 200 OK Date: Tue, 14 Jan 2020 07:27:02 GMT Server: Apache Cache-Control: max-age=0 Expires: Tue, 14 Jan 2020 07:27:02 GMT Vary: Accept-Encoding,User-Agent Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 剛提到實務上仍會有所限制，WHY？

對一個大流量的網站，cache可說是無所不在。由訪客端的browser cache、傳輸過程中的proxy cache，到程式端的nosql等各種cache…對於cache機制，最重要的指標莫過於hit rate。這數字越高，表示該cache機制的效果越佳。 最近在處理一個爬蟲的過程中，注意到一個狀況，當行銷部門買Google廣告、或有網友將網址分享於FB時，Google或Facebook都會在網址後面加上他們自己獨有GET參數。 由於我們有採用nginx作為 reverse proxy ，主要用以降低後端的web server的loading（還有其他用途），上述的狀況會使得hit rate不好。

最近有個splunk需求，程式所產生的log中想埋入JSON格式的內容。後續需要由splunk解析該JSON內的資訊、以分析、或相關警示的處理。 首先說明此次splunk中的log格式，舉三筆示意的log如下

有人遇到一個問題，說他的PHP程式連資料庫（MSSQL 2008R2）查詢資料時會因為 Changed database context to 'DATABASE-NAME' 的錯誤而無法執行… "Changed database context to XXXX"這訊息的含意是…登入資料庫所用的帳號，做了切換資料庫的動作。如果登入資料庫的帳號有設定預設使用的資料庫，而程式運作中切換了資料庫。舉例，登入資料庫的帳號預設的資料庫為 DB-A，但程式登入資料庫後切換到 DB-B時，此時資料庫就會回傳這訊息。 雖然這樣的訊息不是『錯誤』，只能算是『資訊』…以往總覺得納悶這為何是錯誤？但，在這次追查問題中使用 SQL Server Profiler 時，發現到真的歸類於error... 總之，個人認為他的程式不可能是因為這的訊息樣而無法運作。且，他PHP程式所在的主機，都已經將錯誤等級設定為超過11才顯示，如下…

cookie 有人遇到一個PHP問題，聽完他的描述後直覺認為是和該系統操作cookie的方式有關，懷疑該系統產生的的Cookie大小超過規範的限制。原以為瀏覽器會呈現Cookie容量過大的錯誤，但是打開瀏覽器的console卻看不到任何錯誤。當時，還誤以為是不是PHP在server端做了處理？ 花了冤枉時間後，才知道是因為Firefox不會呈現Cookie超過限制的錯誤，但是Chrome會……昏倒…… 下面範例，是使用PHP產生一個超過RFC規範大小的cookie $value = str_pad("", 5000, "TEST-"); setcookie("TestCookie", $value); 測試環境，分別用以下版本瀏覽器執行上述程式進行測試，並說明結果

調整行動版版型後，經由自然搜尋（Organic）的行動裝置流量就馬上提升 以往瀏覽這blog行動版頁面時，文章中的圖會有破版的狀況，很難看…雖然去年曾經嘗試改過一次這blog的行動版版型，卻發現毫無效果。 長期觀察這個blog的流量都是以電腦裝置、且都是上班時段為主。讓我以為是因為這blog的內容特性才有如此的流量趨勢。既然以電腦裝置為主，就沒認真找為何調整了行動版型卻沒效果的答案。 最近處理完公司網站由http移轉到https後相關SEO事項後，依照慣例也更新之前對公司內部所做的SEO簡報。當中有份google重要調整的時間表也一併更新。 今年google就有兩項更新。這兩項和2015、2016年的更新有關，因此一併節錄如下…

HTTP 301 vs HTTP 302 網頁轉址的HTTP response status codes有兩種，分別為301與302。使用瀏覽器瀏覽網頁時如果遇到這兩種轉址，對人來講沒有差別。但對於搜尋引擎、SEO、瀏覽器就有重大的差異。處理網站遷移時務必要做好。 HTTP 301、302 在 RFC 中的定義如下。不過，對於SEO比較重要的是301 Moved Permanently 301 Moved Permanently The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. 302 Found The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. 為何301 Moved Permanently比較重要？

為了提供更好的資安、及SEO，網站由http改成了https。技術面處理好上線後，卻遇到一個狀況-網頁上所呈現的Facebook讚、分享等的次數，居然全部歸零。在這社群的時代，這樣的結果不是大家所要的。 要讓Facebook讚的數字回來，說穿了不難。就是要讓網頁中og:url的值，填入原本的網址即可 以我們為例做說明，我們的網頁中原本就埋有 Open Graph protocol 中所定義的metadata-og:url。只是，隨者網站由http改成https後，og:url的內容自然就跟者改變了，調整前、後的內容如下 <!-- 調整前，原本使用http時的內容--> <meta property="og:url" content="http://example.com/0010777884"/> <!-- 調整後，改為https時的內容--> <meta property="og:url" content="https://example.com/0010777884"/> 當網頁中有埋 Open Graph protocol 的og:url時，Facebook就是以og:url中的網址為主，而不會採用瀏覽時的網址。這樣的處理模式，和SEO、搜尋引擎中的 標準網址 （canonical）有異曲同工之妙～

Word Cloud Generator 今年的關鍵字點擊文字雲分析 去年因為簡報的需要，整理了 中文文字雲產生器 的作法。當時，只要能做出圖放在簡報上即可。這次的文字雲應用，想將製作一個文字雲/關鍵字放在網頁上讓大家能自己看、並且可點擊該關鍵字帶入另一個頁面呈現資訊。 找了一下作法…最後在 D3.js Examples 找到了 Word Cloud的範例 。該範例使用 d3-cloud 。就以此又做了個線上文字雲… 這次的範例，資料來依舊來自 Google Search Console 。取和這blog有關的關鍵字、並依據點擊數作為文字雲的文字大小。 如以往…每個關鍵字熱門程度依舊差異很大，所以…仍要做些處理，降低各個關鍵字間的差異。不然，點擊數太大的關鍵字會因為字型太大而無法呈現～ 以下就是這blog於google上點擊數排名前100的關鍵字。當用滑鼠點擊文字雲上的關鍵字，則會將關鍵字帶入google做搜尋～

最近使用 redis 的 Lists 資料結構做些東西，採用 Reliable queue 這Pattern。 我開發環境的語言是PHP，連接 redis 的套件，採用 phpredis/phpredis: A PHP extension for Redis 這套。 雛形很快的就開發好了，沒想到，一測試就遇到以下的錯誤…程式無法達到預期-持續的連接於redis接收 Lists 內的資料。 RedisException: read error on connection in XXXXX.php 由於我是使用 brpoplpush 這指令操作，不經懷疑blocking的操作方式會受redis.conf中的timeout參數的影響。當初，考量redis的運作方式，因此刻意調整此參數避免redis被單一client卡住。畢竟設定檔中的timeout參數是這樣說明的…

Google Analytics (分析) 個人認證考試（GAIQ） 使用 Google Analytics （後面簡稱GA）也好幾年了，當初會使用GA是為了瞭解blog流量、及每次調整SEO之後的效果檢視之用。到後來則是應用在公司的網站上，並整合公司內部的成效追蹤系統，以提供網站各種績效的深入分析。 這中間曾經卡關過。因為一開始使用GA，是由技術的角度出發，只是單純的看流量。在這個角度看GA，和一般的流量分析軟體差異並不明顯，無法體會GA真正的用途。 個人覺得GA這工具是橫跨了所謂的IT、及行銷領域。如果只懂其中一個領域將無法完整發揮GA。當時的我，就是這樣……

以我blog關鍵字曝光數所做的文字雲 最近在整理一份關於google關鍵字簡報，為了讓大家能簡單的體會各個關鍵字的份量、出現次數，使用文字雲(tag cloud、word cloud)以視覺化方式表現。最後找到 wordcloud2.js - tag cloud/Wordl 。 在 wordcloud2.js - tag cloud/Wordl 的demo頁面上我們可以直接貼上權重(weight)與字串。前者就是關鍵字出現的次數，後者就是我blog於google的關鍵字。 一開始使用時，發現到有些關鍵字沒有出現。以為這套對於中文的支援是否不佳？花了些時間才發現到，是因為我手上資料所造成。

先前介紹使用GTM觀察訪客進入網站後，是否有閱讀完文章才離開。分別採用過兩種方式，第一次使用timer配合trigger方式處理，藉此得到訪客於文章的停留時間，作為評斷是否有看文章的依據。第二次則是使用 Scroll Depth 這個Google Analytics plugin。 考量timer配合trigger方式產生太多的event，以及影響了跳出率，才使用此法- GTM搭配Scroll Depth-Google Analytics plugin於GA中瞭解訪客是否閱讀完文章才離開 。 這兩種方式對於GA的相關指標會有何種影響、及變化，做個簡單說明…

使用GTM搭配Scroll Depth-Google Analytics plugin，提供更符合狀況的跳出率 這個blog的流量來源以organic search為主，高達八成。另外，訪客只有閱讀一篇文章的比例也一直蠻高的。雖然也曾經嘗試在文章中儘量帶出blog內的相關文章，但觀察自己在GA中所設定的目標數字一直沒什麼改變。這表示，跳出率自然也居高不下… :P 雖然訪客多數只閱讀進入的文章後就離開，但換個角度，很想瞭解訪客是否真的有看完文章才離開？還是進入後覺得文章內容和預期不同而馬上離開（如同觀察跳出率的意義）？ 在 GTM搭配Scroll Depth-Google Analytics plugin瞭解訪客是否有閱讀文章 文章中，只有提到如何藉由Scroll Depth-Google Analytics plugin產生的閱讀百分比，瞭解訪客閱讀文章的狀況。本篇則是要說明如何更進一步的應用以解決上述的疑惑。 說穿了，很簡單。就是利用Scroll Depth-Google Analytics plugin會隨者訪客觀看頁面的位置傳出25%、50%、75%、100%四種event，再搭配GTM整合Google Analytics的事件(event)。 設定前，要先瞭解Google Analytics的事件(event)的背景知識。GA有以下兩種event 互動事件（Interaction Events） 非互動事件（ Non-Interaction Events ）

最近測試新版PHP時，有人提到他的程式在新的環境執行時無法取得自訂的header。可是，在舊環境執行卻可正常取得該header。 程式是採用$_SERVER取得header。原以為是新版PHP的問題，但查了PHP的版本變更記錄( PHP: Appendices - Manual )卻沒有相關的說明。於是，懷疑和apache有關，傳給PHP的資料就有問題。 此次，除了PHP升級外，Apache也一併升級到2.4。在官方說明- Overview of new features in Apache HTTP Server 2.4 - Apache HTTP Server Version 2. 中提到，Apache 2.4為了增加安全做了以下調整… Translation of headers to environment variables is more strict than before to mitigate some possible cross-site-scripting attacks via header injection. Headers containing invalid characters (including underscores) are now silently dropped. Environment Variables in Apache has some pointers on how to work around broken legacy clients which require such headers. (This affects all modules which use these environment variables.) 依據上述資訊，重新查了有問題的程式。原來，程式中所自訂的header名稱中包含了『_』（底線、underscores）。觸發了Apache 2.4上述的安全加強，PHP就無法在$_SERVER取得header名稱中有底線『_』的header。當然，自訂的header名稱中沒有使用底線『_』的header，是可以正常取得的。 以下，簡單說明問題發生的原因、與相關的狀況，與處理方式…

最近想將使用CodeIgniter這套php framework的系統改用 PHP: FastCGI Process Manager (FPM) 運行。 由於採用了CodeIgnite官方 CodeIgniter URLs : CodeIgniter User Guide 的作法，於網址中移除index.php。因此，當設定好 PHP-FPM 後，尚須處理移除index.php這段設定。 另外，也由於apache的版本演進，不同版本配合 PHP-FPM 的設定方式也有所不同，找資料過程中看過很多種設定。因此把最後採用的設定方式做個紀錄。