Performance in extensions #

Part 3, chapter 36. An extension can make every page of a site slower: a listener on response/output, an operator in the pagelayout, a fetch in a loop. This chapter lists the usual causes and the tools that find them.

Measure first #

Measure the page before and after you switch your extension on; the difference is what it costs.

Database #

• Count queries. A page that runs the same query once per list item has a loop that should fetch once.
• Fetch with limits and filters; never load a whole subtree to count it (subTreeCountByNodeID() and the _count fetch functions count in the database).
• Do not load attributes you do not use: load_data_map false() for lists of names.
• Index your own tables on the columns you query by.

Caching #

Listeners and operators on every page #

response/output, request/input and operators in the pagelayout run on every request. Keep them to a few microseconds: no database, no file reads, no network. Do the work elsewhere and store the result.

Persistent workers (Velocity) #

Velocity, the recommended application server, keeps PHP processes alive between requests. That makes the kernel fast, and it changes the rules for your code:

• No request state in statics. A worker puts every class's statics back between requests, but code that relies on a static being empty at the start of a request should not exist: compute per request, or key the value by request.

• Register once per request with a request key, not with a true flag, as the Velocity documentation shows:

  if ( self::$registered !== eZExecution::requestKey() )
  {
      self::$registered = eZExecution::requestKey();
      register_shutdown_function( array( __CLASS__, 'flush' ) );
  }

• New classes need a restart of the workers. After deploying new code, ./console exp:velocity deploy regenerates autoloads, clears caches and restarts the workers.

• Never wrap a download plus eZExecution::cleanExit() in catch ( Exception ): under Velocity the clean exit throws to end the request.

See Velocity: running Exponential in a persistent-worker web server.

Front end #

• Load scripts and styles through the packer (one bundle, cached, with the time stamp in the name).
• Require page-specific scripts with ezscript_require on that page only.
• Images through image aliases, not full originals.

Related pages #

• Previous: Debugging extensions
• Next: Documenting your extension, including help pages
• Benchmarking, Caches
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.