Dalam cache, PHP membuat Gambar Mini memuat dengan lambat


179

Pertanyaan Bagian A ▉ (100 hadiah, diberikan)
Pertanyaan utama adalah bagaimana membuat situs ini, memuat lebih cepat. Pertama, kami perlu membaca air terjun ini. Terima kasih atas saran Anda tentang analisis pembacaan air terjun. Terbukti dari berbagai grafik air terjun yang ditampilkan di sini adalah hambatan utama: thumbnail yang dihasilkan PHP. Pemuatan protokol-kurang jquery dari CDN yang disarankan oleh David mendapatkan hadiah saya, meskipun membuat situs saya hanya 3% lebih cepat secara keseluruhan, dan sementara tidak menjawab hambatan utama situs. Saatnya untuk klarifikasi pertanyaan saya, dan, hadiah lain:

Pertanyaan Bagian B ▉ (hadiah 100, diberikan)
Fokus baru sekarang adalah untuk menyelesaikan masalah yang dimiliki gambar 6 jpg, yang menyebabkan penundaan pemuatan paling banyak. 6 gambar ini adalah thumbnail yang dihasilkan PHP, kecil dan hanya 3 ~ 5 kb, tetapi memuat relatif sangat lambat. Perhatikan " waktu untuk byte pertama " pada berbagai grafik. Masalahnya tetap belum terpecahkan, tetapi hadiah pergi ke James, yang memperbaiki kesalahan header yang digarisbawahi RedBot : "Permintaan bersyarat-Jika-Dimodifikasi-Karena mengembalikan konten lengkap tidak berubah." .

Pertanyaan Bagian C ▉ (hadiah terakhir saya: 250 poin)
Sayangnya, bahkan setelah kesalahan header REdbot.org diperbaiki, penundaan yang disebabkan oleh gambar yang dihasilkan PHP tetap tidak tersentuh. Apa yang dipikirkan thumbnail kecil 3 ~ 5Kb kecil ini? Semua informasi header itu dapat mengirim roket ke bulan dan kembali. Setiap saran tentang hambatan ini sangat dihargai dan diperlakukan sebagai jawaban yang mungkin, karena saya terjebak pada masalah kemacetan ini sudah tujuh bulan sekarang. Terima kasih sebelumnya.

[Beberapa info latar belakang di situs saya: CSS ada di atas. JS di bagian bawah (Jquery, JQuery UI, membeli mesin menu awm / menu.js, mesin tabs js, video swfobject.js) Garis hitam pada gambar kedua menunjukkan apa yang memulai apa yang akan dimuat. Robot yang marah adalah hewan peliharaan saya "ZAM". Dia tidak berbahaya dan sering lebih bahagia.]


Load Waterfall: Kronologis | http://webpagetest.org masukkan deskripsi gambar di sini


Domain Paralel yang Dikelompokkan | http://webpagetest.org masukkan deskripsi gambar di sini


Air Terjun Situs-Perf | http://site-perf.com masukkan deskripsi gambar di sini


Air Terjun Pingdom Tools | http://tools.pingdom.com

masukkan deskripsi gambar di sini


Air Terjun GTmetrix | http://gtmetrix.com

masukkan deskripsi gambar di sini



11
Saya pikir sebagian besar browser hanya membuat 20 koneksi pada satu waktu sehingga setelah 20 yang pertama harus selesai sebelum mulai berikutnya, maka perlambatan setelah 20

1
Saya pikir Anda lupa untuk mereduksi instance pertama domain Anda. Setidaknya Anda mendapatkan sisanya: D
fiftydot

2
Tidak bisakah Anda menggabungkan beberapa gambar itu ke dalam sprite?
Marcel Korpel

1
@Agon, ketahuilah bahwa HTTP 1.1 RFC meminta ( SHOULD) untuk klien HTTP 1.1 untuk menggunakan paling banyak 2 koneksi ke server HTTP 1.1; HTTP 1.0 tentu saja jauh lebih terbuka.
sarnold

1
Browser @agon juga hanya akan membuat 2 koneksi bersamaan ke domain tertentu.
Endophage

Jawaban:


61

Pertama, menggunakan beberapa domain tersebut membutuhkan beberapa pencarian DNS. Sebaiknya Anda menggabungkan banyak gambar-gambar itu menjadi sprite daripada menyebarkan permintaan.

Kedua, ketika saya memuat halaman Anda, saya melihat sebagian besar pemblokiran (~ 1,25s) di all.js. Saya melihat itu dimulai dengan (versi lama) jQuery. Anda harus merujuknya dari Google CDN, untuk tidak hanya mengurangi waktu muat , tetapi juga berpotensi menghindari permintaan HTTP untuk itu .

