The diagram below illustrates a simple setup for the web services process that will be fine for most venues that only need one machine for web listeners. The simply configuration is designed so that all traffic goes through single inbound ports and is load balanced at each machine.

It can also be used in the vast majority of situations with moderate web sales requirements, even if you have:

• one or more machine dedicated to web services -and-
• multiple cores on each machine (4 or more is better) -and-
• machines that are roughly equivalent -and-
• each machine can have services for all outlets

Traffic flow for Simple Setup of Theatre Manager Server

• All web traffic for 'tickets.yourvenue.org' flows through the router and firewall on ports 80 and 443
• The firewall passes traffic to Apache on ports 80 and 443
• Apache has a load balancer that forwards traffic to each Theatre Manager Server machine on port 5000.
• If and web service on the Theatre Manage Server need a template web page, it asks apache for it (on port 80 or 443)
• All completed web pages flow back to the patron.

For this setup to work, each machine must have:

• One or more second generation listener processes
• One of more classic listeners, sufficient to handle the load requested of it from that machine

The custom setup option can route traffic through more pathways and should only be used for complex environments, requiring the extended capabilities.

The web services can be customized to be used in situations with many outlets, high load and specific needs. The simple setup handles most situations and automatically load balances within machines. The custom setup allows you to load balance traffic across multiple machines. Since most venues do not have this need, the following setup is rarely implemented. Please consult with Arts Management Technical Support if you think you want to implement this option.

Consider this option if you:

• have multiple outlets,
• need to load balance traffic across multiple machines of varying capability,
• have very large onsales (typically thousands of seats to sold in a short time) and high traffic spikes on occasion

Traffic flow with the Theatre Manager Server

• All web traffic for 'tickets.yourvenue.org' flows through the router and firewall on ports 80 and 443
• The firewall passes traffic to TM Listener on ports 80 and 443
• TM Listener passes all requests to the Theatre Manager Server using the built in Load Balancer.
  • The IP/Ports for each of the Theatre Manager Web Server must be specified in the extra/httpd-balance.conf file
• If the Theatre Manager Server can handle the web request, it will do so immediately.
• If the Theatre Manager Server cannot handle the request, the following happens:
  • it contacts TM Web Server at port 8111 to talk to the virtual server (this is an internal port and is not exposed to the internet). However, make sure your firewall allows internal communication to this port.
  • The Theatre Manager Server hands the response to the customer

The Theatre Manager Server (middle of diagram) is the key component in the process. When it is started:

• It is running as a service
• You cannot monitor or control it directly.
  • You can observe it indirectly using the web listener logs from the web monitor inside TM
  • You can also monitor some activity by viewing the console logs/event logs or using an activity monitor/task manager to see the CPU it uses.
  • You can control the behaviour of the second generation listener by opening a web browser and using the url http://127.0.0.1:3012 on the machine with the second generation listener

Make sure you have enough permitted connections in postgresl.conf setup for the postgres database to handle the processes you configure to run by contacting the second generation server at http://127.0.0.1:3012. Typically, Depending on the number of CPU's on the machine you have, you may see:

• cores-1 'Theatre Manager Server' processes start. Meaning a 4 core machine will start 3 processes, an 8 core machine will start 7 processes, a dual 4 core with hyperthreading will start 15 process.
• 3 'Logging' connections will be started for logging activity to the database. These are used by the new server
• 1 or more 'Housekeeper' connections are started to handle worker activity. Worker activity currently means things like:
  • Cleaning up expired carts on a periodic basis
  • Sending out emails automatically that are due to go, whether created by an eblast or from the customer when they ask for their password or get a purchase confirmation. The email worker is very fast -- over 12,000 emails/hour.