nach sekarang udah mulai jelas dimana bottleneck-nya. dari sisi software, database sever pada OLTS bisa dibaratkan jantung yg memompa darah kotor (BEI ke OLT) untuk mengasilkan darah bersih (OLT ke user).
dari sisi infrastructure adalah masalah konetivitas & lebar bandwidth yg digunakan. akan sangat bayak celah dan variable yg bisa diukur untuk menghasilkan mutu layanan OLT yg baik atau yg kurang baik. bisa dianalogikan sebagai pembuluh darah yg mengalirkan darah masuk dan keluar dari jantung. server yg baik, harus juga didukung oleh hardware yg berkualitas dan software yg handal. bisa dianalogikan dng tubuh sehat dan pikiran sehat. dan ini semuanya sangat tergantung pada besar kecilnya alokasi investasi OLT pada IT. jadi untuk OLT, jika ingin bersaing mendapatkan nasabah, selain fee, features & service, juga harus mempertimbangan kualitas layanan dari sisi software, hardware dan infrastructure. salam, AR On 5/7/08, Dean Earwicker <[EMAIL PROTECTED]> wrote: > > *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... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
