Databases
StackOverflow2013
Postsdbo
POWhat's the best IPC mechanism for medium-sized data in Perl?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat's the best IPC mechanism for medium-sized data in Perl?
    primarykey
    data
    text
    <p>I'm working on designing a multi-tiered app in Perl and I'm wondering about the pros and cons of the various IPC mechnisms available to me. I'm looking at handling moderately-sized data, typically a few dozen kilobytes but up to a couple of megabytes, and the load is pretty light, at most a couple of hundred requests per minute.</p> <p>My primary concerns are maintainability and performance (in that order). I don't think I'll need to scale up to more than one server, or port off of our main platform (RHEL), but I suppose it's something to consider.</p> <p>I can think of the following options:</p> <ul> <li>Temporary files - Simplistic, probably the worst option in terms of speed and storage requirements</li> <li>UNIX domain sockets - Not portable, not scalable</li> <li>Internet Sockets - Portable, scalable</li> <li>Pipes - Portable, not scalable (?)</li> </ul> <p>Considering that scalability and portability are not my primary concerns, I need to learn more. What's the best choice, and why? Please comment if you need additional information.</p> <hr> <p><strong>EDIT:</strong> I'll try to give more detail in response to <a href="https://stackoverflow.com/questions/431623/whats-the-best-ipc-mechanism-for-medium-sized-data-in-perl#432629">ysth's questions</a> <strong><em>(warning, wall of text follows)</em></strong>:</p> <ul> <li><strong>Are readers/writers in a one-to-one relationship, or something more more complicated?</strong></li> <li><strong>What do you want to happen to the writer if the reader is no longer there or busy?</strong></li> <li><strong>And vice versa?</strong></li> <li><strong>What other information do you have about your desired usage?</strong></li> </ul> <p>At this point, I'm contemplating a three-tiered approach, but I'm not sure how many processes I'll have in each tier. I think I need to have more processes towards the left side and fewer toward the right, but maybe I should have the same number across the board:</p> <pre> .---------. .----------. .-------. | Request | -----&gt; | Business | -----&gt; | Data | | Manager | &lt;----- | Logic | &lt;----- | Layer | `---------' `----------' `-------' </pre> <p>These names are still generic and probably won't make it into the implementation in these forms.</p> <p>The <strong>request manager</strong> is responsible for listening for requests from different interfaces, for example web requests and CLI (where response time is important) and e-mail (where response time is less important). It performs logging and manages the responses to the requests (which are rendered in a format appropriate to the type of request).</p> <p>It sends data about the request to the <strong>business logic</strong> which performs logging, authorization depending on business rules, etc.</p> <p>The business logic (if it needs to) then requests data from the <strong>data layer</strong>, which can either talk to (most often) the internal MySQL database or some other data source outside our team's control (e.g., our organization's primary LDAP servers, or our DB2 employee information database, etc.). This is mostly simply a wrapper which formats the data in a uniform way so that it can be handled more easily in the business logic.</p> <p>The information then flows back to to the request manager for presentation.</p> <p>If, when data is flowing to the right, the reader is busy, for the interactive requests I'd like to simply wait a suitable period of time, and return a timeout error if I don't get access in that amount of time (e.g. "Try again later"). For the non-interactive requests (e.g. e-mail), the polling system can simply exit and try again on the next invocation (which will probably be once per 1-3 minutes). </p> <p>When data is flowing in the other direction, there shouldn't be any waiting situations. If one of the processes has died when trying to travel back to the left, all I can really do is log and exit.</p> <p>Anyway, that was pretty verbose, and since I'm still in early design I probably still have some confused ideas in there. Some of what I've mentioned is probably tangential to the issue of <strong>which IPC system to use</strong>. I'm open to other suggestions on the design, but I was trying to keep the question limited in scope (For example, maybe I should consider collapsing down to two tiers, which is a much simpler for IPC). What are your thoughts?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USAdam Bellaire
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhat's the best IPC mechanism for medium-sized data in Perl?
      1. USBobbyShaftoe
      1. VTFavorite
    2. VO
      singulars
      1. POWhat's the best IPC mechanism for medium-sized data in Perl?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhat's the best IPC mechanism for medium-sized data in Perl?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload