*Untuk BEJ ke Broker OLT> 1 to 1 Broker OLT ke nasabah > 1 to many* Jadi bottlenecknya ada di broker OLT. Jgn lupa untuk order dan marketinfo itu dua system (jalur) yang berbeda. Yang sering hang biasanya OLTS/Market Info yang sistemnya database-driven, yang bagus itu yang memory-based, tapi ada pro dan con nya. Dan sebaiknya server untuk ORDER dipisah dengan server MARKETINFO.
*Database driven* Data streaming dari JATS, diolah dan disimpan di database. Client OLTS secara periodik me *retrieve *dari database tsb. Pros: Data historical lengkap dan "matang" alias informatif, bisa analisa TA, murah, dsb. Cons: Lambat, berat dan laggard (ada delay), apalagi kalau market rame bgt. Kalau overload, server akan memutuskan koneksi yang dianggap membebani. Kalau pakai app OLTS di quad-screen pasti jebol. hehe.. Mis: H*TS, IP*T, dan OLTS lainnya *Memory based* Data streaming dari JATS diolah secara realtime dan disimpan didalam memory yang besar. Hasil olahan di *broadcast *ke semua terminal yang aktif. Pros: Data realtime (best bid/ask, running trade) Cons: Data streaming masih agak mentah, tidak ada/jarang ada data historical, relatif mahal Mis: Stockw***, RT*, IM* Jadi ini tanggungjawabnya lebih ke broker OLTS/provider, bukan BEI. OLTS tidak bakal mau pake memory-based karena costnya bandwidthnya gak nutup. CMIIW Regards, DE 2008/5/7 Adam Rajsha <[EMAIL PROTECTED]>: > setuju. saya rasa aristektur yag ini yg dipakai: > > server BEI ---intranet--- server OLT ------ internet --- user > server olt mempunyai 2 kanal berbeda untuk menghubungkan antara user > ke server OLT dan server OLT ke server BEI, server OLT berfungsi > layaknya Proxy. > > akan menjadi lebih baik bila database BEI menggunakan teknology clutering > dan load balancing dng beberapa backbone koneksi untuk OLT, idealnya satu > koneksi untuk satu OLT. begitu juga OLT punya teknologi yg sama dng beberapa > koneksi untuk user, dng demikian bottle neck bisa diminimalkan. > > tapi ini technology yg sangat mahal, akan membebankan biaya bagi OLT & > BEI. > salah satu contohnya yahoo. bisa mengenali IP address user, sehingga bisa > diarahkan ke server yg terdekat dng user. misal user dari indonesia akan > secara otomatis terhubung ke server yg sudah di alokasikan untuk IP addres > indonesia. namun bila user tsb login dari US, maka akan diarahkan ke server > di US. > > salam, > AR > > On 5/7/08, odhienx <[EMAIL PROTECTED]> wrote: > > > > kalau saya melihatnya mungkin antara koneksi user ke server olt dan > > dari koneksi server olt ke server yg ada di bei, menggunakan satu > > saluran yang sama, seperti berikut ini topologinya : > > > > server olt ---- internet --- server BEI > > | > > user > > Jadi kalau misal demikian halnya berarti 1 user yang konek ke server > > olt, olt akan membutuhkan 4 queue traffic (2tx & 2rx (ke bei dan ke > > user)) untuk melayani koneksi user ke server BEI menggunakan saluran > > yg sama. > > Jika pada saat ramai, user melakukan bid/sell pada saat bersamaan, ini > > menyebabkan queue menjadi panjang dan koneksi menjadi bottleneck, dan > > diperparah lagi apabila koneksi databases menggunakan persistent, > > menyebabkan user yang baru tidak bakal dapat masuk karena kehabisan > > jatah port yang bisa dibuka, dan atau user yang memiliki koneksi lebih > > lambat menjadi tidak kebagian jatah, ingat bahwa protokol TCP tidak > > mengijinkan 1 bit pun hilang, apabila terjadi dia akan terus menunggu > > sampai batas waktu menunggunya hilang, dan sistem terus membuka > > portnya dan tidak mengijinkan koneksi baru untuk masuk. > > > > kondisi lain... > > > > server BEI ---intranet--- server OLT ------ internet --- user > > server olt mempunyai 2 kanal berbeda untuk menghubungkan antara user > > ke server OLT dan server OLT ke server BEI, server OLT berfungsi > > layaknya Proxy, > > jika kondisi ini terjadi tentunya tinggal cek infrastruktur server OLT > > ke Server BEI, dan atau server OLT ke Internet, yang lain-lainya sama, > > ada kemungkinan server OLT mengalami stagnan, karena koneksi > > databasesnya persisten, pada saat ramai, semua user meminta mereka > > didahulukan, server OLT stagnan karena kelebihan koneksi persisten ke > > databases. > > > > jadi kesimpulannya apapun model koneksinya, server BEI dan server olt > > menggunakan sistem koneksi persisten ke databasesnya menyebabkan semua > > yang terkoneksi saling berebut untuk masuk, dan "ngendon" di port > > tersebut, namun karena keterbatasan infrastruktur, terjadilah lost > > walaupun 1 bit, menyebabkan port tersebut nganggur tidak bisa dibuka > > atau digunakan sampai beberapa waktu, sedangkan yang ngantri port > > banyak, mulailah sistem stagnan lama disini. > > > > solusinya benahi infrastruktur dengan cara tidak menggunakan 1 layanan > > koneksi, atau membuat model IIX mini khusus BEI > > > > --- In obrolan-bandar@yahoogroups.com <obrolan-bandar%40yahoogroups.com>, > > "jsx_consultant" > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Embah gunakan aplikasi OLT yg bersifat Client Server, Client > > > pake Windows dan Server pake Unix Alike engine. > > > > > > Pada aplikasi Client Server, jika jaringan internet putus > > > maka coneksi akan otomatis putus karena server akan > > > meng KILL proses tsb. > > > > > > Cuman GANGGUAN yg embah alami terjadi pada jaringan internet > > > YG MULUS jadi server tidak mungkin mengKILL proses koneksi > > > embah secara otomatis , kecuali secara MANUAL di KILL... > > > > > > > > > > > > > > > --- In obrolan-bandar@yahoogroups.com<obrolan-bandar%40yahoogroups.com>, > > "Adam Rajsha" > > > <adam.rajsha@> wrote: > > > > > > > > numpang nimbrung yach Mbah, jadi penasaran juga nich. > > > > > > > > bila menyimak ulasan Mbah, kayaknya Mbah gunakan OLT yg berbasiskan > > > Windows. > > > > secara programing bila hanya terjadi disconected tanpa > > > mengakibatkan logout, > > > > maka bila aplikasi tsb 'cerdas', maka dia dapat melakukan conneksi > > > kembali > > > > secara otomatis. > > > > > > > > namun bila disconneted terjadi hingga menyebabkan logout, maka ini > > > yg harus > > > > dicurigai, atau paling tidak aplikasi ini tidak 'cerdas'. > > > > > > > > mungkin benar ada yg kasih saran untuk gunakan berbasis web (web- > > > based), > > > > karena secara natural aplikasi berbasiskan web menggunakan tehnik > > > yg disebut > > > > sebagai 'disconected recordset'. > > > > > > > > artinya koneksi hanya terjadi bila ada interaksi antara user dan > > > aplikasi, > > > > jadi setelah aplikasi meng-excecute suatu proses (query) maka > > > koneksi secara > > > > otomatis terputus, tapi tidak menyebabkan logout. session tiap user > > > akan > > > > terus terjaga dalam bentuk cookies atau 'session'. > > > > > > > > selama kita melakukan aktivitas atau 'aktive' pada aplikasi web > > > tsb, session > > > > tsb tidak akan hilang. > > > > > > > > jadi bila Mbah gunakan aplikasi OLT web dan terus 'aktive', tapi > > > masih juga > > > > terjadi disconnected (logout), nah ini benar2 perlu dicurigai. > > > > > > > > salam, > > > > AR > > > > > > > > > > > > > > > > On 5/7/08, jsx_consultant <jsx-consultant@> wrote: > > > > > > > > > > Kalo suatu server lagi RAMAI: > > > > > - Apakah kita ENGGA BISA masuk ?, atau > > > > > - Kita dikasih masuk (connect) baru digebug (diputusin)... > > > > > > > > > > Kalo menurut LOGIKA embah: > > > > > - Jika suatu sever udah TERLALU RAMAI (quota user dilampaui), > > > > > otomatis sistem TIDAK mengijinkan connect, kita engga akan > > > > > berhasil connect.. betul engga ?. Jadi kita TIDAK AKAN > > > > > mengalami kejadian seperti di KILL (didisconnect secara > > > > > PAKSA). > > > > > > > > > > Ngapain sistem ngijinin KITA BISA CONNECT kalo CUMAN buat > > > > > di KILL... > > > > > > > > > > > > > > > --- In > > > > > obrolan-bandar@yahoogroups.com<obrolan-bandar%40yahoogroups.com><obrolan-bandar% > > > 40yahoogroups.com>, > > > > > "Andrian Kurniady" > > > > > <andrian@> wrote: > > > > > > > > > > > > Kalau yang saya perhatikan sih, dari beberapa OLT yang saya > > > pakai : > > > > > > 1. Biasanya client OLT ada settingan semacam "timeout", di mana > > > > > kalau > > > > > > servernya tidak merespon dalam jangka waktu <sekian> detik, dia > > > > > anggap > > > > > > koneksi putus (muncul tanda putus, lalu tanya mau reconnect atau > > > > > > tidak) -- walopun bukan karena diputusin sama servernya. > > > > > > > > > > > > 2. Servernya bisa dibilang tidak mampu handle transaksi "ramai" > > > pada > > > > > > saat market lagi bergerak (rally), jadi kalo lagi rally, respon > > > > > server > > > > > > jadi lambat (karena banyak antrian transaksi dan servernya nggak > > > > > > kuat). Kalau lambatnya keterlaluan sampai lewat dari timeout > > > seperti > > > > > > di atas, ya otomatis client anda terputus. > > > > > > --> respon server lambat bisa jadi karena -> koneksi server OLT > > > ke > > > > > > server BEI lambat, server OLTnya yang tidak mampu (kebanyakan > > > user), > > > > > > atau koneksi server OLT ke IIX yang lambat (kalo traffic normal > > > > > waktu > > > > > > market sepi tidak lambat, kalo trafficnya lagi ramai, > > > koneksinya ga > > > > > > kuat). > > > > > > > > > > > > 3. Walaupun mbah nyobanya di beberapa server, bisa jadi gejala > > > yang > > > > > > sama terjadi juga karena banyak orang yang terputus lalu coba > > > pindah > > > > > > server seperti mbah, nah kalo total server masih mampu handle > > > total > > > > > > user ya no problem (misalnya lagi kurang beruntung di mana > > > server > > > > > yang > > > > > > dipakai lagi ramai, sedangkan server sebelah kosong), tapi kalo > > > > > total > > > > > > servernya tidak sebanding dengan total user, pindah server ya > > > jelas > > > > > > tidak ada gunanya (kan semua servernya ramai dan overloaded). > > > Atau > > > > > > kalo yang masalah itu bandwidth koneksi (OLT ke BEI dan OLT ke > > > IIX), > > > > > > pindah server juga ga ada gunanya karena pool bandwidthnya > > > biasanya > > > > > > sama. Tapi kalo dari praktek programming network yang benar sih, > > > > > > walopun OLT ke BEI lambat, semestinya client tidak terputus, > > > karena > > > > > > server OLT tetap bisa respon ping dari client. > > > > > > > > > > > > 4. Kalau yang saya perhatikan sih, tidak semua OLT kena masalah > > > itu > > > > > > (kalo ramai disconnected). Ada satu OLT yang saya pakai dan > > > sering > > > > > > kejadian putus-kalo-rame begitu, sedangkan OLT sebelah normal - > > > > > normal > > > > > > saja tuh (jadi bukan salah server BEI). > > > > > > > > > > > > -Kurniady > > > > > > > > > > > > 2008/5/7 jsx_consultant <jsx-consultant@>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- In > > > > > > > obrolan-bandar@yahoogroups.com<obrolan-bandar%40yahoogroups.com> > > <obrolan-bandar% > > > 40yahoogroups.com>, > > > > > "bang" <bankwij63@> wrote: > > > > > > > > > > > > > > > > Mbah. > > > > > > > > Sepertinya permasalahan ada di penyedia OLT. > > > > > > > > Kita bisa tanya kepada penyedia OLT. Berapa kemampuan server > > > > > OLT > > > > > > > menghandle > > > > > > > > secara bersamaan di akses oleh member OLT tersebut. Misalnya > > > > > > > kemampuannya > > > > > > > > server maksimum 200 customer mengakses secara bersama-2 maka > > > > > customer > > > > > > > yang > > > > > > > > ke-201 tidak akan pernah bisa masuk alias akan diputus terus > > > > > setiap > > > > > > > kali > > > > > > > > masuk. > > > > > > > > > > > > > > Embah coba bukan cuman 1 server aja tapi beberapa server.. > > > > > > > > > > > > > > Kalo limit JUMLAH user dilampaui seharusnya kita TIDAK bisa > > > > > connect > > > > > > > tapi embah mengalami BISA connect LALU putus/diputus dan > > > kejadian > > > > > > > ini tidak selalu terjadi pada BURSA RAMAI tapi pada saat ada > > > > > > > saham yg LAGI MULAI RALLY... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
