Tim CDRX dengan senang hati menyambut Anda dengan artikel (Medium) yang baru saja dirilis dari blog mereka.
"Blog: Di dalam pikiran pengembang latensi rendah (Bagian 1)"Hari ini CTO kami memberikan wawasan tentang pikiran pengembang latensi rendahDi sini, di CDRX kami meningkatkan untuk meluncurkan Bursa crypto di Q1 2019 (dengan beta tertutup dimulai pada Q4 2018). Baca lebih lanjut tentang itu dan pendekatan unik kami untuk token yang dapat diakses di
sini.
Mengembangkan platform semacam ini adalah wujud dasar dan merupakan sesuatu yang kami punya dalam banyak pengalaman. Bagi saya pribadi, karena menghabiskan sebagian besar karir saya di salah satu pasar tercepat yakni FX antar bank.
Setiap programmer rata-rata dapat mengembangkan bursa, tetapi seperti yang telah kita lihat dengan pasar Ekuitas dan FX, ada saatnya ketika bahkan inefisiensi yang kecil diperbesar. Masalah-masalah ini menjadi berbahaya bagi mesin perdagangan pada kotak hitam klien yang memiliki frekuensi tinggi. Pada akhirnya sistem yang ditulis dengan buruk akan berakhir dengan mengubah kesuksesan yang mengelembung ke dalam jebakan uang. itu terjadi ketika pasar mengurangi latensi dan peningkatan kecanggihan.
Menariknya pola pikir untuk mengembangkan platform dengan karakteristik kinerja yang diperlukan tidak dididik oleh Tier 1 yang kami kerjakan dibank, tetapi didorong oleh persaingan sengit antara banyak organisasi menjadi yang tercepat. Sangat jarang bahwa (misalnya) Anda akan memiliki pemimpin senior yang memberi tahu Anda untuk menggunakan strategi cache tertentu; sebaliknya mereka hanya tahu bahwa yang tercepat adalah yang terbaik dan teraman. Terserah kepada pengembang dan insinyur untuk mencapai hal ini.
Jika Anda mengesampingkan kontroversi-kontroversi tersebut, misalnya keberhasilan besar yang dicapai tim balap Inggris selama 15 tahun terakhir atau lebih tidak mengejutkan. Pada tahun 2004 hanya Chris Hoy dan Bradley Wiggins memenangkan emas dan pada tahun 2005 tidak ada pembalap Inggris di Tour de France. Pada musim panas 2018 mereka telah mengumpulkan 22 medali emas Olimpiade dan 6 dari 7 kemenangan terakhir Tour de France.
Anda mungkin bertanya-tanya ke mana saya pergi dengan ini, tetapi bertahanlah dengan saya.
Ada banyak faktor yang berkontribusi terhadap keberhasilan bersepeda Inggris, tetapi tampaknya selalu kembali ke prinsip 'keuntungan marjin' mereka ... pandai menyetel setiap aspek yang mungkin dari pendekatan mereka untuk mencapai perbaikan kecil yang dicapai secara keseluruhan yang memenangkan tambahan 1% kinerja.
Keuntungan marjinMari kita membedah ini:
Margin - Kecil dan tidak penting
Keuntungan - Mendapatkan atau dapatkan sesuatu yang berharga
Kata-kata ini tampaknya bertentangan satu sama lain, tetapi ini benar-benar tentang membuat perubahan yang tidak penting untuk menambah sesuatu yang berharga. Dalam olahraga, di mana Anda bisa menang dengan seperseribu detik, itu akan mengejutkan sebab itu belum pernah dilakukan sebelumnya.
Yang juga mengejutkan adalah betapa sedikit orang yang benar-benar mengejar “perolehan signifikan” di bidang pilihan mereka apalagi dengan marjin. Namun keduanya akan terbayarkan ketika datang ke pengembangan.
Jadi ... Bagaimana kita bisa menerapkan ini untuk pengembangan itu?Saya sudah memilih beberapa topik untuk dibicarakan. Ini mungkin sangat jelas sehingga Anda bertanya-tanya mengapa saya menyebutkannya, tetapi sekali lagi, hanya karena mereka melihat secara tidak jelas berarti orang akan secara otomatis melakukannya. Komputer telah menjadi begitu kuat hari-hari ini sehingga jenis optimisasi ini hanya diperlukan dalam skenario yang ekstrim atau sangat sensitif.
Peringatan: jelas banyak hal yang mempengaruhi pembandingan dan contoh di bawah ini menggunakan Java, sehingga compiler JIT juga dapat campur tangan dengan tipu daya licik juga, tetapi nilainya sangat berbeda sehingga masih mendapatkan intinya.
Pikirkan baik-baik tentang struktur data AndaSaya tidak dapat menghitung berapa kali saya melihat array atau map disalahgunakan. Berulang-ulang di atas map adalah contoh yang bagus.
Skenario: Dengan asumsi Anda sudah memiliki array dan HashMap angka acak, masing-masing diisi secara berurutan oleh indeks atau oleh kunci Bilangan bulat yang setara (masing-masing)
// A) Looping over an array
for (int i = 0; i < size; i++) {
total += array[i];
}
// B) iterating over a HashMap
for (Long value : hashmap.values()) {
total2 += value;
}
// output totals to avoid JIT eliminating the need to run the loops
System.out.println(“output1=” + total);
System.out.println(“output2=” + total2);
Untuk catatan 10m ini membutuhkan ~ 40–45ms untuk array, tetapi ~ 130–135ms untuk HashMap.
"Jadi apa?" Anda mungkin bertanya. Di sebagian besar aplikasi, peningkatan ini tidak akan sebanding dengan upaya untuk mengubahnya. Jarang sekali Anda berurusan dengan volume catatan semacam ini dan jika Anda, sebagian besar pengguna akhir bahkan tidak akan merasakan jeda ~ 90ms.
Namun, saat Anda memperkenalkan ribuan pengguna dan melempar beberapa klien agresif pada api (yang telah menyetel kode mereka sebanyak mungkin) ke dalam campuran ini merupakan jenis penundaan yang mulai menghabiskan biaya uang Anda.
Minimalkan LoncatanMembagi aplikasi Anda menjadi komponen-komponen kecil bisa sangat berharga. Ini dapat menyederhanakan pengujian, pemeliharaan, keandalan, dan jika dilakukan dengan benar secara skalabilitas platform. Sayangnya itu memiliki efek yang merugikan pada latensi. Per (1) ini adalah penundaan yang mungkin tidak dapat dilihat oleh pengguna akhir, tetapi menambahkan lubang pada jaringan dan sentralisasi dan desentralisasi yang terkait dapat meningkatkan latensi keseluruhan secara signifikan.
Skenario: membandingkan penggabungan string ke dirinya sendiri (menggunakan Java seperti contoh ini)
1. Serialising dan deserialising string sebelum melampirkan
2. Lampiran Sederhana
//create a trivial object as the input to the test
String testString = “Hello World”;
//initialising google’s JSON serialiser/deserialiser
Gson gson = new GsonBuilder().setPrettyPrinting().create();
StringBuilder buf = new StringBuilder();
long start = System.currentTimeMillis();
for (int i = 0; i < size; i++) {
// TEST1: serialise/deserialise string then append to the buffer
buf.append(gson.fromJson(gson.toJson(testString), String.class));
}
System.out.println(“time=” +(System.currentTimeMillis()-start));
StringBuilder buf2 = new StringBuilder();
long start2 = System.currentTimeMillis();
for (int i = 0; i < size; i++) {
// TEST 2: simply append the test string to the buffer
buf2.append(testString);
}
System.out.println(“time=”+(System.currentTimeMillis()-start2));
// to force JIT not to optimise the loops above out of existence
// the substring avoids messing overloading the console
System.out.println(“output 1=” + buf.substring(5000, 5005));
System.out.println(“output 2=” + buf2.substring(5000, 5005));
Jika saya menjalankan kode di atas untuk catatan 1m, saya mendapatkan ~ 1050ms untuk TEST1 dan ~ 35ms untuk TEST2. Ini adalah perbedaan yang mengejutkan dan hanya sebagian dari cerita karena jelas tidak mempertimbangkan jaringan atau bahkan perangkat lunak apa pun di luar JVM.
Sekarang, sepertinya saya memperdebatkan kasus untuk aplikasi monolitik dalam lingkungan latensi rendah, tetapi saya sebenarnya menyarankan pendekatan terukur untuk memutuskan apakah, kapan, dan bagaimana membagi aplikasi. Jika itu untuk alasan yang bagus, seperti skalabilitas, maka latensi tambahan mungkin sebanding dengan biaya overhead.
Pikirkan tentang protokol AndaSaya harus membuat pengakuan. Jangan membenci saya, tetapi saya benar-benar bukan penggemar "REST" (jeda). Ya, yang sangat sederhana untuk dikodekan dan dihadapinya tampaknya cukup cepat, tetapi REST memerlukan penanganan header HTTP pada setiap permintaan, yang jelas tidak diperlukan untuk protokol komunikasi yang memiliki soket terbuka.
Orang lain telah melakukan analisis mendalam mengenai hal ini (
di sini misalnya) dan kesimpulannya jelas: bahkan 100 pesan dapat mengambil alih 5 kali lebih lama untuk diproses dengan REST daripada dengan websockets.
Sekali lagi, dibutuhkan skala yang signifikan sebelum efeknya terlihat oleh pengguna akhir. tetapi ketika Anda menskalakannya hingga ribuan pesan dan menempatkannya dalam skenario ekstrim (seperti bursa) ini dapat membuat atau menghancurkan untuk bisnis. Jangan lupa saya fokus pada keuntungan margin di sini!
Wrapping up / MembungkusDengan mencapai 'keuntungan marjinal' secara konsisten, CDRX berusaha menjadi pengubah permainan untuk pertukaran kripto. Lebih cepat, lebih stabil, dan lebih banyak kelas perusahaan daripada penawaran lainnya di luar sana. Untungnya kami telah bermitra dengan beberapa pebisnis yang sangat cerdas sehingga kami memiliki banyak kedudukan bisnis baru yang akan kami kembangkan juga. Saat-saat yang menyenangkan di depan!
Silakan kembali untuk update bagian 2 ...
Bergabunglah dengan Kami Di Telegram:
https://t.me/cdrxchange