Pemahaman tentang penyemaian file back end untuk menyediakan pengunduhan klien yang cepat

Tema proyek saya adalah mengimplementasikan server terdistribusi yang menyediakan beberapa klien beberapa file untuk diunduh. Server menghosting beberapa file dan kami ingin server menerapkan beberapa algoritme terbaik agar klien dapat mengunduh data darinya dengan cepat.

Ide saya tentang implementasi proyek:

Seperti klien pada umumnya mengunduh file menggunakan beberapa pengelola unduhan, demikian pula harus ada beberapa manajer/kode/algoritma sisi server yang mengunggah/menyemai file dengan cepat agar klien dapat mengunduh file. Tidak boleh ada tindakan apa pun dari klien kecuali pemilihan file yang akan diunduh!

Bagaimana cara saya menulis kode untuk server seperti itu di bagian belakang, serupa dengan pengelola unduhan berbasis multi-threading untuk klien di bagian depan?

Bagaimana seharusnya server menyemai/membuat file tersedia ke klien jika klien hanya mengirimkan jalur sebagai String ke server di Java untuk diunduh?

Atau, jika saya melewatkan sesuatu/ide saya salah total, mohon pencerahannya dengan proses/algoritma alternatif yang harus saya terapkan di sisi server. Harap diingat bahwa seluruh tujuan menanyakan pertanyaan ini adalah algoritma penyemaian server ujung belakang ATAU algoritma/metode yang setara.


download java backend file-upload client-server
person Am_I_Helpful    schedule 28.10.2014    source sumber

Jawaban (1)


arrow_upward
2
arrow_downward

Saya berasumsi, server Anda ini memiliki koneksi internet yang bagus dengan upstream yang luas. Jika demikian halnya maka faktor pembatas ketika hanya sedikit klien yang mengunduh sedikit file adalah bandwidth klien tersebut. Jadi, paling banyak Anda akan mendapatkan kecepatan yang sama dengan bandwidth hilir klien Anda. Jadi, hanya menggunakan perpustakaan server HTTP yang tersedia untuk melayani unduhan saja sudah cukup.

Di mana penerapan backend Anda sangat penting dan mampu meningkatkan kinerja pengunduhan, maka banyak pengguna yang terhubung ke server Anda dan mengunduh banyak file. Pertama, ada beberapa hal berikut yang perlu dipertimbangkan:

  • TCP memiliki waktu startup. Saat pertama kali membuka koneksi, kecepatan pengunduhan perlahan mulai meningkat hingga mencapai maksimum. Untuk meminimalkan waktu ini, saat mengunduh banyak file, koneksi yang dibuka untuk satu unduhan file harus digunakan kembali untuk file berikutnya.

  • Mengunduh banyak file sekaligus (di sisi klien) tidak masuk akal ketika bandwidth adalah faktor pembatas, karena klien harus memulai banyak koneksi TCP dan data akan terfragmentasi, ketika ditulis ke Disk, atau (ketika mengalokasikan sebelumnya) disk akan sangat sibuk saat berpindah antar sektor.

  • Server Anda secara umum harus menggunakan pustaka IO yang tidak memblokir (mis. java.nio) dan jangan membuat thread per koneksi masuk karena ini akan mengakibatkan thrashing yang lagi-lagi menurunkan kinerja server Anda secara drastis.

Jika Anda memiliki sejumlah besar klien yang mengunduh secara bersamaan dari server Anda, batas yang mungkin Anda capai adalah:

  • Batas upstream penyedia Anda

  • Kecepatan baca Harddisk Anda (SSD memiliki ~ 500MB/s sejauh yang saya informasikan)

Server Anda dapat mencoba menyimpan berkas yang paling sering diminta dalam memorinya dan menyajikan konten dari sana (RAM DDR3 mencapai kecepatan sebesar 17 GB/dtk). Saya ragu Anda hanya memiliki sedikit file di server Anda sehingga Anda dapat menyimpan semuanya dalam cache di RAM server Anda.

Jadi tugas teknis utama terletak pada pemilihan cerdas konten mana yang harus di-cache dan mana yang tidak. Hal ini dapat dilakukan berdasarkan prioritas dengan menetapkan prioritas yang lebih tinggi pada file tertentu atau dengan metrik yang mengkodekan kemungkinan satu file untuk diunduh dalam beberapa menit berikutnya. Atau sekadar file yang paling banyak diunduh oleh klien saat ini.

Dengan pertimbangan seperti itu Anda dapat mendorong batas server unduhan Anda hingga titik tertentu di mana satu-satunya perbaikan dapat dicapai dengan mendistribusikan atau mereplikasi file Anda ke banyak server.

Jika Anda ingin melayani jutaan klien secara bersamaan harus dimungkinkan, Anda harus mempertimbangkan untuk membeli layanan semacam itu dari CDN. Mereka berspesialisasi dalam pengiriman cepat dan memiliki banyak server upstream di sebagian besar AS sehingga setiap klien dapat mengunduh filenya dari server CDN regional.

Saya tahu, saya belum memberikan contoh algoritma atau kode apa pun, tetapi saya tidak bermaksud menjawab pertanyaan ini sepenuhnya. Saya hanya ingin memberi Anda beberapa pedoman dan pemikiran penting tentang topik itu. Saya harap, Anda setidaknya dapat menggunakan beberapa pemikiran ini untuk proyek Anda.

person lSoleyl    schedule 08.11.2014
comment
Silakan periksa ini dan balas---mailinator.blogspot.in/2008/02/ . Jika puas, saya akan memberi suara positif pada jawaban Anda, dan kemudian memberi hadiah kepada Anda! - person Am_I_Helpful; 09.11.2014
comment
Saya tidak begitu yakin dengan hasil mereka. Saya percaya bahwa mereka benar-benar telah mengukur hasil-hasil ini dan tidak dibuat-buat. Namun pemrograman dengan NIO jauh lebih kompleks dibandingkan menggunakan pemblokiran vanilla IO. Karena saya tidak memiliki pengetahuan tentang kode mereka, saya tidak dapat memverifikasi bahwa tes ini adil. Hal kedua yang menyengat saya adalah mereka melakukan pengukuran hanya untuk 1.700 koneksi bersamaan. Saya cukup yakin, pemblokiran IO akan menimbulkan masalah ketika naik lebih jauh dan akan naik lebih jauh (komentar berikutnya) - person lSoleyl; 09.11.2014
comment
Jadi, menurut Anda, 1.700 koneksi bersamaan tidak meyakinkan? Saya bersama mereka karena tampaknya cukup sah dan tidak ada yang akan mencoba koneksi lebih banyak! - person Am_I_Helpful; 09.11.2014
comment
Pengaturannya cukup mudah untuk menunjukkan seberapa baik IO mengungguli NIO dengan membatasi koneksi bersamaan hingga 1700 dan hanya mengukur throughput. Namun dalam kasus Anda, jika banyak klien akan mengunduh file secara bersamaan dan file ini mungkin berukuran besar, maka setiap koneksi akan terbuka untuk waktu yang lama. Seperti yang saya katakan, saya tidak tahu klien apa yang Anda layani, tetapi rata-rata pengguna internet memiliki batas bandwidth yang cukup kasar dan throughput tidak boleh menjadi perhatian utama Anda. Sebaliknya Anda harus melayani ribuan koneksi terbuka (lambat) secara bersamaan dan banyaknya thread ini berdampak pada kinerja server... - person lSoleyl; 09.11.2014
comment
@shekharsuman mengenai komentar Anda: Meyakinkan untuk nomor itu. Saya tidak suka pernyataan umum yang memblokir IO lebih baik daripada NIO yang dihasilkan dari satu pengaturan tertentu. Jika Anda bertujuan untuk menyediakan server yang fokusnya bukan melayani ribuan klien secara bersamaan, maka memblokir IO akan baik-baik saja dalam kasus Anda. - person lSoleyl; 09.11.2014
comment
Terima kasih, izinkan saya mencoba saran Anda. Penghargaan Anda sedang menunggu Anda! - person Am_I_Helpful; 13.11.2014
comment
Mungkin juga menarik bagi Anda: Saya menemukan karya ilmiah dari tahun 2011, yang menunjukkan caranya aplikasi NodeJS non-pemblokiran mengungguli aplikasi Java dan Scala dengan throughput pesan tujuh kali lebih tinggi. - person lSoleyl; 17.11.2014