Archived

This forum has been archived. Please start a new discussion on GitHub.

How to optimize the ICE application in a measurable way

Hi, all

I have a problem with optimize my application based on ICE. ICE have some parameters to optimize its performance such as thread pool size. But my problem is there is a 400 person simultaneous login rush hour and I tune ICE to satisfy this requirement. and How could I know if it could get over the 500 or 600 person rush hour? if not , what's the proper thread size? Can anybody give me a methold to tune ICE in a measurable way? Thx!

Chao Sun

Comments

  • Without more detail, it is difficult to help. If you have more clients than threads, what will happen is that, once all threads in the pool are used, new incoming client requests are simply delayed; whenever a thread returns to the pool, it picks up another request.

    The exception to this is if operations are long-running, and you truly need 500 clients to execute the operation in the server *concurrently*. In that case, you need to have one thread in the pool for each client. However, a more scalable approach in this case is to use asynchronous dispatch, which allows you to have more concurrent invocations in progress than you have threads in the server.

    Please check the Ice manual on asynchronous dispatch for more detail on this.

    Cheers,

    Michi.
  • Hi, Michi:

    It's a web application and The function of ICE client is to check user password. The application is deployed in Websphere5.0.2 and the ICE client class is in a jar package. And ICE Server is a stand alone application, which check the password in ldap and return the result to ICE client. sometime users logon this system almost concurrently.
    Can you give me some suggestion in detail?

    Chao Sun

    michi wrote:
    Without more detail, it is difficult to help. If you have more clients than threads, what will happen is that, once all threads in the pool are used, new incoming client requests are simply delayed; whenever a thread returns to the pool, it picks up another request.

    The exception to this is if operations are long-running, and you truly need 500 clients to execute the operation in the server *concurrently*. In that case, you need to have one thread in the pool for each client. However, a more scalable approach in this case is to use asynchronous dispatch, which allows you to have more concurrent invocations in progress than you have threads in the server.

    Please check the Ice manual on asynchronous dispatch for more detail on this.

    Cheers,

    Michi.
  • chaosun wrote:
    And ICE Server is a stand alone application, which check the password in ldap and return the result to ICE client. sometime users logon this system almost concurrently.

    As I said, unless clients spend a long time in this operation, you don't need as many threads as you have concurrent clients.

    We can only provide general advice on Ice-specific topics in this forum. If you require advice specific to your application, please contact us at info@zeroc.com for our consulting services.

    Cheers,

    Michi.