Kevin,
Thank you very much for your response. By simultaneous users I meant
concurrent requests. I am aware of and implemented the system as you
suggested.
I suppose my real question, which I had difficulty articulating was, is
there a way for me to simultaneous respond to more simultaneous requests
than I have allowable database connections. I now know the answer is no.
In a broader sense, I am wondering what I need to do
to maximize the number of simultaneous requests. I've figured out I need
to verify:
Max database connections
Max database connection pool size
Max http connection threads
Of course, I need the hardware to back it up.
If anyone has anything to add to this list, I'd surely appreciate it!
Thanks.
Blake
On Sun, Feb 2, 2014 at 8:08 PM, Kevin Schmidt <kevin.schmidt_at_nextgate.com>wrote:
> Blake,
>
> When you say simultaneous users, do you mean all logged in to the
> application at the same time? Or that many concurrent requests to the
> application? I assume you mean all logged in to the application at the
> same time which means some subset of these would actually be issuing any
> type of request at the same time. Depending on how interactive the app is
> and how quickly users go from page to page, on average a given user may be
> causing requests to be made less than 10% of the time, or on average at
> most 30 users would be issuing requests simultaneously.
>
> Given this, In general, you don't want each user to have a database
> connection open during their entire session. This is wasteful in that it
> is holding connections open that aren't being used and also means that you
> have to ensure users log out or sessions time out in order to close
> connections and return them to the pool.
>
> What you want to do is architect your database access to be done in a way
> where a connection is opened (retrieved from the pool) when a query is
> about to be issued and used for that, but then closed (returned to the
> pool) as soon as it is no longer actively being used. By doing this, you
> can limit the required connections to perhaps 30 or less and set your pool
> size accordingly.
>
> Kevin
>
>
>
> From: Blake McBride <blake_at_arahant.com>
> Reply-To: "users_at_glassfish.java.net" <users_at_glassfish.java.net>
> Date: Sunday, February 2, 2014 5:37 PM
> To: "users_at_glassfish.java.net" <users_at_glassfish.java.net>
> Subject: Scaling up
>
> Greetings,
>
> I have a GWT application (written in Java) that I host on Glassfish that
> uses Hibernate & PostgreSQL all on a Linux box. I don't know much about
> scaling the application or deployment to support a lot of simultaneous
> users so I though I would reach out to the glassfish community. For now, I
> have everything running on a single machine. So, at this point I am only
> looking to support as many users on the single machine as possible. Just
> to give my understanding of scaling a number, let's say I want to support
> 300 simultaneous users.
>
> I understand that each connection spawns a new Java (native) thread. That
> shouldn't be a problem. 300 threads on top of the ones used by glassfish
> and the OS shouldn't be a problem. Am I wrong?
>
> What scares me is the database connections. My understanding is that each
> connection creates it's own database connection. I understand there is
> pooling of these going on but I doubt the pool will handle 300 connections.
> I think this is my potential problem. Am I wrong? What possible
> solutions do I have?
>
> I think my _only_ potential issues are RAM, CPU horsepower, number of
> threads, and number of database connections. My opinion is that I should
> be okay regarding the RAM, CPU, and thread count. Is there anything else I
> should be worried about?
>
> Ultimately I may scale to more machines if needed, but that will be
> another matter.
>
> I really appreciate any help you can offer.
>
> Thanks.
>
> Blake McBride
>
>