We use different stacks to handle connections to the various services we offer. The following will briefly describe our HTTP and HTTPS stack.
Each customer runs separate and dynamic sets of services within our hosting cluster. Supported services include webservers, appservers, databases, caches and filesystems.
This flexibility allows us to adapt to individual needs. We can scale out individual layers to attack bottlenecks and handle different load patterns.
We suggest to deploy two or more services of the same type to be able to provide basic failover and load-balancing.
What makes us special is that we can do that without asking you to write specialized and cluster-aware applications. Simply write code, deploy and let us take care of the rest. You might be interested in our technical limitations.
We try hard to combine high-availability and high-performance with ease of use.
Just click on one of the layers in the graphical representation on the right to display a brief description and show links to the software we use.
Our services are powered by state of the art Free Open Source Software.
The routing layer consists of services that help us to provide single entry points and automatic recovery in case of possible problems (IP and service failover).
We also use it to ensure high performance using best-practice load-distribution and load-balancing techniques.
Software used on this layer includes:
Fine-grained per-domain configurations to serve static files, pass requests to applications, control caching and more.
We analyze the requested URI in order to search for redirects, rewrites and various mappings.
- Auth mappings allow you to use access authentication with custom groups and users.
- Static media mappings allow you to serve static files directly out of the filesystem. We support transparent fall-through to a given application (in case the requested file was not found), custom expiry headers and efficient application controlled downloads.
- Application mappings allow you to pass requests to your application. We support all possible combinations to map an application on multiple paths from multiple domains. This makes multi-domain apps easy and efficient. We support caching of dynamic content, which can be controlled per mapping as well as using fine-grained HTTP cache-control headers.
This layer is used for HTTPS termination. We combine HTTP and HTTPS configurations and give your application all the information required to handle any use case.
We're using nginx here because of its outstanding performance.
If you configure the upper layers correctly, only dynamic requests will make it here, helping to relieve your applications and guarantee fast responses.
Configure caching on your webservers, set HTTP cache-control headers, and your website will enjoy being slashdotted any time.
We abstract appservers as WSGI and PHP containers. Every container can be deployed on multiple nodes. Every deployment can run a configurable amount of workers, represented by the product of processes and threads. This allows you to fine-tune based on the bottlenecks of your application (IO or CPU). Excessive requests are queued to protect workers from overloading and allow them to use external resources as efficient as possible.
We're using a stripped Apache with mod_wsgi for our Python WSGI containers. This combination is robust and stable and supports nearly every WSGI application out there. Workers are pre-forked and your application is loaded in RAM to handle requests as fast as possible.
We're using a stripped Apache with mod_fcgid for our PHP containers. This allows us to fully support htaccess and nearly every PHP application out of the box. We support a configurable PHP APC to keep compiled scripts in RAM.
We give you full control over your databases:
- Manage databases, users and permissions
- Use command line tools on our shell servers to dump, restore or administrate.
- Use SSH tunnels to connect from remote and work with custom clients.
- Use phpMyAdmin or phpPgAdmin
This layer is used for the following services:
We're using a replicated and highly-available filesystem per customer. All nodes running your services get the necessary filesystem access.
This design makes our hosting cluster transparent to your application. We recommend against filesystem-backed caching or session storage though. We provide faster and more efficient services for that, e.g. memcached or MongoDB.
We use caching mechanisms in production mode to speed up file access to local filesystem speeds. We support a per-domain development mode without caching. Use versioned filenames to allow fast updates while keeping caches hot.