2011-09-20 31 views
0

我正在開發一個phonegap應用程序,該應用程序的一部分是大約10個基於base64編碼的圖像,並且每個用戶每週下載一次(現在有100個用戶,希望成長很多) My服務器很慢,我也在工作,所以這些圖像的傳輸速度很慢。 我的問題是: 將這些base64圖像生成並保存到db一次,並根據請求從數據庫獲取圖像,或每次請求圖像時base64編碼圖像會更快,php和服務器明智嗎?提供10個基本64圖像的最佳實踐

感謝您的幫助。

回答

1

它會肯定要快到base64編碼的圖像和存儲的編碼。

這是一個經典的內存與速度的折衷方案,您可以支付更低的計算成本,以獲得更高的內存成本。在這種情況下,這意味着如果只保留編碼版本,則保存更多數據( 8/7 8/6以上,如果保留原始版本,則保留原始版本多一點多)。

您可以做的最好的事情是將圖像保存在內存中,因爲這樣可以避免訪問磁盤的成本。您可以使用shared memory functions或濫用會話變量並分配固定會話ID來檢索內容。

+1

基礎64是原始數據大小的8/6,因爲它映射6位到8位(不是8/7) – Dani

+0

或「只是memcached」 - 儘管原始方法和解決方案應該進行基準測試。 base64是一個*快*算法,所以我相信這個問題在別處。 – 2011-09-20 01:37:02

1

不知道你的應用程序的細節,在我看來,有一個數據庫只有10個圖像是矯枉過正。在緩慢的服務器上運行數據庫的額外開銷可能會消除保存base64編碼可能帶來的任何好處。

我會將base64編碼的圖像存儲爲文件而不是數據庫,以便它們可以通過Web服務器直接提供給客戶端。

如果客戶端可以處理它,我還會確保您可以傳遞數據gzip壓縮,因爲base64數據壓縮得非常好。這將大大減少您的服務器的流量。請參閱this

+0

+1用於建議使用FS(並讓服務器執行此操作):在這種情況下,實際圖像將被髮送(而不是用於發送嵌入ML中的圖像的base64)。 – 2011-09-20 01:47:54

1

在服務器成爲處理器綁定之前,您很可能會受到帶寬限制。我的想法:

  • 請勿發送base64編碼圖像。相反,發送正確壓縮的二進制數據。
  • 除非需要更新客戶端(即,如果沒有新圖片需要抓取,則不要抓取圖片)。使用304標題和相關信息來跟蹤。
  • 一旦事情開始難以解決,請使用memcache/Redis而不是數據庫來存儲「預先消解的」圖像數據。
+0

+1我真的很喜歡*使用HTTP協議。還有ETags,在這裏可能很有用。 – 2011-09-20 01:42:55