Netherlands
4 days / 20 talks
Awesome and great speakers
October 22-27
…
Doug Easterbrook
Studio and Postgres are part of the software stack used by Arts Management Systems. We’ve expended a great deal of effort to make a high availability, high performance application capable of millions of daily transactions. Theatre Manager, our ticketing software, has sold events like Elton John, Bob Dylan, Phantom of the Opera, Hamilton, Miss Saigon, Shania Twain and more. In this context, Arts Management has explored any and all mechanisms to achieve the best performance possible from Studio, Postgres and the rest of the stack.
In an earlier era, Doug designed the first version of Theatre Manager using Omnis 3.3+. The need for performance has been the one constant over the years. Studio 4.1 and the beta Postgres Dams was agame changer (thank you Gary Ashford). Ideas started to flow and shortly after that, we invented Postgres Workers to wrest the full power of all CPU’s within a machine. After demonstrating workers at Euromnis 2011 in Arnhem, our code was adapted into Studio as the basis for all current Studio Worker processes.
There will be two sessions on performance. The basis for both sessions are sample libraries given to all participants. This represents decades of proven code and contain:
The code performance analyzer
Database object and helpers
Base table class and helpers
Cache object and helpers
Listen notify object and triggers
Numerous helpful pgSQL stored procedures
Techniques for adding performance
Techniques for exposing chatty code
Text search implementation
TMObjs, the truly time saving binary search, and other nice tools and helpers
Arts Management Systems has proudly contributed the following to the Omnis community:
xComps: TMObjs, jsoncpp and ExcelFormat
The original Postgres Worker concept
The $collectperformancedata concept and a Performance Analyzer library so you can find where Omnis code is spending most of its time
Table class architecture tips to allow writing to a query, minimizing data transfered and boosting performance significantly
Advocating for the JSON export, using git as alternative VCS for numerous benefits
Introducing Sentry and automatic reporting for post deployment error discovery
Starting and controlling multiple Omnis servers
Advocating for Chromium Embedded which resulted in oBrowser
Accufonts
and more.
In an earlier era, Doug designed the first version of Theatre Manager using Omnis 3.3+. The need for performance has been the one constant over the years. Studio 4.1 and the beta Postgres Dams was agame changer (thank you Gary Ashford). Ideas started to flow and shortly after that, we invented Postgres Workers to wrest the full power of all CPU’s within a machine. After demonstrating workers at Euromnis 2011 in Arnhem, our code was adapted into Studio as the basis for all current Studio Worker processes.
There will be two sessions on performance. The basis for both sessions are sample libraries given to all participants. This represents decades of proven code and contain:
The code performance analyzer
Database object and helpers
Base table class and helpers
Cache object and helpers
Listen notify object and triggers
Numerous helpful pgSQL stored procedures
Techniques for adding performance
Techniques for exposing chatty code
Text search implementation
TMObjs, the truly time saving binary search, and other nice tools and helpers
Arts Management Systems has proudly contributed the following to the Omnis community:
xComps: TMObjs, jsoncpp and ExcelFormat
The original Postgres Worker concept
The $collectperformancedata concept and a Performance Analyzer library so you can find where Omnis code is spending most of its time
Table class architecture tips to allow writing to a query, minimizing data transfered and boosting performance significantly
Advocating for the JSON export, using git as alternative VCS for numerous benefits
Introducing Sentry and automatic reporting for post deployment error discovery
Starting and controlling multiple Omnis servers
Advocating for Chromium Embedded which resulted in oBrowser
Accufonts
and more.
Postgres, table classes, caching, and performance optimization
Part 1: generally about table classes, performance tips and latency
Doug will be discussing many techniques to squeeze performance out of table classes, Postgres, stored procedures, workers, list manipulation, upserts, reducing latency, SQL tricks, common table expressions, JSON within Omnis and some built in postgres features and procedures, replication, high availablility, backups and the Postgres planner.
Part 1 will focus on the table class and methods overridden for performance:
- Performance Analyzer
- Automating joins
- Limiting data traffic
- Using returning for 15%+ improve performance
- Replacing text in the sql statement with functions using derived columns
- updating using query classes to simplify code
- Nice little modifications to $insert, $update, $delete to ignore DB traffic if nothing significant changes
- Setting defaults for data and setting defaults for primary keys
- Minimizing or reducing latency and other tricks
Parts 1 and 2 will be presented in succession.
Postgres, table classes, caching, and performance optimization
Part 2: Caching, listen-notify, time zone support and text searching
Part 2 adds to topics discussed in part 1 and fills out the roster of performance techniques such as:
- Caching as a natural addition to performance including
- Strategies for types of caching
- Strategies for cache invalidation
- Listen Notify
- to avoid unnecessary polling
- or to invalidate cache and force reread
- Time zone support made very easy
- The worker patterns and the benefit of breaking up code into multiple workers
- Grabbing existence of child records en masse for edit checks
- Text search, unaccent and others
- Advisory locks vs lock for update
- Upserts – are they for you
Parts 1 and 2 will be presented in succession.
Packages
How you can deliver your software solution as a single clickable install.
About workshops
Format
You’ll sign up for the session you want to attend on a first-come, first-served basis. Up to 6 participants may attend a session, if full, you can sign up for the same topic at a different time. During the session, the speaker will guide the audience through the main topic but you will be able to ask him/her to deviate and cover related areas. Sometimes participants offer new ideas and solutions to a problem.
Check the
Speakers
Pursue any question or area not directly related to the core topic. Every speaker hosts at least 4 sessions which means there are about 11 to 12 simultaneous sessions running all the time with an average of 5 or 6 participants
Check the
Schedule
Flexible conference format means you can choose the best classes for you and at the best time. Some sessions will be repeated, so when you miss one, you can attend the same session later in the day or the week.