Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    IPC / latency overhead with Two-task setup

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    Are there any expericences with Aleph servers / database servers running on different physical machines?
    We would like to run Apache (+ www-server, if possible) on one machine, pc-servers and the "rest" of Aleph on a second one and Oracle on a third.

    Resolution:
    [From Mathias Weyland, ETH Bibliothek, on ALEPH500-DISCUSS-L:]

    We migrated to a dedicated server setup roughly half a year ago after experimenting with said setup for more than a year. However, we kept all of the ALEPH services (www-servers, pc-servers, batch jobs etc.) on one single server. The Oracle database was moved to a dedicated server and ALEPH connects to that database by means of SQL*Net and the Oracle listener.

    Some performance issues became apparent after the switch to production and we determined that the network layer contributed to a vast extent to these issues. If the database resides on the same server than the application, communication between the two is usually carried out by inter-process communication[1] (IPC). If database and application are torn apart, information must be wrapped into network packages[2] and we discovered that the network layer adds a significant latency overhead which is boosted by the somewhat inefficient data handling of ALEPH.

    I therefore recommend a rock-solid network link between the two (or in your case maybe even three) servers. Bandwidth is not much of a problem since traffic is rather low, but latency is absolutely critical. We are under the impression that our situation improved dramatically after low latency was enforced on the link to the database. ([3], nice graph)

    Even though we do not have those in use, I would consider some kind of MyriNet (or whatever) high performance device or at the very least a high quality NIC.


    • Article last edited: 10/8/2013
    • Was this article helpful?