Sptnya solusinya utk market infos pake O/L - sedangkan utk order transaksinya (yg utama) pake broker manual [tentunya - dg institusi + si Brokernya masing2 oke poenya]
:) Kalo pas tradings - tahu2nya macet + mampet - kita boleh tanya2 Pak SBj - berarti kurang hoki (lucky) waktu itu + tentunya pas tradings ada2 'aja yg menghambat/menggangu (noises + errors) - yg sedapat mungkin mudah2an dapet dicegah/dikurangi > 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 >> [email protected]<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 >> [email protected]<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 >> [email protected]<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 >> [email protected]<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... >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> > >> > >> >> >> >
