Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><a href="http://search.cpan.org/dist/CHI/" rel="nofollow"><code>CHI</code></a> is a good base, and can do most caching you are likely to need, with the back-end chosen according to your need. We used to use <a href="http://search.cpan.org/~jswartz/Cache-Cache-1.06/" rel="nofollow"><code>Cache::Cache</code></a>, and on occasion even <code>Memoize</code>, but <code>CHI</code> appeared best in the end, and has certainly superseded <code>Cache::Cache</code>.</p> <p>Now for the caching back-end system. This will depend a lot on your web setup, and even on your operating system and hardware. If you have a lot of memory, and/or are running a small number of server processes, a memory-based cache is solid and easy. If you are running many processes and still have decent memory, you probably want a shared memory cache (and this will work fine on Linux and UNIX systems, but might not be supportable on Windows). If you have less memory, a file-based cache will work, but it'll be slower. </p> <p>However, if you are only prefetching, you might just as well use a database. And even if the caching is mainly there to avoid network requests, an SQL database will still provide the performance improvement you need. There's also a <code>CHI</code> driver for that at: <a href="http://search.cpan.org/~jswartz/CHI-Driver-DBI-1.25/" rel="nofollow"><code>CHI::Driver::DBI</code></a>. Most databases do very decent caching anyway.</p> <p><strong>UPDATE:</strong></p> <p><code>Cache</code> and <code>Cache::Cache</code> are both pretty old. <code>CHI</code> has been designed to replace <code>Cache::Cache</code>. Of these, <code>CHI</code> is definitely the best. </p> <p>Yes, even in mod_perl, a memory cache can be useful, but you can't afford it to become too large. mod_perl embeds Perl in the server processes, so each server process will have its own cache. This reduces effectiveness, but if you have a small number of things to cache, and they are used often, it is still worth using. </p> <p>Assuming you're on a UNIX-type system, a shared memory cache or a database cache will likely be your best bet, depending on how many things you are likely to need to cache, and their size. If your cache will become huge, and if network latency is the main part of the problem, a database cache backend will be fine. If the cache will always be relatively small, memory or shared memory should suit. </p>
    singulars
    1. This table or related slice is empty.
    1. POPerl, which is the best module to cache data for a web application?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USStuart Watt
    1. USStuart Watt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POPerl, which is the best module to cache data for a web application?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYou say "If the cache will always be relatively small, memory or shared memory should suit", but if I want to share cache among all server processes, I do not need memory, but shared memory, right? (and yes, I hope my cache will always be relatively small...)
      singulars
      1. PO
      1. USMarcoS
    2. CO@MarcOS yes, that's it
      singulars
      1. PO
      1. USStuart Watt
 

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