300 simultanious users != 300 concurrent requests...buts lets assume 300
truely concurrent requests (maybe 5k users, probably more....again, a lot
depends on your app).
You will indeed bottleneck either at the request handler worker threads
(the thread pool for the http handler), most likely, or the db connection
pool (the db connection isnt assigned to the thread for the entire request,
often its lazy retrieved from the pool). Each can be configured with the
stable pool size and max pool size, a fair amount of tuning can be done.
Yes, you'll eventually resource starve with any application, gf or
ngix...but it wont likely be 300 concurrent users unless something is wrong
with your app. Throw some code against this and see wha your app can
handle ;)
S
On Feb 2, 2014 9:36 PM, "Blake McBride" <blake_at_arahant.com> wrote:
> On Sun, Feb 2, 2014 at 8:05 PM, Steven Siebert <smsiebe_at_gmail.com> wrote:
>
>> Each request does not spawn a new thread...read up on java nio.
>>
>
> I understand thread pooling. But you still need the ability to allocate
> enough threads to support the maximum number of needed simultaneous threads
> at any given time. Each active user must have it's own thread or you won't
> have multi-tasking.
>
>
>> Similarly, each request does not spawn a new db connection, read up on
>> connection pooling.
>>
>
> My understanding of connection pools is as follows. Creating a connection
> to a DB is an expensive operation. It makes sense to place a
> no-longer-needed connection to a pool for re-use rather than opening and
> closing a new connection each time. No problem. Got it. My problem is
> when you approach or attempt to exceed the maximum number of connections a
> database has to offer. A connection pool offers no help here. Am I wrong?
>
> I am wondering if there are solutions, problem, or issues I am not aware
> of.
>
> Is it correct that you can't have more simultaneous users than available
> database connections? <- BIG QUESTION
>
> Thanks for the help!
>
> Blake
>
>
>
>
>
>