2012-04-26 55 views
1

我目前正在組合網站上工作,其中我將不得不在同一頁面上加載大量照片。在圖像密集型網頁上加載速度

這些圖像通過PHP動態加載,目前我選擇預先保存這些圖像的縮略圖版本並加載這些圖像。

然而,我擔心的是,如果網站擁有大量用戶,這可能不是最佳解決方案:我基本上會將每張圖片的重複數乘以用戶上傳的圖片數量。

我的問題是你是否有更好的解決方案來解決這個問題?在不影響太多空間的情況下儘快加載頁面的方法?

謝謝了。

+0

你提到重複的...規範化圖像和用戶之間的關係。計算每個圖像的MD5並使用它來將圖像綁定到用戶。 – HappyTimeGopher 2012-04-26 20:33:08

回答

2

加載充滿大量圖像的網頁會很慢。原因是因爲傳輸這些圖像所需的帶寬。

你有幾個選項

  1. 放入標準圖像瓷磚模式。這些圖像將是完整圖像,只是調整大小以適合「縮略圖」視圖。這樣做的好處是您只能保存1張圖片,但該圖片是全尺寸的,需要很長時間才能加載。

  2. 按照您所說的加載縮略圖。這樣做的好處是性能,但您需要存儲每個圖像的兩個副本。另外,根據你如何處理縮略圖的創建,你可能會要求用戶上傳圖像的兩個副本,以提供他們自己的縮略圖...這可能會很糟糕。

  3. 加載縮略圖,但在上傳時動態生成縮略圖。你基本上保留了磁盤上的圖像的兩個副本,但你是通過一些PHP圖像修改API動態創建它。這將加載速度更快,但仍佔用磁盤空間。它還最大限度地減少了用戶/管理要求以提供縮略圖。

  4. 根據請求頁面按需加載縮略圖。這種方法需要一些測試,因爲我從來沒有嘗試過。基本上,你會調用PHP圖像修改API(或更好的源代碼到本地解決方案!)來創建一次性使用(或緩存)的縮略圖來使用。你可能會說「OMG,這會花很長時間!」。我認爲如果您應用適當的緩存機制,這種方法可能實際上可用,因此您不會不斷重新創建相同的縮略圖。它會降低帶寬,因爲這裏的限制因素是網絡連接,所以發送完整圖像可能會更快(因爲創建縮略圖的限制因素現在是CPU /內存/硬盤)。

我認爲#4是一個有趣的概念,可能值得探討。

1
  1. 在動態生成大圖像的縮略圖。 (Some hint
  2. 加載圖像異步(嘗試JAIL
  3. PAGINATE
  4. 緩存也是一個選項,從該網站下載,雖然第二次工作。
+0

「on-the-fly」正是錯誤的答案 – KingCrunch 2012-04-26 20:34:56

+0

我的意思是動態生成縮略圖。那是錯的嗎?請解釋。 – 2012-04-26 20:36:20

+0

現在我不清楚,你的意思是「dynamicall」。但是,「即時」意味着您希望爲每個請求創建縮略圖。你絕對不想要這個;) – KingCrunch 2012-04-26 20:41:26

1

什麼,我認爲是:

A.取緩存(系統緩存,緩存在標頭,HTTP緩存..所有高速緩存)的優勢

B.不要生成Thumb所有的時間

C.使用作業Queing系統如Gearmanbeanstalkd產生豎起大拇指,這樣你就不必做它立即

D.使用Imagick更EFF icient

E. PAGINATE

F.實施例,只有當原始文件已被修改

$file = "a.jpg" ; 
$thumbFile = "a.thumb.jpg" ; 
$createThumb = true; 
if(is_file($thumbFile)) 
{ 
    if((filemtime($file) - 10) < filemtime($thumbFile)); 
    { 
     $createThumb = false; 
    } 
} 


if($createThumb === true) 
{ 
    $thumb = new Imagick(); 
    $thumb->readImage($file); 
    $thumb->thumbnailImage(50, null); 
    $thumb->writeImage($thumbFile); 
    $thumb->destroy(); 
} 
1

,緩存縮略圖是一個好主意,和做過權當將迎刃而解。這種事情是horizontal scaling的好地方。

  1. 你應該看看使用 CDN。(或者 可能實現類似的東西。)高速緩存系統將生成通常請求的大小的圖像,並且如果 在稍後變得不經常請求,則修改它們。
  2. 您也可以水平擴展並將此服務移植到您的網絡或雲中的另一臺服務器或 虛擬服務器。

這是一個磁盤密集和帶寬密集型的東西,圖像傳遞。不像視頻那樣糟糕!