Saya salah berasumsi bahwa pengujian AB internal saya berarti server saya dapat menangani 1k concurrency @ 3k hits per detik.

Teori saya saat ini adalah bahwa jaringannya adalah hambatan. Server tidak dapat mengirim data dengan cukup cepat.

Pengujian eksternal dari blitz.io pada konkursi 1k menunjukkan hit / s saya berhenti pada 180, dengan halaman yang lebih lama dan lebih lama untuk merespons karena server hanya dapat mengembalikan 180 per detik.

Saya telah menyajikan file kosong dari nginx dan mencadangkannya: ini menskala 1: 1 dengan concurrency.

Sekarang untuk mengesampingkan kemacetan IO / memcached (nginx biasanya menarik dari memcached), saya menyajikan versi statis dari halaman yang di-cache dari sistem file.

Hasilnya sangat mirip dengan tes asli saya; Saya dibatasi sekitar 180 RPS.

Membagi halaman HTML menjadi dua membuat saya menggandakan RPS, jadi pasti dibatasi oleh ukuran halaman.

Jika saya secara internal ApacheBench dari server lokal, saya mendapatkan hasil yang konsisten dari sekitar 4k RPS pada Halaman Penuh dan Halaman Setengah, dengan kecepatan transfer tinggi. Kecepatan transfer: 62586,14 [Kbytes / detik] diterima

Jika saya AB dari server eksternal, saya mendapatkan sekitar 180RPS - sama dengan hasil blitz.io.

Bagaimana saya tahu itu bukan pelambatan yang disengaja?

Jika saya melakukan tolok ukur dari beberapa server eksternal, semua hasil menjadi buruk yang membuat saya percaya bahwa masalahnya ada pada lalu lintas keluar server MY, bukan masalah kecepatan unduhan dengan server pembandingan saya / blitz.io.

Jadi saya kembali ke kesimpulan saya bahwa server saya tidak dapat mengirim data dengan cukup cepat.

Apakah saya benar? Apakah ada cara lain untuk menginterpretasikan data ini? Apakah solusi / pengoptimalan untuk mengatur beberapa server + load balancing yang masing-masing dapat melayani 180 hit per detik?

Saya cukup baru dalam pengoptimalan server, jadi saya menghargai konfirmasi yang menafsirkan data ini.

Lalu lintas keluar

Berikut informasi lebih lanjut tentang bandwidth keluar: Grafik jaringan menunjukkan output maksimum 16 Mb / s: 16 megabit per detik. Sama sekali tidak terdengar.

Karena saran tentang pelambatan, saya melihat ke dalam ini dan menemukan bahwa linode memiliki batas 50mbps (yang saya bahkan tidak dekat dengan memukul, rupanya). Saya memilikinya dinaikkan menjadi 100mbps.

Karena linode membatasi traffic saya, dan saya bahkan tidak memukulnya, apakah ini berarti server saya memang harus mampu menghasilkan hingga 100mbps tetapi dibatasi oleh beberapa hambatan internal lainnya? Saya hanya tidak mengerti bagaimana jaringan pada skala besar ini bekerja; dapatkah mereka benar-benar mengirim data secepat mereka dapat membaca dari HDD? Apakah pipa jaringan itu besar?

Kesimpulannya

1: Berdasarkan hal di atas, saya pikir saya pasti dapat meningkatkan 180RPS saya dengan menambahkan penyeimbang beban nginx di atas pengaturan server multi-nginx tepat 180RPS per server di belakang LB.

2: Jika linode memiliki batas 50 / 100mbit yang tidak saya pukul sama sekali, pasti ada sesuatu yang bisa saya lakukan untuk mencapai batas itu dengan pengaturan server tunggal saya. Jika saya dapat membaca / mengirimkan data secara lokal dengan cepat, dan bahkan tidak perlu memiliki cap 50mbit / 100mbit, pasti ada hambatan internal yang tidak memungkinkan saya mengenai batasan yang saya tidak yakin cara mendeteksi. Benar?

Saya menyadari bahwa pertanyaannya sangat besar dan tidak jelas sekarang, tetapi saya tidak yakin bagaimana memadatkannya. Masukan apa pun dihargai atas kesimpulan yang saya buat.