Khususnya, pustaka jQuery dan jQuery UI terbaru dapat dirujuk di URL ini (lihat posting ini jika Anda tertarik mengapa saya menghapusnya http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Jika Anda menggunakan salah satu tema UI jQuery default, Anda juga dapat menarik CSS dan gambarnya dari Google CDN .

Dengan hosting jQuery dioptimalkan, Anda juga harus menggabungkan awmlib2.jsdan tooltiplib.jsmenjadi satu file.

Jika Anda mengatasi hal-hal itu, Anda akan melihat peningkatan yang signifikan.


1
Komentar luar biasa Dave! 1,3 JQuery lama jauh lebih kecil jadi saya pikir saat bekerja, mungkin lebih cepat. Tapi saya suka rekomendasi Anda: Tautan google CDN mana yang Anda sarankan untuk saya gunakan sebagai Jqyuery saya? Bisakah saya menggunakan javascript UI JQ yang sama? +1 terima kasih banyak
Sam

2
Saya merekomendasikan menggunakan jQuery versi terbaru (1.4.4 saat ini). Saat diperkecil dan di-gzip, hanya ada beberapa byte perbedaan di antara mereka. Saya telah memperbarui jawabannya dengan beberapa tautan ke versi jQuery dan jQuery UI terbaru di Google CDN, yang saya sarankan untuk digunakan.
Dave Ward

1
Tip bagus dengan sprite, yang seharusnya mengurangi jumlah koneksi terbuka ke server
JamesHalsall

saat ini sedang bekerja untuk mengurangi koneksi terbuka (beralih dari 40 orso menjadi sekarang 30 orso ... dorongan terakhir adalah yang paling sulit karena beberapa gambar adalah latar belakang pengulang dan tidak bisa menjadi sprite (atau ???)
Sam

Perbarui Page Speed ​​Grade: (96%) YSlow Grade: (90%) ... dan thumbnailnya tetap sama lambatnya!
Sam

17

Aku punya masalah yang sama beberapa hari yang lalu & saya menemukan head.js . Ini adalah Plugin Javascript yang memungkinkan Anda untuk memuat semua file JS paralell. Semoga itu bisa membantu.


Luar biasa! Bagaimana saya bisa mengabaikan hal itu? +1 Saya akan menguji sekarang ini. Baunya seperti malam yang subur. Terima kasih Schattenbaum!
Sam

1
Bolehkah saya bertanya apakah Anda Schattenbaum dari schattenbaum.net?
Pekka

12

Saya jauh dari ahli tetapi ...

Sehubungan dengan ini: "Permintaan bersyarat-Jika-Dimodifikasi-Sejak mengembalikan konten lengkap tidak berubah." dan komentar saya.

Kode yang digunakan untuk menghasilkan Gambar Kecil harus memeriksa hal-hal berikut:

  1. Apakah ada versi thumbnail yang di-cache.
  2. Apakah versi yang di-cache lebih baru dari gambar aslinya.

Jika salah satu dari ini salah, thumbnail harus dibuat dan dikembalikan tidak peduli apa. Jika keduanya benar maka pemeriksaan berikut harus dilakukan:

  1. Apakah ada tajuk HTTP_IF_MODIFIED_SINCE
  2. Apakah waktu terakhir versi yang di-cache itu sama dengan HTTP_IF_MODIFIED_SINCE

Jika salah satu dari ini salah, thumbnail yang di-cache harus dikembalikan.

Jika keduanya benar maka status 304 http harus dikembalikan. Saya tidak yakin apakah ini diperlukan tetapi saya juga secara pribadi mengembalikan header Cache-Control, Expires, dan Last-Modified bersama dengan 304.

Sehubungan dengan GZipping, saya telah diberitahu bahwa tidak perlu gambar GZip jadi abaikan bagian komentar saya itu.

Sunting: Saya tidak melihat tambahan Anda pada kiriman Anda.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

Saya juga yakin bahwa kode Anda perlu memeriksa tajuk HTTP_IF_MODIFIED_SINCE dan bereaksi terhadapnya. Hanya dengan mengatur header ini dan file .htaccess Anda tidak akan memberikan hasil yang diperlukan.

Saya pikir Anda perlu sesuatu seperti ini:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

James, Anda telah menemukan inti masalah setelah diedit dalam jawaban Anda! yang If Modified Sincemasalah tampaknya bekerja sekarang! Namun, tajuk panjang / waktu tunggu untuk ibu jari mungil ini belum terpecahkan ...
Sam

@ James PS REdbot.org mengatakan bahwa header Kedaluwarsa Anda adalah nilai yang salah. Saya pikir itu harus GMT dan bukan CET?
Sam

@ Sam Maaf server saya ada di Inggris sehingga ia menghasilkan tanggal GMT secara otomatis. Gunakan saja fungsi PHP gmdate sebagai ganti date. Ini harus menghasilkan tanggal GMT relatif terhadap waktu server Anda.
James

1
@ Sam, Waktu tunggu Anda adalah waktu eksekusi skrip. Entah itu butuh waktu lama untuk melewati kode Anda ke titik Anda mengirim header Anda atau Anda tidak keluar setelah Anda mengirim header Anda.
James

@ James, saya mengerti ... Tetapi selain dari generator thumbnail thumbnail php itu, ada banyak sekali skrip panjang yang sama lainnya yang melakukan berbagai hal lain (terjemahan, pemuatan menu dll) semuanya dalam waktu singkat ... MEREKA sepertinya tidak mengalami hambatan sama sekali ... apakah itu mengarahkan masalah kemudian ke generator thumbnail php SAJA?
Sam

6

Wow, sulit untuk menjelaskan hal-hal menggunakan gambar itu .. Tapi di sini, beberapa mencoba:

  • file 33-36 memuat selambat itu, karena mereka dimuat secara dinamis di dalam swf, dan swf (25) dimuat terlebih dahulu sepenuhnya sebelum memuat konten tambahan apa pun
  • file 20 & 21 mungkin (saya tidak tahu, karena saya tidak tahu kode Anda) pustaka yang dimuat oleh all.js (11), tetapi untuk 11 untuk mengeksekusi, ia menunggu seluruh halaman (dan aset) untuk memuat (Anda harus mengubahnya ke domready)
  • file 22-32 dimuat oleh dua pustaka itu, sekali lagi setelah itu sepenuhnya dimuat

Poin yang menarik. Saya kira tidak ada apa-apa di sekitar swf ... Bagaimana saya bisa mengubah apa yang sudah ada? Saya punya firasat apa yang Anda maksud. Ini tentang kapan javascript siap dan memberitahu pada dokumen siap ini atau itu? haruskah dokumen itu. sudah diganti oleh dom.ready?
Sam

@ Sam jika Anda menggunakan caching sisi klien (dan Anda seharusnya), Anda dapat memuat sumber daya yang digunakan oleh swf di js atau div tersembunyi di halaman Anda sehingga ketika swf meminta mereka, mereka sudah berada di klien.
Endofage

4

Hanya tebakan sederhana karena analisis semacam ini membutuhkan banyak pengujian A / B: domain .ch Anda tampaknya sulit dijangkau (panjang, pita hijau sebelum byte pertama tiba).

Ini berarti bahwa situs web .ch di-host dengan buruk atau ISP Anda tidak memiliki rute yang baik untuk mereka.

Mengingat diagram, ini bisa menjelaskan hit kinerja besar.

Di samping catatan, ada alat keren ini cuzillion yang dapat membantu Anda memilah hal-hal tergantung pada pemesanan Anda memuat sumber daya.


4

Coba jalankan tes Y! Lambat dan Kecepatan Halaman di situs / halaman Anda, dan ikuti panduan untuk menyelesaikan kemungkinan hambatan kinerja. Anda harus mendapatkan keuntungan kinerja yang sangat besar setelah skor Anda lebih tinggi di Y! Lambat atau Kecepatan Laman.

Tes ini akan memberi tahu Anda apa yang salah dan apa yang harus diubah.


Terima kasih! nilainya adalah: 92 pada Kecepatan Halaman dan 93 pada Ylow. Yang hilang adalah: TETAP HIDUP = tidak aktif dan tidak menggunakan CDN.
Sam

UPDATE: 96 dan 90 masing-masing saat ini
Sam

4

Jadi skrip PHP Anda menghasilkan thumbnail pada setiap pemuatan halaman? Pertama, jika gambar yang sedang di-thumbnail tidak sering berubah, dapatkah Anda mengatur cache sehingga tidak harus diuraikan setiap kali halaman dimuat? Kedua, apakah skrip PHP Anda menggunakan sesuatu seperti imagecopyresampled()untuk membuat thumbnail? Itu adalah downsample non-sepele dan skrip PHP tidak akan mengembalikan apa pun sampai selesai menyusut. Menggunakan imagecopymerged()malah akan mengurangi kualitas gambar, tapi mempercepat proses. Dan berapa banyak pengurangan yang Anda lakukan? Apakah thumbnail ini 5% ukuran gambar asli atau 50%? Ukuran yang lebih besar dari gambar asli kemungkinan mengarah ke perlambatan karena skrip PHP harus mendapatkan gambar asli dalam memori sebelum dapat mengecilkannya dan menghasilkan thumbnail yang lebih kecil.


Terima kasih MidnightLightning! Ada folder cache tempat thumbnail JPG dibuat dan digunakan kembali, meskipun saya merasa di sini terletak masalah skrip yang telah saya beli (dan tampaknya berfungsi dengan baik untuk orang lain)
Sam

2
Jika thumbnail di-cache, pastikan skrip yang menariknya dari cache menggunakan readfile()daripada file_get_contents()diikuti oleh gema, yang menunggu untuk mengeluarkan apa pun sampai seluruh file dipindahkan ke memori skrip PHP.
MidnightLightning

Lebih baik lagi - jika file di-cache, buat HTML dengan cara yang secara langsung menarik gambar yang di-cache dari disk tanpa melalui PHP. Itulah yang saya lakukan dalam skrip saya untuk videodb.net
andig

"Ada folder cache di mana ..." dan seberapa cepat mereka dereferensi? Apakah URL Anda mengarah langsung ke file cache atau skrip PHP? Apakah Anda mengarahkan atau menggunakan readfile ()? Apakah skrip PHP yang sama berisi kode pembuatan thumbnail - atau apakah Anda menunda memuat sebagian besar kode menggunakan include / erquire?
symcbean

4

Saya telah menemukan URL situs web Anda dan memeriksa satu file jpg dari beranda. Sementara waktu memuat masuk akal sekarang (161ms), itu menunggu 126ms, yang terlalu banyak.

Header terakhir Anda yang dimodifikasi siap untuk Sabtu, 01 Jan 2011 12:00:00 GMT, yang terlihat terlalu "bulat" untuk menjadi tanggal sesungguhnya dari generasi ;-)

Karena kontrol Cache adalah "publik, maks-usia = 14515200", header yang dimodifikasi terakhir secara sewenang-wenang akan dapat menyebabkan masalah setelah 168 hari.

Bagaimanapun, ini bukan alasan sebenarnya untuk penundaan.

Anda harus memeriksa apa yang generator thumbnail lakukan ketika thumbnail sudah ada dan apa yang bisa menghabiskan banyak waktu untuk memeriksa dan mengirimkan gambar.

Anda dapat menginstal xdebug ke profil skrip dan melihat di mana kemacetannya.

Mungkin semuanya menggunakan kerangka kerja atau menghubungkan ke beberapa database tanpa biaya. Saya telah melihat sangat lambat mysql_connect () pada beberapa server, sebagian besar karena mereka terhubung menggunakan TCP dan bukan socket, kadang-kadang dengan beberapa masalah DNS.

Saya mengerti Anda tidak dapat memposting generator berbayar Anda di sini, tetapi saya khawatir ada terlalu banyak masalah yang mungkin terjadi ...


Terima kasih atas detektif Anda & mengetahui petunjuk Capsule! Hal pertama yang pertama: tidak ada database. Temuan Anda sama dengan temuan saya: menunggu 90% dari waktu? Jempol kecil yang gila. Pikiran yang menarik pada header yang terakhir dimodifikasi, karena menurut James posting di sini, saya harus mengatur header yang terakhir diubah ke waktu STATIC (tetap), bukan waktu dinamis / selalu berubah yang ditetapkan oleh generator gmdate php. Atau mungkin Anda bermaksud sesuatu yang lain di sini? (Dinominasikan untuk hadiah)
Sam

1
Agar sempurna, ini harus mencerminkan tanggal pembuatan sebenarnya, misalnya dengan mendapatkan filemtime () dari thumbnail yang di-cache. Apa yang akan menarik untuk diuji adalah mengakses file PHP kosong, atau file PHP hanya menggemakan "tes" dan lihat seberapa banyak Anda menunggu menunggu yang satu ini. Mungkin seluruh server lambat dan berdampak pada setiap skrip PHP tunggal, apa pun fungsinya.
Kapsul

1
Saya juga melihat penundaan yang relatif lama pada file statis murni (misalnya gambar yang ditautkan ke ibu jari), seperti 36ms. Pada salah satu server yang saya kelola (yang bukan binatang ... dual core dengan 2Gb RAL), saya mendapatkan hampir setengahnya, seperti 20 ms pada file statis.
Kapsul

Menarik ... 1. perangkat lunak / alat online apa yang Anda gunakan untuk mengukur? 2. apakah pengukuran 20 ms Anda yang lebih cepat konsisten (berapa banyak ± xx%) menurut Anda hasilnya bervariasi? Dalam kasus saya itu sangat bervariasi tergantung pada alat tes apa yang saya gunakan. beberapa sangat konsisten ( gtmetrix.com ) ada yang sangat bervariasi ( pingdom.com ) dan sulit untuk memberi waktu dalam XX ms karena mereka berubah setiap saat ...
Sam

Saya menggunakan tab NET Firebug. 20ms adalah waktu tercepat yang saya dapatkan. Ini bervariasi antara 20 dan 28. Tentu saja 36ms yang saya ukur di server Anda adalah yang tercepat juga.
Kapsul

4

Jika tidak ada alasan yang sangat bagus (biasanya tidak ada) gambar Anda seharusnya tidak memanggil penerjemah PHP.

Buat aturan penulisan ulang untuk server web Anda yang server gambar langsung jika ditemukan pada sistem file. Jika tidak, arahkan ulang ke skrip PHP Anda untuk menghasilkan gambar. Saat Anda mengedit gambar, ubah nama file gambar untuk memaksa pengguna yang memiliki versi cache untuk mengambil gambar yang baru diedit.

Jika tidak bekerja setidaknya Anda sekarang tidak akan ada hubungannya dengan cara gambar dibuat dan diperiksa.


Terima kasih Goran, namun ini bukan solusi elegan yang saya inginkan: Saya pikir ada sesuatu yang mencurigakan dalam kasus saya, dan itu biasanya tidak butuh waktu lama untuk skrip php untuk mengetahui apakah akan melewati header 304 atau untuk memanggang image dll. terima kasih atas saran Anda karena mengarahkan masalah dari perspektif yang sama sekali baru! Yang berharga dengan sendirinya +1
Sam

3

Selidiki penggunaan data sesi PHP. Mungkin (mungkin saja), skrip PHP penghasil gambar sedang menunggu untuk mendapatkan kunci pada data sesi, yang dikunci oleh halaman utama yang masih render atau skrip rendering gambar lainnya. Ini akan membuat semua optimasi JavaScript / browser hampir tidak relevan, karena browser menunggu server.

PHP mengunci data sesi untuk setiap skrip yang berjalan, dari saat penanganan sesi dimulai, hingga saat skrip selesai, atau ketika session_write_close () dipanggil. Ini secara efektif membuat cerita bersambung banyak hal. Lihat halaman PHP pada sesi, terutama komentar, seperti ini .


Terima kasih atas saran Ricardo! Tampaknya Alix menyarankan hal yang sama dengan Anda (kan?). Secara praktis, apa yang Anda sarankan untuk saya letakkan / hapus dari kode, lalu uji lagi grafiknya lalu laporkan kembali? Sangat dihargai.
Sam

1
Ya saya pikir begitu. Saya sarankan Anda mengubah skrip penghasil gambar sehingga skrip tersebut tidak bergantung pada data $ _SESSION atau yang serupa (mungkin sudah tidak ada). Kemudian gunakan session_write_close () sesegera mungkin , atau, lebih baik lagi, hindari menggunakan sesi sama sekali pada skrip tersebut. Lihatlah php.net/manual/en/function.session-write-close.php
Ricardo Pardini

3

Ini hanya tebakan liar karena saya belum melihat kode Anda tetapi saya menduga sesi mungkin berperan di sini, berikut ini dari entri Manual PHP pada session_write_close():

Data sesi biasanya disimpan setelah skrip Anda dihentikan tanpa perlu memanggil session_write_close (), tetapi karena data sesi dikunci untuk mencegah penulisan bersamaan, hanya satu skrip yang dapat beroperasi pada suatu sesi kapan saja. Saat menggunakan bingkai bersama dengan sesi Anda akan mengalami bingkai memuat satu per satu karena penguncian ini. Anda dapat mengurangi waktu yang diperlukan untuk memuat semua frame dengan mengakhiri sesi segera setelah semua perubahan pada variabel sesi dilakukan.

Seperti yang saya katakan, saya tidak tahu apa kode Anda lakukan tetapi grafik itu anehnya mencurigakan. Saya memiliki masalah serupa ketika saya mengkodekan fungsi melayani file multi-bagian dan saya memiliki masalah yang sama. Saat menyajikan file besar, saya tidak bisa menjalankan fungsionalitas multi bagian atau membuka halaman lain hingga pengunduhan selesai. Panggilan session_write_close()memperbaiki kedua masalah saya.


Terima kasih Alix atas saran Anda. Sebuah pertanyaan: apakah exit();fungsinya sama dengan session_write_close();? saat ini, penulis asli kode sedang menyelidiki masalah ini, tetapi helas tampaknya dia juga agak dalam kegelapan, karena dia perbarui kode dengan penanganan If-Modified-Sejak penanganan yang lebih baik tampaknya memiliki penundaan yang sama (air terjun baru grafik menghasilkan grafik yang sama, meskipun hasil nyata dunia tampak / terasa lebih cepat memuat! Ini masalah yang sangat aneh ...
Sam

1
@ Sam: Saya tidak bisa memberikan Anda sumber apa pun sekarang, tapi saya yakin exit () pertama-tama memanggil setiap destruktor dan / atau fungsi yang terdaftar untuk shutdown dan hanya setelah sesi ditutup. Bagaimanapun, saya yakin masalah Anda mungkin ada sebelum panggilan keluar () Anda. Lihat juga: stackoverflow.com/questions/1674314/…
Alix Axel

2

Sudahkah Anda mencoba mengganti php yang dihasilkan dengan gambar biasa untuk melihat apakah ada perbedaan? Masalahnya bisa sekitar - bug dalam kode php Anda mengarah ke regenerasi thumbnail pada setiap permintaan server - penundaan dalam kode Anda (sleep ()?) Yang terkait dengan masalah jam - masalah hardrive yang menyebabkan kondisi balapan yang sangat buruk karena semua thumbnail dimuat / dihasilkan pada saat yang sama.


Sesuatu yang saya pikir akan mencoba memberi +1 untuk membaca pemikiran saya dan mengungkapkan solusi pertama yang sudah saya lakukan. Apa yang saya HOPING, adalah untuk menemukan bahwa gambar normal juga akan memuat perlahan-lahan karena itu bisa menjadi kecepatan unduhan dengan sesuatu atau secara fisik membatasi, tetapi saya malah menemukan bahwa gambar dump statis normal (saya menyimpan jempol yang dihasilkan dan diunggah sebagai statis) ini dimuat Sangat cepat. Jadi itu harus dilakukan dengan apa generator thumbnail php!
Sam

2

Saya pikir alih-alih menggunakan skrip thumbnail-generator, Anda harus mencoba TinySRC untuk pembuatan thumbnail cepat yang cepat dan di-host cloud. Ini memiliki API yang sangat sederhana dan mudah digunakan, Anda dapat menggunakan seperti: -

http://i.tinysrc.mobi/ [height] / [width] /http://domain.tld/path_to_img.jpg

[lebar] (opsional): - Ini adalah lebar dalam piksel (yang mengesampingkan ukuran adaptif atau keluarga). Jika diawali dengan '-' atau 'x', itu akan mengurangi, atau menyusut menjadi persentase dari, ukuran yang ditentukan.

[tinggi] (opsional): - Ini adalah tinggi dalam piksel, jika lebar juga ada. Ini juga mengesampingkan ukuran adaptif atau keluarga dan dapat diawali dengan '-' atau 'x'.

Anda dapat memeriksa ringkasan API di sini


Faq

Berapa biaya tinySrc bagi saya?

Tidak ada.

Kapan saya bisa mulai menggunakan tinySrc?

Sekarang.

Seberapa andal layanan ini?

Kami tidak membuat jaminan tentang layanan tinySrc. Namun, ini berjalan pada infrastruktur cloud terdistribusi utama , sehingga menyediakan ketersediaan tinggi di seluruh dunia. Itu harus cukup untuk semua kebutuhan Anda.

Seberapa cepat?

cache kecilSrc mengubah ukuran gambar dalam memori dan di datastore kami hingga 24 jam , dan itu tidak akan mengambil gambar asli Anda setiap kali. Ini membuat layanan sangat cepat dari perspektif pengguna. (Dan mengurangi beban server Anda sebagai efek samping yang bagus.)


Semoga berhasil. Hanya saran, karena Anda tidak menunjukkan kepada kita kode: p


2

Karena beberapa browser hanya mengunduh 2 parallel unduhan per domain, Anda tidak dapat menambahkan domain tambahan untuk membatalkan permintaan lebih dari dua hingga tiga nama host yang berbeda. mis. 1.imagecdn.com 2.imagecdn.com


+1 untuk saran Anda: terima kasih, tetapi jika Anda melihat lebih dekat pada saya (mengaku: gambar yang sangat kacau) Anda akan melihat bahwa beberapa item berasal dari ....... es beberapa berasal dari ........ com .......... de TAPI, mungkin itu tidak berhasil dan saran Anda tidak? (Saya melihat Anda menyarankan subdomain, bukan hanya domain yang berbeda.)
Sam

1

Pertama-tama, Anda perlu menangani If-Modified-Sincepermintaan dan hal itu dengan tepat, seperti yang dikatakan James. Kesalahan itu menyatakan bahwa: "Ketika saya bertanya kepada server Anda apakah gambar itu dimodifikasi sejak terakhir kali, ia mengirim seluruh gambar alih-alih ya / tidak sederhana".

Waktu antara koneksi dan byte pertama biasanya adalah waktu yang dibutuhkan skrip PHP Anda untuk menjalankannya. Jelas ada sesuatu yang terjadi ketika skrip itu mulai berjalan.

  1. Sudahkah Anda mempertimbangkan untuk membuat profil? Mungkin ada beberapa masalah.
  2. Dikombinasikan dengan masalah di atas, skrip Anda mungkin berjalan lebih banyak dari yang dibutuhkan. Idealnya, ini hanya menghasilkan jempol jika gambar asli dimodifikasi dan mengirim jempol yang di-cache untuk setiap permintaan lainnya. Sudahkah Anda memeriksa bahwa skrip menghasilkan gambar yang tidak perlu (mis. Untuk setiap permintaan)?

Menghasilkan tajuk yang tepat melalui aplikasi agak sulit, ditambah lagi mereka mungkin ditimpa oleh server. Dan Anda terkena penyalahgunaan karena siapa pun yang mengirim beberapa header permintaan tanpa cache akan menyebabkan generator thumbnail Anda berjalan terus menerus (dan meningkatkan beban). Jadi, jika mungkin, cobalah untuk menyimpan jempol yang dihasilkan, panggil gambar yang disimpan langsung dari halaman Anda dan kelola tajuk dari .htaccess. Dalam hal ini, Anda bahkan tidak perlu apa pun di .htaccessserver Anda jika server Anda dikonfigurasi dengan benar.

Selain itu, Anda dapat menerapkan beberapa ide optimisasi cerah dari bagian kinerja dari keseluruhan pertanyaan SO yang bagus tentang cara melakukan situs web dengan cara yang benar , seperti membagi sumber daya Anda ke dalam subdomain yang tidak bisa memasak, dll. Tetapi bagaimanapun, gambar 3k seharusnya tidak mengambil detik untuk memuat, ini jelas bila dibandingkan dengan item lain dalam grafik. Anda harus mencoba mengenali masalahnya sebelum mengoptimalkan.


-1: Menanggapi permintaan bersyarat dengan 'Tidak diubah' dan tidak ada waktu kedaluwarsa yang direvisi akan membuat situs Anda lebih lambat dalam 99,9% kasus (BTW, AFAIK, tidak ada cara untuk membuat Apache mengeluarkan info caching yang direvisi dengan respons 304)
symcbean

Dan, apa hubungannya dengan jawaban saya?
Halil Özgür

1

Sudahkah Anda mencoba menyiapkan beberapa subdomain di bawah server web NGINX khusus untuk menyajikan data statis seperti gambar dan stylesheet? Sesuatu yang bermanfaat dapat ditemukan dalam topik ini .


Terima kasih! Namun, setelah beberapa penelitian, pengaturan subdomain ke cookie statis server hanya membuat situs lebih cepat, ketika ada banyak gambar, dengan biaya overhead tambahan. Dalam kasus saya, saya bertaruh 6 gambar tidak akan memuat lebih cepat daripada overhead sub / ekstra domain. Baik?
Sam

1
NGinx mendukung syscall sendfile, yang dapat mengirim file langsung dari hdd. silakan lihat dokumen berikut wiki.nginx.org/HttpCoreModule pada arahan 'sendfile', 'aio'. Server web ini menyajikan file statis seperti gambar jauh lebih cepat daripada apache.
nefo_x

menarik ... Saya tidak tahu ada yang lebih baik dari Apache. Ngomong-ngomong, apa maksudmu straight from hdd. maksud Anda sebaliknya straight from DDR3 RAM/ straight from Solid State DiskSaya tahu bahwa harddisk, tidak seperti ram DDR3 atau Solid State Discs, memiliki waktu akses yang sangat lambat. Tapi saya merasa ini bukan hambatan di sini ...
Sam

1
intinya adalah nginx tidak buffer output data statis, seperti apache.
nefo_x

1

Mengenai thumbnail yang tertunda, coba lakukan panggilan flush () segera setelah panggilan terakhir ke header () di skrip pembuatan thumbnail Anda. Setelah selesai, buat kembali grafik air terjun Anda dan lihat apakah penundaannya sekarang ada di tubuh alih-alih tajuk. Jika demikian, Anda perlu melihat panjang pada logika yang menghasilkan dan / atau menampilkan data gambar.

Skrip yang menangani thumbnail semoga semoga menggunakan semacam caching sehingga tindakan apa pun yang dilakukan pada gambar yang Anda sajikan hanya akan terjadi ketika benar-benar diperlukan. Sepertinya beberapa operasi mahal terjadi setiap kali Anda melayani thumbnail yang menunda output apa pun (termasuk header) dari skrip.


+1 Tebakan menarik akan mencobanya sekarang! akan melaporkan kembali ketika Air Terjun baru saya mengalir ...
Sam

Sayangnya, setelah menambahkan flush();tepat setelah tajuk, tampaknya tidak ada perubahan sama sekali! Apa artinya itu?
Sam

Tidak yakin. Apakah ada cara Anda dapat menautkan kami ke skrip PHP yang dimaksud? Saya tahu Anda membayar untuk itu, tetapi sangat sulit untuk mengatakan apa yang mungkin menyebabkan perilaku tanpa bisa melihat apa yang dilakukannya.
AR Younce

Apakah gambar mini dirujuk dalam CSS atau dalam tag <img>?
AR Younce

Apa yang Anda maksud dengan direferensikan dalam css? mereka berada di samping html tubuh dan sebagai berikut: <img src="thumbprocessor.php?src=/folder/image.jpg&w=100&h=200" id="thumbnail"/>
Sam

1

Mayoritas masalah lambat adalah TTFB Anda (Waktu ke byte pertama) terlalu tinggi. Ini adalah hal yang sulit untuk diatasi tanpa menjadi akrab dengan file konfigurasi server Anda, kode dan perangkat keras yang mendasarinya, tetapi saya bisa melihat itu merajalela pada setiap permintaan. Anda mendapat terlalu banyak bilah hijau (buruk) dan sangat sedikit bilah biru (bagus). Anda mungkin ingin berhenti sedikit mengoptimalkan frontend, karena saya yakin Anda telah melakukan banyak hal di area itu. Meskipun ada pepatah yang mengatakan bahwa " 80% -90% dari waktu respons pengguna akhir dihabiskan di frontend ", saya yakin milik Anda terjadi di backend.

TTFB adalah barang backend, barang server, pra-pemrosesan sebelum output dan handshaking.

Atur waktu eksekusi kode Anda untuk menemukan hal-hal yang lambat seperti permintaan basis data yang lambat, waktu memasukkan dan keluar dari fungsi / metode untuk menemukan fungsi yang lambat. Jika Anda menggunakan php, coba Firephp . Kadang-kadang itu adalah satu atau dua permintaan lambat dijalankan selama startup atau inisialisasi seperti menarik info sesi atau memeriksa otentikasi dan apa yang tidak. Mengoptimalkan kueri dapat menyebabkan beberapa peningkatan kinerja yang baik. Terkadang kode dijalankan menggunakan php prepend atau spl autoload sehingga mereka berjalan pada segalanya. Di lain waktu, konfigurasi ap dan konfigurasi apache yang mal dapat disimpan yang menghemat waktu.

Cari loop yang tidak efisien. Cari panggilan cache yang lambat atau operasi i / o lambat yang disebabkan oleh drive disk yang salah atau penggunaan ruang disk yang tinggi. Cari penggunaan memori dan apa yang digunakan dan di mana. Jalankan pengujian berulang 10 kali pada webpagetest pada satu gambar atau file menggunakan hanya tampilan pertama dari berbagai lokasi di seluruh dunia dan bukan pada lokasi yang sama. Dan baca akses dan log kesalahan Anda, terlalu banyak pengembang mengabaikannya dan hanya mengandalkan kesalahan pada layar yang dihasilkan. Jika host web Anda memiliki dukungan, minta bantuan mereka, jika mereka tidak meminta bantuan dengan sopan, itu tidak akan merugikan.

Anda dapat mencoba DNS Prefetching untuk memerangi banyak domain dan sumber daya, http://html5boilerplate.com/docs/DNS-Prefetching/

Apakah server Anda sendiri server yang bagus / layak? Terkadang server yang lebih baik dapat memecahkan banyak masalah. Saya seorang penggemar dari ' hardware itu murah, mentalitas programmer mahal ', jika Anda punya kesempatan dan uang upgrade server. Dan / Atau gunakan CDN seperti maxcdn atau cloudflare atau serupa.

Semoga berhasil!

(ps saya tidak bekerja untuk salah satu dari perusahaan-perusahaan ini. Juga tautan cloudflare di atas akan berpendapat bahwa TTFB tidak begitu penting, saya melemparkannya ke sana sehingga Anda bisa mendapatkan kesempatan lain.)


Dear Anthony, terima kasih banyak atas pengetahuan "latar belakang" yang berwawasan luas ini. Saya setuju bahwa kadang-kadang perangkat keras adalah hambatan dan yang kurang jelas untuk diukur terutama ketika perusahaan hosting menjadi hosting bagian server dalam lingkungan hosting bersama. Saya pikir cloudflare adalah pilihan yang baik untuk mencoba dalam kombinasi dengan optimasi konfigurasi apache. Salam pembuka!
Sam

-1

Maaf untuk mengatakan, Anda menyediakan beberapa data. Dan Anda sudah memiliki beberapa saran bagus.

Bagaimana Anda menyajikan gambar-gambar itu? Jika Anda streaming itu melalui PHP, Anda melakukan hal yang sangat buruk, bahkan jika itu sudah dihasilkan.

GAMBAR TIDAK PERNAH STREAM DENGAN PHP. Ini akan memperlambat server Anda, tidak peduli bagaimana Anda menggunakannya.

Tempatkan mereka di folder yang dapat diakses, dengan URI yang bermakna. Kemudian panggil mereka langsung dengan URI mereka yang sebenarnya. Jika Anda membutuhkan pembuatan fly, Anda harus meletakkan .htaccess di direktori gambar yang dialihkan ke skrip php generator hanya jika gambar permintaan tidak ada. (ini disebut strategi cache-on-request).

Melakukan hal itu akan memperbaiki sesi php, browser-proxy, caching, ETAGS, apa pun sekaligus.

WP-Supercache menggunakan strategi ini, jika dikonfigurasi dengan benar.

Saya menulis ini beberapa waktu yang lalu ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), revisi terakhir rusak, tetapi saya kira 8 atau kurang seharusnya berfungsi dan Anda dapat ambil .htaccess sebagai contoh hanya untuk menguji berbagai hal (walaupun ada cara yang lebih baik untuk mengkonfigurasi .htaccess daripada cara saya dulu).

Saya menggambarkan strategi itu dalam posting blog ini ( http://www.stefanoforenza.com/need-for-cache/ ). Mungkin ditulis dengan buruk tetapi dapat membantu memperjelas segalanya.

Bacaan lebih lanjut: http://meta.wikimedia.org/wiki/404_handler_caching


Pikiran, ErrorDocument sebenarnya bukan hal terbaik yang dapat Anda lakukan, karena menghasilkan entri dalam log kesalahan apache, pengalihan -f akan lebih baik.
tacone

Terima kasih atas masukan masukan Anda. Apakah Anda mengatakan bahwa tidak peduli seberapa bagus skrip php, itu akan memperlambat server, atau seperti yang Anda katakan dalam posting Anda "Ini akan membunuh server Anda, tidak peduli apa."
Sam

itu akan memperlambat server tidak peduli seberapa bagus skripnya. Untuk setiap gambar server harus memuat php dan minta aliran gambar byte-per-byte. Biarkan apache melakukan pekerjaan itu tanpa melewati penerjemah php. Sebagai akibatnya, banyak kemungkinan kesalahan lain akan secara otomatis dihindari, seperti sesi, konten-panjang, caching, pantomim / ketik dll. KETIKA kinerja sangat penting Anda bahkan tidak harus memuat php (tetapi pada generasi-waktu).
tacone

Vote downers, bisakah Anda menjelaskan alasannya?
tacone
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.