On 2003.10.21_03:09:22_+0000, adi wrote: > wah .. ini agak panjang. bisa dibicarakan di thread baru kalau > mau :-) penjelesan sederhana gini saja, coba lihat patch yang disediakan > matthias. komentar saya: dengan patch ini qmail justru nampak lebih > culun :P pasalnya mail delivery failed bisa terjadi pada fase > sesudah itu, dan patch itu tidak bisa apa-apa :-)) 'scheduler' > pada mailer modular dilakukan oleh agent lain, dengan mencoba > semua MX untuk semua tempfail bisa problematik. bayangkan saja > gini: hotmail punya 10 MX, 1 MX kalau diretry bisa menghabiskan > 10 menitan, kalau 10 MX berarti 100 menit! kalau concurrencyremote > dibatasi 20 dan worst case banyak kirim ke hotmail, maka qmail, > kalau dicoba semua untuk mentaati postulat di atas, bisa menjadi > mailer telo. ingat yang mengatur concurrencyremote adalah qmail-send. > jadi minimal qmail-send harus support semacam preemtive scheduling. > mungkin ada solusinya (bapak-bapak pembuat MTA pasti > lebih tahu) tapi yang jelas tidak dengan one liner patch :-) > perilaku qmail yang sekarang pun sebenarnya masih acceptable.
bukankah mta non-modular juga memiliki masalah yang sama: harus mencoba semua MX, dan akibatnya mengalami delay yang sama? sorry for being dense, tapi saya mulai dapat melihat maksud Anda. qmail tidak mempunyai fasilitas ini bukan karena perilakunya masih acceptable. Posting DS point 3.2. > > qmail menolak DSN karena alasan simplicity, reliability dan security. > > takutnya hanya karena point ini motto qmail menyimpang. patch > > kalo pengen pake fitur ini. bagi yang lain, ketahuilah bahwa code yang > > tidak perlu tidak terdapat dalam qmail, dan tidur dengan lebih nyenyak. > > sepertinya bukan. eh? any URL for reference? > philip haezel, DJB, wietse merasa spec untuk > DSN ini problematik, sehingga enggan untuk mengaplikasikannya. reliablity, security. > setidaknya dapat prioritas yang sangat rendah. lagi pula, > implementasi DSN mensyaratkan *semua* 'hop' yang dilalui harus > support DSN. kira-kira: sudah capek-capek bikin eh .. masih > kagak bisa juga. mendingan kagak usah ditulis sekalian :-) simplicity, reliability. > > dengan mengesampingkan kemudahan instalasi qmail+ezmlm(-idx), terdapat > > banyaknya synchronous writes per mail pada qmail disengajakan untuk > > memberikan reliability yang digaransi oleh qmail. > > hei .. postfix dengan satu file tapi tetap reliabel :-)) > hati-hati menggunakan istilah synchronous write di linux. > kecuali courier-mta, tidak ada satupun MTA yang menerapkan > synchronous write seperti yang dipostulatkan linus (dengan > mount async). courier pun kalau tidak salah ingat menyediakan > ini saat compile time. lagi-lagi salah paham. ini bukan tentang hubungan satu file vs. banyak file terhadap reliability. tapi bagaimana upaya qmail untuk memberikan reliability. lagipula, tidak ada yang menggunakan istilah synchronous write di "linux". > > bandingkan juga dengan benchmark yang diberikan pada jawaban DS. > > itu karena monotori pakai default as is :-) postfix bisa diset supaya > lebih strightforward seperti qmail kalau mau. dari sini bisa dilihat > bahwa qmail kalah dalam fleksibilitas. tapi sekali lagi MTA ditulis > untuk memecahkan masalah tertentu saja. pada dasarnya benchmark dapat dibuat untuk menampilkan hasil sesuai dengan keinginan pembuat benchmark. > 1000 msg/menit ~ 15000/hari pada titik itu, bottleneck-nya sudah > di concurrencyremote. note: jangan dikacaukan dengan milis (ezmlm) > dengan ezmlm hanya ada 1 msg untuk lebih dari satu destination. boleh dijelaskan dari mana angka-angka ini? saya tidak mengerti, apa maksud 1000 msg/menit ~ 15000/hari pada titik itu. > kalau di Indonesia, sulit. sepintas saya lihat ISP menerapkan > setup 'mahal' karena legacy dari setup sebelumnya. Dengan qmail, > rate segitu (tanpa patch) bisa dilakukan dengan komputer dengan > ram 64MB :-) that's the point. ketika kebutuhan bertambah, single system dapat memenuhi kebutuhan, and more. patch ini diperlukan kalau kebutuhan tinggi, tapi menggunakan satu sistem. > dalam batas tertentu, saya masih percaya pada skalabilitas > horisontal. lakukan dengan beberapa komputer kecil-kecil. > dengan demikian, sekaligus diperoleh redundancy (kalau sudah > ada lebih dari 1 komputer, patch tsb. useless, red). kebutuhan redundancy berbeda untuk setiap orang. kebanyakan orang memakai single system. malah kadang banyak service dalam satu sistem. yang ingin saya sampaikan bahwa patch ini tidaklah tanpa fungsi, sehingga setiap kali sindrom ini muncul, solusinya adalah setup lebih dari satu komputer versi LVS. btw, apa yang Anda maksud dengan "red"? setau saya sih komentar redaksi.. -- H. D. Lee -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
