Secara primitif, setiap request itu akan di handle oleh satu thread. Thread ini start sejak request datang dan sampai response selesai dibuat dan dikirimkan.
Kalau kita bikin http server sendiri, kita bisa aja bikin proses yang create thread baru untuk setiap incoming request.. tapi ini cupu banget kan .. :) .. bahaya CPUnya bisa modar dan ga efisien aja klo threadnya musti di create terus terusan. okeh, dari situ muncul yang namanya Thread Pooling dan pembatasan maksimum thread (yang bisa dilayanin) .. bisa kita atur, kalau ada request datang sementara seluruh pool terpakai, kita bisa reject .. nah .. definisi concurency bisa dianalogikan dari situ .. seberapa thread pool yang kita alokasikan. logikanya berbanding lurus dengan setingan kita untuk max Thread ini. tentu saja ada faktor lain, seperti kalau kita konek ke database, seberapa besar connection pool yang kita alokasikan buat aplikasi supaya bisa konek ke DB .. nah .. dari situ kita bisa itung kalau mau scaling untuk meningkatkan concurent kita, kita harus nggedein yang mana .. bisa pakai clustering App server, bisa di DB , atau kombinasi .. 2008/3/3 Frans Thamura <[EMAIL PROTECTED]>: > menurut saya sih > > orang yang hit, request page gak dihitung sebagai reqeust > > tetapi session yang active ini yang jadi thread session disebut concurrent > masalah ikc bukan bandiwidth limit, wong unlimited, tetapi servernya ngambek > :)
