On Sun, Feb 2, 2014 at 9:11 PM, Steven Siebert <smsiebe_at_gmail.com> wrote:
> 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).
>
Sorry about my loose semantics. Each request on my system causes a DB
connection (from a pool), performance of some DB stuff, and data return /
release connection back to pool. So, each concurrent connection does mean
a concurrent DB connect to me. I understand that I might have 1,000 users
on at a time but only 300 concurrent connections. The numbers I have been
throwing around (300) was supposed to mean truly concurrent DB connections.
> You will indeed bottleneck either at the request handler worker threads
> (the thread pool for the http handler), most likely,
>
Very interesting. It didn't occur to me that GF might have a setting for
this. I (ignorantly) figured that GF just keeps using threads until the OS
says no. I'll have to look at how to control this with GF.
> 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.
>
Yea. I am beginning to think that I correctly understood this from the
beginning. I just wasn't sure.
> 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 ;)
>
Good idea. Thanks!!
Blake
>
>
> 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
>>
>>
>>
>>
>>
>>