[Pixmicat!]突發奇想 Cecil ID:0EYr5GWY 11/06/19(日)12:46 No.3093
評分：0, 年：0, 月：0, 週：0, 日：0, [+1 / -1] 最後更新：2019-12-04 07:48:17
如果裡祭用這樣的構想來架,以最便宜的方式分流
有沒有可能?
雖然SCRIBE 說過要用家每次上傳圖片到2台主機要花上傳圖片的人2倍時間, 不過實際上是否可行. 想問一下意見
構想1. 可以把PHP 運算分流
有沒有可能?
雖然SCRIBE 說過要用家每次上傳圖片到2台主機要花上傳圖片的人2倍時間, 不過實際上是否可行. 想問一下意見
構想1. 可以把PHP 運算分流
無標題 Cecil ID:0EYr5GWY 11/06/19(日)12:47 No.3094
構想2. 這個改起來比較簡單
不過所以PHP 運算都在一台主機
不過所以PHP 運算都在一台主機
無標題 無名氏 ID:sr2PqlGY 11/06/20(一)22:46 No.3095
共享SQL+分散是應該OK...
存取同一個SQL..然後後面加參數去做控制
不過要快到不如圖片檔用FTP的方式存檔(PIX>FTP)
FTP端要鏡像多少根本無所謂
最後RAND取出那台電腦都會有檔案
不過資料量有大到需要這樣@@?
存取同一個SQL..然後後面加參數去做控制
不過要快到不如圖片檔用FTP的方式存檔(PIX>FTP)
FTP端要鏡像多少根本無所謂
最後RAND取出那台電腦都會有檔案
不過資料量有大到需要這樣@@?
無標題 無名氏 ID:5RQGgMEI 11/06/21(二)00:55 No.3096
直接用隨機上傳到不同伺服器不就好了
無標題 Cecil ID:JESEisi6 11/06/22(三)15:03 No.3099
構想3: CPU 分流
由於現在有幾位版主都在家中架設主機
而外國的便宜空間商都限制CPU使用.
不知道這個構想行不行?
由於現在有幾位版主都在家中架設主機
而外國的便宜空間商都限制CPU使用.
不知道這個構想行不行?
無名氏: 構想行不行是要看誰來開發吧... 即使我說行, 你開發的出來嗎? (1d2J9p7. 11/06/22 18:52)
無名氏: 同意.. 而且pixmicat還沒有這麼大的用戶吧 (eRdYKTt. 11/06/23 01:10)
無名氏: 應該沒必要做什麼分流，找個好一點的伺服器比較實在 (eRdYKTt. 11/06/23 01:11)
f2: 之所以會要這麼做，是因為只能用免費空間。如果把裡版架在自己家，大概沒幾天就被抓去當業績了 (tHB3I6q2 11/06/30 11:39)
f2: 而祭典裡的流量一個月大概1T左右，放上免費空間一天就爆了，所以非搞些不一樣的做法 (tHB3I6q2 11/06/30 11:40)
f2: 事實上這種流量大部分付費空間也是一天就爆.... (tHB3I6q2 11/06/30 11:41)
無名氏: 同意.. 而且pixmicat還沒有這麼大的用戶吧 (eRdYKTt. 11/06/23 01:10)
無名氏: 應該沒必要做什麼分流，找個好一點的伺服器比較實在 (eRdYKTt. 11/06/23 01:11)
f2: 之所以會要這麼做，是因為只能用免費空間。如果把裡版架在自己家，大概沒幾天就被抓去當業績了 (tHB3I6q2 11/06/30 11:39)
f2: 而祭典裡的流量一個月大概1T左右，放上免費空間一天就爆了，所以非搞些不一樣的做法 (tHB3I6q2 11/06/30 11:40)
f2: 事實上這種流量大部分付費空間也是一天就爆.... (tHB3I6q2 11/06/30 11:41)
無標題 scribe<span class="nor">◆ScRBg4WCkk</span> ID:Ky1AHTfU 11/06/28(二)22:35 No.3101
1.
這感覺太複雜了。
有點像是兩個獨立的網站，共用資料。一方面要記錄圖檔在哪個site，沒有通透性。
而且萬一有一個掛了整個機制就毀了，不推薦。
2.
直接使用CDN吧，圖檔流量分散交給專業的來作就對了。
或者你自己架幾台Replication sites，定期與Primary site作resync的動作，
確保每一台上面的圖檔都是相同的。而Primary site就跟一般使用無異。
使用者的圖檔要求則利用Round-robin DNS的方式隨便挑一台。
只是如果有站台掛點了就比較麻煩(特別是Primary site)，可能得加上Load balancer的概念。
參見伺服器負載平衡的做法吧。
3.
比1.單純，就是要分散CPU time。
不過分出去的生成預覽圖所用的CPU不知道有沒有整個版面的30%。
不知道你去呼叫http://quickthumbnail.com/再把預覽圖抓回來怎麼樣？
不過你得先等這個網站抓完你的圖才能產生預覽圖，所以會有delay。
給使用者的感覺可能會比較久一點。
這感覺太複雜了。
有點像是兩個獨立的網站，共用資料。一方面要記錄圖檔在哪個site，沒有通透性。
而且萬一有一個掛了整個機制就毀了，不推薦。
2.
直接使用CDN吧，圖檔流量分散交給專業的來作就對了。
或者你自己架幾台Replication sites，定期與Primary site作resync的動作，
確保每一台上面的圖檔都是相同的。而Primary site就跟一般使用無異。
使用者的圖檔要求則利用Round-robin DNS的方式隨便挑一台。
只是如果有站台掛點了就比較麻煩(特別是Primary site)，可能得加上Load balancer的概念。
參見伺服器負載平衡的做法吧。
3.
比1.單純，就是要分散CPU time。
不過分出去的生成預覽圖所用的CPU不知道有沒有整個版面的30%。
不知道你去呼叫http://quickthumbnail.com/再把預覽圖抓回來怎麼樣？
不過你得先等這個網站抓完你的圖才能產生預覽圖，所以會有delay。
給使用者的感覺可能會比較久一點。
無標題 f2 ID:tHB3I6q2 11/06/30(四)11:36 No.3103
我當時的做法是一張圖片分往後面三台圖片主機，顯示時隨機產生url，所以只要主機不一起掛就好。缺點是cpu分不開，而這才是免費空間最容易被鎖的地方
分散製作縮圖事實上cpu用量減少的相當有限
構想一我覺得比較難搞的是共用db的部分，畢竟免費空間才不會讓你做這種比較進階的功能，不然他們還混什麼？而用php處理的話，處理同步產生的Request數量可能不會佔到太多便宜。
分散製作縮圖事實上cpu用量減少的相當有限
構想一我覺得比較難搞的是共用db的部分，畢竟免費空間才不會讓你做這種比較進階的功能，不然他們還混什麼？而用php處理的話，處理同步產生的Request數量可能不會佔到太多便宜。
◆ScRBg4WCkk: 如果限定得用免空作分流的話，要多繞好幾圈才能達成。我的回應是沒有考慮到只用免空的方式 (MCV.Ojpo 11/06/30 12:53)
事實上，我覺得pixmicat會吃這麼大cpu是遠超出預期之外，php只是生成靜態網頁30頁就可以消耗180M的記憶體有點誇張，而且每次更新事實上有必要更動的都只有少部分的頁面而已。
如果有模組可以限定超過10頁的留言就進入Archive Mode，不再列入排序中（生成固定編號之靜態網頁），限制住必須更新的頁面數量的話，我想應該可以降低不少cpu用量。
如果有模組可以限定超過10頁的留言就進入Archive Mode，不再列入排序中（生成固定編號之靜態網頁），限制住必須更新的頁面數量的話，我想應該可以降低不少cpu用量。
ericpony: 可以調整 STATIC_HTML_UNTIL 的值 (jHBWQJm. 11/06/30 12:21)
ericpony: http://pixmicat.wikidot.com/pmcuse:manage (jHBWQJm. 11/06/30 12:21)
◆ScRBg4WCkk: 我想這跟PHP的記憶體管理機制有點關係。程式就只是迴圈產生頁面內容然後寫入。很明顯回收不是太有效率 (MCV.Ojpo 11/06/30 12:56)
◆ScRBg4WCkk: 同上，所以有STATIC_HTML_UNTIL。看來新版本這個參數應該要預設啟用比較好。 (MCV.Ojpo 11/06/30 12:57)
f2: >ericpony：確實這個有幫助，畢竟會翻到10頁前的人少的多，不過也代表如果有人砍站會變的更吃重 (tHB3I6q2 11/06/30 13:03)
f2: 如果生成固定頁面Archive起來，不只是貼文有幫助，也不會喪失讀取效能，還可以順便解決推舊文問題 (tHB3I6q2 11/06/30 13:07)
無名氏: Archive Mode 似乎就是目前2ch的做法, 但目前PMC應沒有掛載點能支援模組實作出此功能 (5SWP1Nvc 11/06/30 22:41)
ericpony: 還是建議在pixmicat.php的主switch前面增加一個掛載點, 讓模組來決定要進入 SW (5SWP1Nvc 11/06/30 22:46)
ericpony: 還是直接輸出ModulePage (須限制最多只能有一個模組掛載在此處). 如此可大幅增加擴充彈性. (5SWP1Nvc 11/06/30 22:47)
ericpony: http://pixmicat.wikidot.com/pmcuse:manage (jHBWQJm. 11/06/30 12:21)
◆ScRBg4WCkk: 我想這跟PHP的記憶體管理機制有點關係。程式就只是迴圈產生頁面內容然後寫入。很明顯回收不是太有效率 (MCV.Ojpo 11/06/30 12:56)
◆ScRBg4WCkk: 同上，所以有STATIC_HTML_UNTIL。看來新版本這個參數應該要預設啟用比較好。 (MCV.Ojpo 11/06/30 12:57)
f2: >ericpony：確實這個有幫助，畢竟會翻到10頁前的人少的多，不過也代表如果有人砍站會變的更吃重 (tHB3I6q2 11/06/30 13:03)
f2: 如果生成固定頁面Archive起來，不只是貼文有幫助，也不會喪失讀取效能，還可以順便解決推舊文問題 (tHB3I6q2 11/06/30 13:07)
無名氏: Archive Mode 似乎就是目前2ch的做法, 但目前PMC應沒有掛載點能支援模組實作出此功能 (5SWP1Nvc 11/06/30 22:41)
ericpony: 還是建議在pixmicat.php的主switch前面增加一個掛載點, 讓模組來決定要進入 SW (5SWP1Nvc 11/06/30 22:46)
ericpony: 還是直接輸出ModulePage (須限制最多只能有一個模組掛載在此處). 如此可大幅增加擴充彈性. (5SWP1Nvc 11/06/30 22:47)
無標題 Cecil ID:N8xXtbEQ 11/06/30(四)23:14 No.3105
>>No.3104
其實我現在這樣修改了
主機1 -> 只是打開回應時候使用PHP,
主機2 -> 把圖片轉換, 寫入DB 資料, 使用FTP 上傳圖片, 轉變後的HTM跟DB檔回主機1
圖片主機1 ->接收主機2的圖片檔
圖片主機2 ->接收主機2的圖片檔
圖片主機3 ->接收主機2的圖片檔
這樣的話, 很多CPU 工作都會在主機2
實例請到裡壁上的二次裡祭測試
如果以最便宜的租用空間(每月8美金的共享空間)來設計, 不知道大家會是怎樣想?
另外, F2可不可以上傳一次你寫好的FILEIO.FTP.PHP 來參考一下? 我改寫的那個很糟糕的說......
其實我現在這樣修改了
主機1 -> 只是打開回應時候使用PHP,
主機2 -> 把圖片轉換, 寫入DB 資料, 使用FTP 上傳圖片, 轉變後的HTM跟DB檔回主機1
圖片主機1 ->接收主機2的圖片檔
圖片主機2 ->接收主機2的圖片檔
圖片主機3 ->接收主機2的圖片檔
這樣的話, 很多CPU 工作都會在主機2
實例請到裡壁上的二次裡祭測試
如果以最便宜的租用空間(每月8美金的共享空間)來設計, 不知道大家會是怎樣想?
另外, F2可不可以上傳一次你寫好的FILEIO.FTP.PHP 來參考一下? 我改寫的那個很糟糕的說......
◆ScRBg4WCkk: 預算US$8？選10美金以下的VPS至少CPU Time不會像Shared hosting那樣嚴格吧 (0efDXbGs 11/07/01 00:15)
◆ScRBg4WCkk: 然後圖片空間就隨便了，無限流量的免空拿來當彈匣用？ (0efDXbGs 11/07/01 00:16)
f2: 可能的話最好不動到付費空間的理由，事實上是在於如果遇到條子的時候，是可以從付費途徑追到人的，雖然從國 (3zqAADOI 11/07/01 14:26)
f2: 外比較不好追（國外廠商比較不鳥台灣警方），但是可以的話還是不要留尾巴 (3zqAADOI 11/07/01 14:28)
f2: 另外如我前面所述，記憶體的消耗量也要考慮，8USD的VPS可能不會給你很多RAM，要試了才知道，不過 (3zqAADOI 11/07/01 14:30)
f2: 絕對比共享空間好的多...想拿共享空間放祭典，請小心你的CPU Time... (3zqAADOI 11/07/01 14:31)
Cecil: 想問一下, 好像現在我把版面修改, 只在回應時使用PHP, 其實RAM 使用需要多少? (XolwVKdo 11/07/01 16:30)
Cecil: 現在我把生產HTML 跟圖片的工作轉到另一台主機操作, 其實可減多少CPU 使用量? (XolwVKdo 11/07/01 16:31)
無名氏: 不懂，現在的pixmicat就已經是只在發留言的時候會用到php了 (w1Nt0mek 11/07/02 02:39)
無名氏: 要把更動留言後的靜態頁面產生動作搬走幾乎就等於把整個版面搬走了...還是你指的是把資料庫分開來？ (w1Nt0mek 11/07/02 02:40)
Cecil: 所有靜態生成的工作都由別的主機2操作, 完成後HTML以及新增文章的SQLITE資料庫傳回主機1 (k.whoiDM 11/07/03 01:42)
無名氏: 如前述，生成靜態網頁的工作幾乎占了所有的CPU Time，這樣等於把整個版面搬走 (lLstgz2g 11/07/03 10:08)
◆ScRBg4WCkk: 然後圖片空間就隨便了，無限流量的免空拿來當彈匣用？ (0efDXbGs 11/07/01 00:16)
f2: 可能的話最好不動到付費空間的理由，事實上是在於如果遇到條子的時候，是可以從付費途徑追到人的，雖然從國 (3zqAADOI 11/07/01 14:26)
f2: 外比較不好追（國外廠商比較不鳥台灣警方），但是可以的話還是不要留尾巴 (3zqAADOI 11/07/01 14:28)
f2: 另外如我前面所述，記憶體的消耗量也要考慮，8USD的VPS可能不會給你很多RAM，要試了才知道，不過 (3zqAADOI 11/07/01 14:30)
f2: 絕對比共享空間好的多...想拿共享空間放祭典，請小心你的CPU Time... (3zqAADOI 11/07/01 14:31)
Cecil: 想問一下, 好像現在我把版面修改, 只在回應時使用PHP, 其實RAM 使用需要多少? (XolwVKdo 11/07/01 16:30)
Cecil: 現在我把生產HTML 跟圖片的工作轉到另一台主機操作, 其實可減多少CPU 使用量? (XolwVKdo 11/07/01 16:31)
無名氏: 不懂，現在的pixmicat就已經是只在發留言的時候會用到php了 (w1Nt0mek 11/07/02 02:39)
無名氏: 要把更動留言後的靜態頁面產生動作搬走幾乎就等於把整個版面搬走了...還是你指的是把資料庫分開來？ (w1Nt0mek 11/07/02 02:40)
Cecil: 所有靜態生成的工作都由別的主機2操作, 完成後HTML以及新增文章的SQLITE資料庫傳回主機1 (k.whoiDM 11/07/03 01:42)
無名氏: 如前述，生成靜態網頁的工作幾乎占了所有的CPU Time，這樣等於把整個版面搬走 (lLstgz2g 11/07/03 10:08)
>>No.3104
>f2: 如果生成固定頁面Archive起來，不只是貼文有幫助，也不會喪失讀取效能，還可以順便解決推舊文問題
>無名氏: Archive Mode 似乎就是目前2ch的做法, 但目前PMC應沒有掛載點能支援模組實作出此功能
>ericpony: 還是建議在pixmicat.php的主switch前面增加一個掛載點, 讓模組來決定要進入 SW
>ericpony: 還是直接輸出ModulePage (須限制最多只能有一個模組掛載在此處). 如此可大幅增加擴充彈性.
目前可能使用PostOnDeletion，在文章要被刪除時生成Archive。
生成完文章就從系統消失了，自然回不到。
至於ericpony提的這個點權限太大了，僅次於程式本身了。不知道要這種點來做什麼呢？
如果是將後面頁數導到archive的話，倒是可以在PAGENAV(換頁列)那增加一個往archive的連結即可。
雖然目前是沒辦法達到動態插入。或者也沒這個需要，想要自己去archive list看。
就是archive list需要強化一些就是了，分頁方便瀏覽/可刪除之類的。
而且如果只能有一種模組掛在這，又這麼強大的話，一定很難決定是誰要擺在這。
因為每個模組都想掛在這。
這個做法要先作的話應該可以用redirect的方式，任何瀏覽先經過這個PHP，有需要再redirect給PMC。
這樣的話倒是不必加什麼點。
>f2: 如果生成固定頁面Archive起來，不只是貼文有幫助，也不會喪失讀取效能，還可以順便解決推舊文問題
>無名氏: Archive Mode 似乎就是目前2ch的做法, 但目前PMC應沒有掛載點能支援模組實作出此功能
>ericpony: 還是建議在pixmicat.php的主switch前面增加一個掛載點, 讓模組來決定要進入 SW
>ericpony: 還是直接輸出ModulePage (須限制最多只能有一個模組掛載在此處). 如此可大幅增加擴充彈性.
目前可能使用PostOnDeletion，在文章要被刪除時生成Archive。
生成完文章就從系統消失了，自然回不到。
至於ericpony提的這個點權限太大了，僅次於程式本身了。不知道要這種點來做什麼呢？
如果是將後面頁數導到archive的話，倒是可以在PAGENAV(換頁列)那增加一個往archive的連結即可。
雖然目前是沒辦法達到動態插入。或者也沒這個需要，想要自己去archive list看。
就是archive list需要強化一些就是了，分頁方便瀏覽/可刪除之類的。
而且如果只能有一種模組掛在這，又這麼強大的話，一定很難決定是誰要擺在這。
因為每個模組都想掛在這。
這個做法要先作的話應該可以用redirect的方式，任何瀏覽先經過這個PHP，有需要再redirect給PMC。
這樣的話倒是不必加什麼點。
ericpony: 我提案的前提是所謂"這個PHP" 就是pixmicat.php本身, 這樣似乎就只能靠新增掛載點了X (g2p06Tj. 11/07/01 02:11)
無標題 無名氏 ID:3zqAADOI 11/07/01(五)14:44 No.3107
fileio.ftp.php source
http://k2yr.yaoif2.twbbs.org/up/
設定檔：
define("FILEIO_PARAMETER", serialize(array(0=>array(0=>array("sateurl"=>"http://xxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"qxxxxxxxc", "geturl"=>"http://xxxxx/satellite/k2fastival/src/satellite-zoka.php?name="),1=>array("sateurl"=>"http://xxxxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"xxxxxxxxc", "geturl"=>"http://xxxxxx/satellite/k2fastival/src/satellite-zoka.php?name="),2=>array("sateurl"=>"http://xxxxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"qwxxxxzxc", "geturl"=>"http://xxxxx/satellite/k2fastival/src/satellite-zoka.php?name=")),1=>true))); // FileIO參數 (Satellite)
http://k2yr.yaoif2.twbbs.org/up/
設定檔：
define("FILEIO_PARAMETER", serialize(array(0=>array(0=>array("sateurl"=>"http://xxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"qxxxxxxxc", "geturl"=>"http://xxxxx/satellite/k2fastival/src/satellite-zoka.php?name="),1=>array("sateurl"=>"http://xxxxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"xxxxxxxxc", "geturl"=>"http://xxxxxx/satellite/k2fastival/src/satellite-zoka.php?name="),2=>array("sateurl"=>"http://xxxxxx/satellite/k2fastival/satellite.php", "transload"=>true, "key"=>"qwxxxxzxc", "geturl"=>"http://xxxxx/satellite/k2fastival/src/satellite-zoka.php?name=")),1=>true))); // FileIO參數 (Satellite)
Cecil: 謝謝 (k.whoiDM 11/07/03 01:43)
無標題 <span class="nor">◆u66tJhMAWo</span> ID:zprt4lmI 11/07/02(六)07:21 No.3108
>>No.3106
如果在"找不到文章"的頁面加一個掛載點呢?
用文章編號 對照archive的文章編號
如果找到相符的archive,echo archive文章的連結
如果在"找不到文章"的頁面加一個掛載點呢?
用文章編號 對照archive的文章編號
如果找到相符的archive,echo archive文章的連結
◆ScRBg4WCkk: 通常來說找不到文章的話，那個連結也不會出現在版面上了。所以你要的可能是反過來列出archive就夠了 (7yukOJy6 11/07/03 20:03)
無名氏: 連結雖不會出現在版面, 但常常會出現在google的搜尋結果, 點進去找不到頁面時還蠻讓人洩氣的 (7DnFKbjo 11/07/12 20:32)
無名氏: 連結雖不會出現在版面, 但常常會出現在google的搜尋結果, 點進去找不到頁面時還蠻讓人洩氣的 (7DnFKbjo 11/07/12 20:32)