2014-09-29 57 views
1

我有一個基於客戶的網站,要求他們上傳圖片,這樣我的腳本將使用GD庫將約25-30個圖像變體保存到服務器上。由於圖像數量衆多,客戶需要等待很長時間才能繼續在網站上等待所有圖像的創建和保存。在此之前,他們無法繼續下去,因此我們得到高水平的客戶離開網站。PHP - 一起使用Cron Jobs和GD

上傳後是否有可能將圖像url存儲在數據庫表記錄中,然後用一個php腳本創建25-30張圖像,將每條記錄拉到數據庫中,並使用cronjob每隔5分鐘運行一次。這樣,它允許客戶繼續通過網站,並在後臺自動創建圖像

所有這些在後臺會導致我的網站速度的任何問題?是否會讓瀏覽人羣的網站變慢,特別是如果有10到100位客戶同時使用它?

+0

是的,你可以做到這一點,這取決於你實際上對圖像做了什麼,你可能想看看運行'jpegtran',這將導致圖像更優化,然後GD可以做什麼。 – cmorrissey 2014-09-29 13:53:24

+0

打開'/ etc/cron.d/image_processing'文件並將'0-55/5 * * * * www-data/path/to/usr/bin/php/path/webservers用戶是www-data。 – DanFromGermany 2014-09-29 14:15:18

回答

0

通過PHP腳本處理,圖像不會在客戶上傳圖像並等待處理完成時在cron作業中產生更多滯後。所以總之,沒有沒有額外這種方法的影響。

問題是,您需要確保您的cron作業具有自我意識,並且不會產生重疊。例如,如果cron運行並花費超過5分鐘完成當前任務,當第二個cron啓動並開始處理另一個映像時(或者如果您沒有正確實現隊列,則會發生同樣的情況)會發生什麼?那麼現在你有兩個克朗正在運行,爭取資源。這意味着第二個可能需要5分鐘以上。最終你會發現3個,4個等cron一起運行。所以確保你的cron只在沒有運行的情況下才能「啓動」。

所有這一切都說明了,根據客戶站點的大小以及他們的流量有多沉重,您最好還是讓另一臺服務器處理圖像處理。您可以在生產站點服務器的羣集中安裝雲服務器,該服務器可以通過本地網絡連接以訪問映像,進行處理,並將25-30份副本返回到適當位置的服務器。這樣,您的處理隊列佔用面向公衆的網絡服務器的0個資源,並且不會影響網站本身的速度。

+0

你有沒有關於我如何設置的文章/教程?我沒有聽說過或看過一個網站的多臺服務器,所以不知道從哪裏開始! – 2014-09-29 15:27:25

+0

實現多服務器設置將是兩個選項中更高級的選項,因爲它需要將兩個文件系統聯網在一起,以便處理服務器可以讀取/寫入面向網絡的服務器。我將從一個構建cron作業的簡單系統開始,以便它不允許重疊運行等,並讓它在後臺進行處理。從那裏你可以很容易地擴展。 – Brian 2014-09-29 16:50:46

+0

謝謝布賴恩,我現在要走這條路,並使用flock()來確保沒有重疊 – 2014-09-30 08:29:03

1

我建議開始看queues,更具體到Gearman

這樣可以減少客戶的加載時間,因爲您可以將生成的圖像卸載到單獨的服務器。如果您需要更多處理能力,它可以輕鬆擴展到多臺服務器。

+0

不幸的是,當前的共享服務器不允許使用gearman,客戶端也不會升級或更改。有其他選擇嗎? – 2014-09-29 15:26:34

+0

您可以使用外部隊列,如IronMQ或Amazon Simple Queue Service。但如果你的客戶不想升級,我認爲他不想爲這些外部服務支付費用...... – tom 2014-10-01 07:33:53

0

確定您可以將圖像的PATH存儲在服務器上並稍後處理。 創建PHP腳本,當運行時創建一個LOCK文件,即「/tmp/imgprocessor.lock」並在最後刪除它,如果cron啓動一個新的進程,你首先檢查該文件不存在。 我會將上傳的圖像存儲在ie pathtoimages/toprocess /中,並在處理後刪除每個圖像或將它移動到別處。在ie/processed中有新圖像

這樣,您不需要爲圖像路徑查詢數據庫,只需處理'toprocess'文件夾中的內容,並且只需在表格中添加UNIQ_NAME_OF_IMAGE即可。在您的網頁腳本加載之前檢查UNIQ_NAME_OF_IMAGE是否存在於'已處理'文件夾中,如果是,則顯示它...

在服務器負載上,它取決於原始圖像的大小和大小,圖像處理在服務器上可能很重,但處理1000個用戶* 30張圖像不會是一項繁重的任務,正如我所說的取決於圖像的大小。

注意:如果你這樣做,你需要確保在啓動cron時ERROR日誌也輸出到某個日誌文件。 Cron腳本必須是防彈的,即如果由於某種原因LOCK文件失敗,所以不再進行處理,您需要手動刪除它(或創建自定義錯誤處理程序,刪除它並可能發送一些郵件),您應該定期檢查日誌文件,以便知道發生了什麼事情。