On Sat, Oct 18, 2003 at 07:00:01AM +0700, H. D. Lee wrote: > .... reuse PID.. dalam waktu satu detik. Reuse PID akan terjadi pada > sistem yang sibuk. Tapi kalau PID yang sama dipakai lagi dalam waktu satu > detik, artinya proses harus banyak dan cepat, sehingga nomor PID yang > dipakai mengulang, dalam detik yang sama itu.
note: program yang disediakan oleh source qmail tidak terkena dampak ini. 'workaround' yang dilakukan DJB tidak diikuti oleh developer lain, karena memang DJB tidak menyebutkannya pada spec maildir yang dia tulis. workaround lain yang dilakukan postfix/courier setelah melihat kenyataan bahwa kebanyakan developer lain (MUA/IMAP/POP3) menggunakan spec maildir seperti yang dituliskan DJB as is. > > 3.2. mta modular umumnya sulit, kecuali zmailer. di postfix > > sendiri ini tidak masuk prioritas, walaupun mungkin > > ada keinginan untuk memasukkan featuer ini, plus > > connection caching (zmailer support connection caching). > > maaf, bisa dijelaskan.. point 3.2 adalah mengenai mail routing > violation. tentang percobaan delivery terhadap minimum dua MX. mungkin > bila dijelaskan tentang kesulitannya, saya bisa mengerti arah dari > diskusi point ini. 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. > 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. philip haezel, DJB, wietse merasa spec untuk DSN ini problematik, sehingga enggan untuk mengaplikasikannya. 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 :-) > 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. > 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. > > 4.6. untuk mailserver tujuan seperti yahoo/hotmail, cara > > qmail ini manjur. tapi kalau bisa per destination > > concurrency seperti punya postfix, pasti asik :-) > > more nuts and bolts means unsimple. nice option, yes. problematic? > unlikely. sejauh ini cuma seorang yang melaporkan ada kejadian ini. Ini berkaitan dengan benchmark yang dilakukan oleh Monotori di atas. > YMMV, tapi komputer kencang sekarang cukup membuat repot qmail tanpa > patch ini. pemakai yang beruntung punya komputer, bandwith dan semuanya > kencang, pertimbangkan patch ini. 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. 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 :-) 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). Salam, P.Y. Adi Prasaja -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
