A good performance architecture ?

Discussions

Performance and scalability: A good performance architecture ?

  1. A good performance architecture ? (12 messages)

    Hi all,
    I have to think for a litle JavaServer application running on SunOne on Solaris with Sybase. This application will be able to accept about 15,000 connection in few hours !!
    So I don't want to have a complex architecture (it's a little application - around 20 JSPs without big transaction), but I'm looking for a good way to manage the big number of connection.
    I'am thinking about a 'transaction pool' in memory which commit the transaction in DB once X number of transaction are in the pool to prevent multiple DB access.

    What do U think ?
    Does a standard architecture can support this ? Or do I think about another solution ?(like the previous one)

    I'm open for any suggestion..

    Thanks a lot

    Kevin

    Threaded Messages (12)

  2. I'am thinking about a 'transaction pool' in memory which commit the transaction in DB once X number of transaction are in the pool to prevent multiple DB access.
    I would abandon the 'transaction pool' idea! From the sounds of your application you would be better off having a data caching layer. If you use something like hibernate, it is real easy to add caching in the datalayer. Good advice I recieved a few years back: Don't worry too much about performance in your design phase. Dont ignore it of couse. Implement a smart design and it will alow for the changes that may have to be made for performance.
  3. I'am thinking about a 'transaction pool' in memory which commit the transaction in DB once X number of transaction are in the pool to prevent multiple DB access.
    This is a really bad idea. Why would you need a database if you could do that 'in memory'? Think of 'ACID' - especially the 'D', of course. If you're going this route, you'll have to struggle with 'complex architecture' for sure. I agree with the previous poster, consider caching.

    Regards,
    Stefan
  4. A good performance architecture ?[ Go to top ]

    I'am thinking about a 'transaction pool' in memory which commit the transaction in DB once X number of transaction are in the pool to prevent multiple DB access.What do U think ?
    Its better to use connection pooling provided by the application server rather than transaction pooling. If you feel that the number of connections are higher then you should adjust connection pool size accordingly (after running actual stress tests).

    In your design you should make sure that you release database connection as soon as you have used it. It will help in better reuse of existing connections.

    Also, you can think of dividing your database tables in Reference data and Transaction data. You can very well cache reference data in memory. There are open source frameworks available to do that for you.

    You can think of clubing update queries and firing them in one shot so that you can reduce span of transaction and in term your transaction will be of short duration.

    - Shiv
  5. BTW, how many of these 15000, are concurrent conections?
    What is your Solaris Box configuration?

    -Vilas.
  6. More information[ Go to top ]

    Of course I'll use connection pooling but this application will have to support 15,000 connections on few hours and these 15,000 connections will be data typing on a small form (about twenty fields Max.).
     That's why I can't use lot of data caching because I'm oftenly in creation mode with INSERT statement. That's why I think about 'transation pool' which containts X number of transaction to commit and execute theme by batch.

    I don't know the maximum number of concurent connections but we'll have 15,000 connection on 3-4 hours and each connection will during around fifteen minutes.

    But I can't certify that we won't have 7-8,000 concurent connections.

    I don't know now on which hardware configuration we will be (maybe an Enterprise-3500) but I'm sure that we will be running on SunOne 6.1 SP1.

    Thx
  7. More information[ Go to top ]

    "... this application will have to support 15,000 connections on few hours and these 15,000 connections will be data typing on a small form (about twenty fields Max.)."

    "... each connection will during around fifteen minutes."

    If I understand you correctly, "fifteen minutes" is the expected average duration of a user session from an application viewpoint ("app_session"), _not_ the average duration of a user's database session ("db_session"). So let's say you have 15,000 app_sessions within 3 hours and each app_session has to insert n rows (n <= 20) into the database when the user presses a 'submit button' or something like that.

    Assuming that you can batch one 'n rows insert' (e.g. by using stored procedures) into m database calls (where m < n, of course) there are 15,000 / (3h * 60min * 60sec) = 1.4 database transactions (= db_sessions) per second (each transaction consisting of m db calls). I can't see concurrency with respect to the database here - it simply boils down to minimizing the number of db roundtrips per transaction (i.e. making m as small as possible).

    But, perhaps I misinterpreted your requirements completely? Let me know ...

    Regards,
    Stefan
  8. More information[ Go to top ]

    Whether standard architectures will scale to your requirement or not will depend on

    1. Ability to provide for max number of concurrent connections at HTTP server
       This may need suitable adjustments to HTTP server parameters, number of max. sockets allowed on your Solaris box etc.

    2. Ability to provide for max number of db conections at database server
       This can be done by adjusting the connection pool size.

    3. Ability to keep DB operations to less than n second, so that there is no queuing at DB layer with given connection pool size.
       [e.g If you have 4000 concurrent users , submitting 4 requests in a 15 min period with 160 connections in the connection pool, then you have to keep DB operations to less than 1 second to achieve zero queuing at DB layer. You can use queing theory formulae to get right numbers for your case].
       Coding a stored proc might help if more than a few DB operations are inolved per transaction.
       To optimize INSERTs make sure your physical organization is right.
       Any improvments here will improve your response time.

    4. Having right amount of memory to support these configurations.

    If based on above you determine that standard architecture may not suffice then you may think of alternatives.
  9. A good performance architecture ?[ Go to top ]

    Hi Kevin,

    Few questions..

    1. # of total users supported by your application?

    2. # of active users for your application? In other words durign peak hours how many users are expected to logged in into the application.

    3. # of concurrent requests expected per min.? This means how many concurrent requests will your application be serving.

    4. What is the average resposne time expected?

    5. What is the size of a typical INSERT business transaction? Means if a request arrives in the server, how much time will it take to complete the request. If you can quantify this then at least categorize it in simple, medium and complex process.

    6. Average number of database accesses in case of a typical business transaction?

    I think when you answer these questions your problem will be more elaborate and context will be clear to us. Then only we can suggest you accurate and reliable solution.

    - Shiv
  10. Shiv

    There is a mention of some open source for caching reference data. Can you please help me find something. Or to be more precised it would be great if you could send me the URLs where I can refer the caching implementation . Also would be great if you could suggest some specific patterns or architectures for achieving the same.

    Thanks in Advance
    Nitin Shethia
  11. Caching Framework[ Go to top ]

    On of the most talked about Caching framework is from Apache.

    http://jakarta.apache.org/turbine/jcs/index.html

    java caching System.

    - Shiv
  12. Thanks for all[ Go to top ]

    Thanks guys for all your comments.
    I'll use it to determine the best way for building this app. I certainly post more questions when my staff and I will begin to start the developpement circle.

    Thanks for all.

    Kevin
  13. Hi all,I have to think for a litle JavaServer application running on SunOne on Solaris with Sybase. This application will be able to accept about 15,000 connection in few hours !!So I don't want to have a complex architecture (it's a little application - around 20 JSPs without big transaction), but I'm looking for a good way to manage the big number of connection.I'am thinking about a 'transaction pool' in memory which commit the transaction in DB once X number of transaction are in the pool to prevent multiple DB access.What do U think ?Does a standard architecture can support this ? Or do I think about another solution ?(like the previous one)I'm open for any suggestion..Thanks a lotKevin
    crazy.