Masalahnya adalah saya berasumsi bahwa puncak grafik linode.com adalah puncak sejati. Ternyata grafiknya menggunakan titik data rata-rata 5 menit, jadi puncak saya tampak 24mbits padahal sebenarnya saya menekan tutup 50mbit.

Sekarang mereka telah menaikkannya menjadi 100mbits, tolok ukur saya segera naik ke batas lalu lintas keluar yang baru.

Kalau saja saya telah memperhatikan itu sebelumnya! Banyak alasan saya bergantung pada gagasan bahwa saya tidak mencapai batas lalu lintas keluar karena grafik itu.

Sekarang, saya memuncak pada 370 permintaan per detik, yang tepat di bawah 100mbps pada titik mana saya mulai mendapatkan "simpanan" permintaan, dan waktu respons mulai naik.

Sekarang saya dapat meningkatkan konkurensi maksimum dengan mengecilkan halaman; dengan gzip diaktifkan, saya mendapatkan 600RPS.

Saya masih mengalami masalah ketika tiba-tiba saya memuncak dan tumpukan permintaan yang tertunda (dibatasi oleh bandwidth) mulai menumpuk, tetapi itu terdengar seperti pertanyaan yang berbeda.

Sudah menjadi pelajaran besar dalam optimasi / membaca data ini / mempersempit kemungkinan masalah. Terima kasih banyak atas masukan Anda!

Agak terlambat sekarang setelah Anda mengetahuinya ... tapi mungkin Anda harus mempertimbangkan untuk membaca blog ServerFault dari waktu ke waktu.

Saya sedang memikirkan khususnya tentang posting ini , di mana mereka membahas mengapa memiliki jajak pendapat satu detik tidak memotongnya dari waktu ke waktu, terkait dengan masalah yang sangat mirip dengan yang Anda miliki ..

Kami menemukan bahwa kami sering membuang paket pada antarmuka 1 Gbit / s dengan kecepatan hanya 10-30 MBit / s yang mengganggu kinerja kami. Ini karena laju 10-30 MBit / s sebenarnya jumlah bit yang ditransfer per 5 menit yang dikonversi menjadi laju satu detik. Ketika kami menggali lebih dekat dengan Wireshark dan menggunakan grafik IO satu milidetik, kami melihat bahwa kami sering meledakkan tingkat 1 Mbit per milidetik dari yang disebut antarmuka 1 Gbit / s.

Tentu membuatku berpikir. Dan saya hanya tahu bahwa saya berusaha keras mengalahkan yang satu di SA lainnya di toko saya pada kesempatan pertama, dan akan terlihat sangat cerdas dan tanggap ketika kita menghadapi masalah ini.

Siapa tahu, saya bahkan mungkin membiarkan beberapa dari mereka secara rahasia. :)

Mungkin dibatasi oleh jaringan, tetapi tidak harus hanya masalah bandwidth. Latensi unit uji jarak jauh Anda akan berdampak pada jumlah koneksi yang tertunda pada waktu tertentu (menunggu 50 ms untuk pengakuan jauh berbeda dari 0,5 ms secara lokal) juga pada negosiasi dan stabilisasi ukuran jendela saat koneksi berlangsung. Anda juga mungkin akan terkena sejumlah kerugian paket - baik sebagai fungsi kemacetan atau sebagai mekanisme pembatasan bandwidth di pihak operator Anda (atau yang upstream).

Saya sarankan menghilangkan sebanyak mungkin dari persamaan untuk menggambar garis dasar yang masuk akal. Ukur bandwidth puncak, latensi, dan paket loss dari server Anda ke beberapa poin di Internet umum. Meskipun kedengarannya tidak mungkin, coba cari "Voip traffic test" atau yang serupa. Beberapa penyedia layanan VOIP memiliki aplikasi yang dapat mengukur pola semacam ini (dua arah) dengan tingkat akurasi yang adil. Setelah Anda memiliki beberapa data empiris yang valid mengenai kecepatan tautan yang sebenarnya berguna, maka hasil Anda mungkin akan divalidasi.

Selain tes bandwidth, mungkin juga berguna untuk melihat tangkapan paket dari lalu lintas web sub-par untuk mencari jumlah transmisi ulang yang berlebihan serta mengukur waktu yang tampak jelas yang diambil server Anda untuk menanggapi permintaan (..jika ini nilai meningkat secara substansial sebagai fungsi dari jumlah koneksi, ini adalah petunjuk besar).