DataSource is now the preferred way to obtain a database connection, but I don't think that this difference will be a big problem. There are a lot more other issues which can reduce or increase the performance of a database-driven application.
Anyway, 20k visits is a bad measure for performance issues related to the database. What exactly is a visit? If you mean database hits 20k hits per day will surely be no problem for the connection handling mechanism itself. Instead it depends a lot more on the implications a "visit" has for your application. Does it involve a high amount of data? Are there many database round-trips to satisfy a "visit"? How does your database schema look like? What kind of queries are necessary to get the necessary data from your database? Is there any kind of caching or something like this? As you can see there are a lot of things you have to consider...
I would recommend to do some load testing on the said application then you can look for performance bottlenecks and optimize where really needed!
posted 8 years ago
Thanks alot for your detailed reply, actually question in my mind was when 20k people will browse website(simple data browsing) atleast 1k connection might be active which is not allowable from any database i think. if 20 k daily visit are there i should keep this possibility in my mind that 1k concurrent users will be online.
what is ideal approach to manage connection usually in Enterprize environment to handle big traffic and all?
for my case connections are closed properly and are issued using singleton objects
i will appericiate your comments on above concerns.
atleast 1k connection might be active which is not allowable from any database i think
At least this would be a huge waste of resources because there are surely not 1k concurrent active connections. That's why there's usually some pooling mechanism involved. Application servers and Servlet containers often take care of connections pooling if your application obtains its connections from the container instead of creating connections itself. Additionally there are solutions like Pool from the Apache Commons project. I'd definitely recommend to use an existing solution for connection handling in a concurrent environment!
Nevertheless it's hard to tell if your application will be able to handle such a load. As I said it does not only depend on the number of database connections but on the data themselves, the database schema and others. Of course the hardware your application and database server are running on will make a difference. And the overall architecture and infrastructure of the application will be important to scale up to thousands of users.
Take the time and do some actual load testing under realistic conditions! This will be the only way to see if your application can handle high load and traffic. There are tools like JMeter which will help you to create load tests. It's almost impossible for us to judge your application's performance without knowing all the details of the whole application and setup ;-)
Are you really anticipating 20000 concurrent users? That is the only situation, assuming you kept a naive 1 to 1 mapping for users to database connections, where you would need the database to accept 20000 connections. Configuring a database to accept this number of connections is not difficult, SQL Server for example defaults to 32,767 connections, though I doubt those users could be doing much if they were all connected concurrently to an out the box server. Specifying your database and application server for 20000 concurrent users is a lot more work, and considerable expense.
Normally if you are anticipating 20000 daily users I'd follow Marco's suggestion: you need to estimate what concurrent load is likely to be and what a "visit" equates to then load test at that level.
Perhaps I should note that I've already managed web applications (although not Java-based) under high load and of course this is possible. With some million visitors (or more) per month the naive approach which works for you on your machine will most probably not work anymore in such an environment. You'll need to cluster your servers, the application will have to handle such a clustered environment etc. I've even seen very simple applications break down with ~20 visits per second because of a simple missing database index. You won't now for sure if the application as a whole will work under load as long as you don't run some test.
posted 8 years ago
so you mean to say ,if load is high, at code level we can not do much??? servers and clustered configration need to take care of that?
No no, don't get me wrong! Performance bottlenecks can be at any level of the whole application and infrastructure. But every application behaves different and has different needs. So if there are performance bottlenecks you won't know for sure where they are until you do some serious testing! As you can imagin, it won't help you to optimize the application if the real problem is the database server and the other way around.
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad: