Halo. Nama saya Stas, di Domclick saya mengawasi pengembangan layanan back office untuk pinjaman hipotek di Sberbank.
Akhir-akhir ini, di berbagai reportase dan podcast, saya sering menemukan istilah "Green Code". Setelah mencari-cari di Internet dan mempelajari topik ini, saya menyadari bahwa istilah ini menggambarkan sekumpulan teknik dalam pengembangan dan desain aplikasi yang dapat mengurangi konsumsi daya peralatan tempat kode ini dijalankan.
Sedikit banyak pertanyaan ini biasanya dibuat bingung oleh pengembang aplikasi seluler, terutama karena perangkat yang akan menjalankan kodenya memiliki kapasitas baterai yang terbatas.
Topik ini telah menjadi sangat "hype", dan saya memutuskan untuk mencari tahu bagaimana sebenarnya prinsip "hijau" dapat tercermin dalam pengembangan WEB.
Prinsip dasar penulisan "kode hijau"
Setelah membaca banyak laporan dan artikel tentang topik ini, saya akan menyoroti aspek pengembangan aplikasi berikut yang memengaruhi konsumsi daya:
1) Penyederhanaan dan optimalisasi algoritma
Seperti disebutkan di atas, eksekusi kode harus menghasilkan konsumsi energi yang minimal. Kode yang dioptimalkan akan berjalan lebih cepat dan, oleh karena itu, akan membutuhkan lebih sedikit biaya pemrosesan dan pendinginan peralatan.
Mari kita coba menghitung perbedaan konsumsi energi untuk menjalankan operasi tertentu dalam kode - penyortiran klasik dari daftar. Saya dengan sengaja akan membesar-besarkan situasi dalam contoh yang diberikan untuk menunjukkan perbedaan kontras.
Mari kita ambil jenis gelembung. Ini mungkin salah satu cara yang paling sub-optimal. Sangat cocok untuk kami. Mari kita hitung pengurutan daftar dan lihat bagaimana pengaruhnya terhadap konsumsi daya MacBook. Pertama, mari kita simulasikan larik data dan logika bubble sort itu sendiri:
from random import randint
def bubble(array):
for i in range(productNumber-1):
for j in range(productNumber-i-1):
if array[j] > array[j+1]:
buff = array[j]
array[j] = array[j+1]
array[j+1] = buff
productNumber = 60000
products = []
for i in range(productNumber):
products.append(randint(1, 1000))
bubble(products)
print(products)
Untuk mengukur dampak eksekusi kode pada konsumsi energi, saya menggunakan sistem pemantauan iStat Menus 6 (https://bjango.com/mac/istatmenus/). Saya menghubungkan MacBook saya ke jaringan, menutup semua aplikasi pihak ketiga, menunggu waktu tertentu untuk mengisi daya baterai, dan mulai menyortir:
Grafik
konsumsi daya saat melakukan bubble sort: Terlihat lonjakan konsumsi daya yang berlangsung selama 305 detik. Itu disebabkan oleh eksekusi permintaan kami yang tidak optimal. Selain itu, energi yang dikeluarkan selama 5 menit (305 detik)
P = (W2 – W1) × 305 = (17,29 [ ] – 2,9 [ ]) × 305 = 14,39 × 305 = 4389 = 0,0012 * .
Sekarang katakanlah kode ini secara tidak sengaja masuk ke server produk industri (anggap saja konsumsi daya tambahan di server akan sama seperti di MacBook saya, dan ketergantungannya berbanding lurus) dan mulai dijalankan dengan frekuensi 1 setiap 10 detik. Kemudian tahun kita mendapatkan lebih banyak energi:
365 × 24 × 3600 /10 × 0,0012 * = 3 784,32 *.
Misalkan pusat data yang menghosting server menerima daya dari ruang ketel yang menggunakan kayu birch sebagai bahan bakar. Saat membakar 1 m 3 kayu birch, energi 1900 kW * h / m 3 dilepaskan. Tentu saja, efisiensi boiler tidak 100%, dan jika kita mengambil untuk 75%, kita mendapatkan: . Jika kita mengambil pohon sebagai silinder biasa, volumenya adalah
(3 784,32 / 1900) / 0,75 = 2,66 3
V = Pi × R2 × H
dimana R adalah jari-jari batang pohon, anggaplah 0,12 meter (nilai rata-rata),
H adalah tinggi batang pohon, anggap saja 3 meter (nilai rata-rata).
lalu kita dapatkan: Ini berarti akan ada kayu dalam satu meter kubik . Untuk memberikan energi agar skrip kami berfungsi, kami membutuhkan waktu satu tahun . Sebagai perbandingan, saya melakukan pengurutan yang sama menggunakan metode pengurutan Python standar ( ). Grafik konsumsi energi saat melakukan pengurutan standar dengan Python: Menerapkan logika kalkulasi yang sama (durasi puncak adalah 10 detik), kita dapatkan: Dalam setahun kita dapatkan (asalkan operasi dilakukan 1 kali dalam 10 detik) Atau:
V = 3,14 × 0,0144 × 3 = 0,14 3
1 / 0,14 = 7,14
2,66 3 × 7,14 = 19
.sort()
P = (W2 – W1) × 10 = (3,51 [ ] – 2,9 [ ]) × 10 = 6,1 = 0,0000016 *
365 × 24 × 3600 /10 × 0,0000016 * = 5,05 *
5,05 / 1900 / 0,75 × 7,14 = 0,025 .
Tentu saja contoh ini memiliki banyak asumsi, dan bubble sort jarang dilakukan. Tetapi angka yang dihasilkan tampak menarik bagi saya
2) Gunakan model aplikasi yang digerakkan oleh peristiwa jika memungkinkan
Intinya adalah bahwa sebagian besar prosesor mendukung berbagai "status" konsumsi daya. Jika kernel tidak sibuk dengan kalkulasi apa pun, sistem operasi akan mengalihkannya ke status "tidur", di mana prosesor menggunakan daya yang jauh lebih sedikit.
Spektrum keadaan (pengoptimalan energi):
Anda dapat membaca lebih lanjut tentang ini di sini .
Cukup sering, ada situasi di mana beberapa logika aplikasi harus dijalankan saat peristiwa tertentu terjadi. Dan untuk mengetahui bahwa peristiwa ini telah terjadi, layanan yang tertarik untuk menerima informasi ini sering melakukan polling secara berkala ke layanan yang menyimpan fakta bahwa peristiwa ini telah selesai. Dengan timer. Selain itu, sebagian besar permintaan menerima jawaban negatif, yaitu 99% permintaan sebenarnya tidak diperlukan.
Adalah benar untuk menyiarkan acara terkait ke antrean dan membaca fakta kemunculannya ke semua layanan yang tertarik.
Spektrum keadaan (pengoptimalan energi):
Contoh lain adalah interaksi komponen aplikasi front-end dan back-end. Jika bagian depan perlu mengubah statusnya bergantung pada data dalam database, terkadang permintaan dikirim secara berkala ke backend, yang membuat beban tambahan yang tidak perlu. Meskipun dimungkinkan untuk menginformasikan ke depan tentang perubahan status data yang diperlukan melalui server soket.
Meskipun soket juga bisa salah, berikut adalah contoh kode "buruk":
while(true)
{
// Read data
result = recv(serverSocket, buffer, bufferLen, 0);
// Handle data
if(result != 0)
{
HandleData(buffer);
}
// Sleep and repeat
Sleep(1000);
}
Dapat dilihat bahwa meskipun tidak ada data yang sampai ke soket, kode akan tetap dijalankan setiap 1000 detik, membuang-buang energi yang berharga.
Hal yang sama dapat ditulis dengan cara yang sedikit berbeda, dan lebih sedikit energi yang akan dihabiskan:
WSANETWORKEVENTS NetworkEvents;
WSAEVENT wsaSocketEvent;
wsaSocketEvent = WSACreateEvent();
WSAEventSelect(serverSocket,
wsaSocketEvent, FD_READ|FD_CLOSE);
while(true)
{
// Wait until data will be available in
the socket
WaitForSingleObject(wsaSocketEve
nt, INFINITE);
// Read data
result = recv(serverSocket, buffer,
bufferLen, 0);
// Handle data
if(result != 0)
{
HandleData(buffer);
}
}
3) UI/UX: «»
Jika data masih digunakan, tetapi jarang, maka lebih baik tidak menampilkannya secara default, tetapi menampilkannya hanya dengan mengklik tombol "Tampilkan informasi rinci".
Contoh sederhana yang menggambarkan prinsip ini: menampilkan daftar objek data (permintaan, pengguna, outlet, gudang, kantor), asalkan skenario penggunaan formulir masih melibatkan pencarian objek yang diinginkan.
Contoh antarmuka yang buruk :
Halaman menampilkan daftar besar tugas (dibagi menjadi "halaman"), tetapi pengguna masih akan mencari klien tertentu (menurut beberapa logika di kepalanya) di bilah pencarian di bagian atas. Mengapa membuang-buang sumber daya untuk mendapatkan daftar tugas?
Skenario yang sama, diterapkan dengan cara berbeda:
Contoh antarmuka "hijau" :
Logika pemilihan klien telah dipindahkan ke sistem; secara default, data yang tidak diperlukan tidak diminta "karena kebiasaan". Pilihan ini, selain pemerhati lingkungan, dan keamanan siber akan mendapat tepuk tangan meriah.
4) Refactoring
Refactoring hampir selalu berguna. Namun dalam konteks ini, diperlukan untuk satu tujuan sederhana: membuang kode (sampah) yang tidak perlu atau untuk menyederhanakan kode yang sudah ada untuk mengurangi konsumsi daya.
Banyak aplikasi yang telah berkembang selama lebih dari tiga tahun mengakumulasi ratusan baris kode yang tidak terpakai atau tidak dapat diprediksi yang tersisa dari fungsi yang diimplementasikan sebelumnya (dan mungkin sudah terpotong). Kadang-kadang kode ini bahkan dijalankan, tetapi hasil kerjanya tidak diklaim.
Pengauditan dan pemfaktoran ulang berkala akan mengurangi jumlah kode tersebut, meskipun mungkin tidak akan menghapusnya sepenuhnya.
Misalnya, secara teratur melakukan refactoring salah satu layanan kami (dalam kuota teknis jam kerja), kami menemukan ini:
Contoh refactoring :
crm_deal_id- pengidentifikasi transaksi hipotek di sistem lama. Sekarang tidak lagi diperlukan, tetapi kode masih memeriksa untuk mendapatkannya dan memanggil fungsi tambahan delete_deal_chat_telephonyyang melakukan banyak tindakan lain.
Semua ini dapat dihapus tanpa kehilangan fungsinya.
5) Gunakan bahasa pemrograman tingkat rendah untuk aplikasi beban tinggi
Jelas, dalam banyak kasus, aplikasi yang ditulis dalam bahasa tingkat rendah lebih hemat energi. Masuk akal untuk menulis ulang layanan yang dimuat dengan Python (jika menjalankan operasi sederhana) di C / C +. Ini akan lebih cepat dan lebih hijau.
Benar, seringkali kita tidak memiliki pengetahuan yang diperlukan untuk menulis logika dalam bahasa seperti itu.
6) Operasi grup I / O
Sistem penyimpanan, seperti prosesor, juga memiliki status daya yang berbeda.
Mode tidur mengkonsumsi energi jauh lebih sedikit daripada mode operasi hangat. Ini terutama berlaku untuk sistem penyimpanan / hard drive.
Jika aplikasi dapat mengelompokkan data yang ditulis ke disk dan mengakses disk tidak terus-menerus, tetapi pada periode waktu tertentu, ini akan lebih hemat energi, karena selama periode "idle", sistem operasi akan mengirim disk ke "hibernasi".
7) Menggunakan sistem penyimpanan yang kurang haus daya untuk log
Merupakan praktik yang baik untuk menggunakan penyimpanan "panas" dan "dingin". Misalnya, masuk akal untuk menyimpan log selama seminggu terakhir dalam bentuk indeks dari masakan "panas", karena kemungkinan mengaksesnya akan cukup tinggi. Log yang lebih panjang dapat disimpan dalam sistem penyimpanan yang lebih murah dan tidak terlalu haus daya.
Bagaimana dengan skala industri?
Di atas, kami membahas teknik dasar untuk bekerja dengan kode untuk memastikan efisiensi energinya. Tetapi bahkan mengikuti sebagian besar aturan ini akan menghasilkan penghematan yang sangat sederhana yang akan sulit untuk divisualisasikan. Tentu saja, jika daftar tersebut tidak diurutkan dengan metode bubble dalam penjualan,
pengembangan fungsionalitas yang disengaja untuk implementasi manajemen dokumen elektronik akan memberikan efek yang jauh lebih besar.
Salah satu aktivitas tim Domclick adalah mengoptimalkan dan mempermudah proses pengurusan KPR. Dan dalam proses KPR ini, pada tahap akhir, banyak dokumen yang disiapkan di atas kertas. Dan dalam beberapa eksemplar. Satu salinan untuk penjual, satu untuk pembeli, satu untuk arsip bank.
Saya senang mengetahui bahwa Domclick menghabiskan banyak upaya untuk menghilangkan praktik kejam ini dan mentransfer seluruh alur dokumen ke format elektronik. Tahun ini, sebagian besar transaksi hipotek telah sepenuhnya didigitalisasi (hanya satu kertas yang dicetak: permohonan penerbitan UKEP, tanda tangan elektronik kriptografi yang disempurnakan). Semua dokumen lain ditandatangani oleh UKEP ini dan tidak ada kertas yang digunakan untuk itu.
Inisiatif ini telah menghemat lebih dari 67.491.108 lembar kertas. Di pohon birch, ada sekitar 23.000 pohon!
Lindungi Lingkungan!
Tautan untuk mereka yang tertarik:
- Green IT - data dan pedoman yang tersedia untuk mengurangi konsumsi energi dalam Sistem TI / Ardito L.; Morisio M… - Dalam: KOMPUTING BERKELANJUTAN. - ISSN 2210-5379. - STAMPA
- Understanding Green Software Development: A conceptual Framework /Luca Ardito, Giuseppe Procaccianti, Marco Torchiano, Antonio Vetro
- Green SW Engineering:Ideas for including Energy Efficiency into your Softwar Projects/Gerald Kaefer