On Wed, Oct 22, 2003 at 11:32:50PM +0700, H. D. Lee wrote: > 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.
katakanlah exim (note: perilaku ini configurable), dia tinggal membuat hint database, kalau proses X sedang mengirim ke hotmail.com. semua mail ke hotmail akan dihandle oleh proses X. mulai dari scanning queue dir, sampai resolve dns dilakukan dalam satu korpus program. jadi lebih mudah dibanding MTA yang modular, di mana scheduler merupakan program terpisah dengan smtp client yang benar-benar melakukan remote deliveries. perlu diingat ini adalah keputusan designer (developer) MTA ybs. kalau sekedar implementasi sih saya percaya pasti bisa. saya yakin pernyataan berikut tidak 100% tepat, tapi boleh dibilang: mta monolitik sebenarnya tidak punya (tidak perlu) scheduler. > qmail tidak mempunyai fasilitas ini bukan karena perilakunya masih > acceptable. Posting DS point 3.2. saya juga tidak bilang begitu kan :-) menurut saya, tidak ada masalah dengan yang ada sekarang ini. soal DS, menurut saya terlalu positifisme, mengajukan alasan positif (dan mungkin benar) tapi tidak ada hubungannya dengan masalah yang sedang dibahas :-))) tapi, walaupun primary MX autoritatif, tapi tetap bisa sibuk atau bahkan crash bukan? soal spam, itu soal administrivia. kalau males ya bisa jadi gitu (backup mx diabuse spammer), kalau bisa dibuat strict no problemo. Dan, sepertinya DS mengacaukan antara pengertian mailserver backup dengan secondary MX. ingat secondary MX bisa saja merupakan autoritative mailserver untuk domain ybs! (bayangkan mail farm, red). > eh? any URL for reference? waduh .. sayangnya ini scattered di milis-milis MTA tsb. saya tidak tahu keyword yang tepat, yang memudahkan pencarian arsip. > reliablity, security. ... > simplicity, reliability. janganlah jadikan itu sebagai menara gading ... kalau spec jelas, sudah dari dulu-dulu ditulis oleh mereka (bapak-bapak pembuat MTA). reliability, security, simplicity yang anda sebutkan itu tetap bisa berlaku walaupun nanti exim, qmail dan postfix jadi support DSN. karena reliability, security, simplicity itu melulu soal MOTTO, sedang MTA adalah program yang harus ditulis, lebih ke implementasi praktis/real, yang perlu keringat, biaya dll. untuk hint saja, sorry kalau bombastis, kalau mau membuat mta yang benar-benar reliabel, simpel dan secure caranya gampang: jangan membuat MTA :-) > lagi-lagi salah paham. ini bukan tentang hubungan satu file vs. banyak > file terhadap reliability. tapi bagaimana upaya qmail untuk memberikan > reliability. justru itu. semua pembuat mta pasti ingin mta-nya reliabel. kenyataan postfix bisa mencapai tingkat reliabilitas yang sama dengan cara yang lebih efisien itu adalah fakta. sesekali DJB menyebut soal zeroseek. walaupun 'vapourware' tapi kalau ini benar diimplementasikan di qmail, barulah orang bisa membandingkan kecepatan (tanpa mengesampingkan reliabilitas) antara qmail vs postfix. kenyataan yang ada sekarang qmail K.O. > lagipula, tidak ada yang menggunakan istilah synchronous write di > "linux". gini saja kalau gitu .. anda jelaskan maksud dari 'synchronous write', sekaligus mencamkan di pikiran anda bahwa ini milis linux-admin. bisa jadi kita pakai 'jargon' yang berbeda dan saya salah mengerti dengan yang anda tulis. > > 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. just another positivism :-) Saya kurang tertarik dengan motivasi (bahkan saya tidak tertarik dengan kesimpulan pembuat benchmark), saya hanya tertarik pada data dan hasil. kesimpulan bisa didiskusikan. > > 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. upss sorry, kurang nol he..he.. 1000 per menit = 60 * 24 = 1440000 ~ 1500000 > that's the point. ketika kebutuhan bertambah, single system dapat > memenuhi kebutuhan, and more. patch ini diperlukan kalau kebutuhan > tinggi, tapi menggunakan satu sistem. itu meminimalkan risiko. anda akan paham kalau anda bekerja untuk ISP. 1000 per menit itu kira-kira 16 msgs/s. kemungkinan besar bottleneck adalah disk dan bandwidth. Tapi gini, point saya: jangan mulai dulu dengan patch! lakukan dengan apa adanya, kalau kurang baru dipatch. berapa load MTA anda sehari? anda pakai patch ini? > btw, apa yang Anda maksud dengan "red"? setau saya sih komentar > redaksi.. benar :-) Salam, P.Y. Adi Prasaja -- Berhenti langganan: [EMAIL PROTECTED] Arsip dan info: http://linux.or.id/milis.php
