AEM/CQ5

In an ideal AEM repository configuration, the segment store will be stored entirely in memory.
Most AEM repositories have a data store which is too large to allow this, therefore we always separate them out.
With the segment store stored entirely in RAM, you will see a massive increase in performance. The physical disk (Bare Metal), vDisk(VMware), EBS Volume (AWS) or Managed Disk (Azure) leveraged for the segment store should also be high performance RAID10 storage ideally SSD/Flash based with a sufficient amount of IOPS available.
When sizing your AEM application servers, make sure to allocate enough RAM for an appropriate sized Heap,

Maintenance:

By splitting the segment store and data store, you then have more flexible options for repository maintenances.
By having a combined repository, the only way to reclaim disk space is is via a tar compaction (or RevisionGC).
This can be a lengthy activity, depending on the number of changes to the repository — and in some AEM versions must be completed with the AEM instance offline.
This means specific publishers will be out of the load balancer pool and your author will be offline during the maintenance.
Separating the data store from the segment store allows you to do an online DatastoreGC, which can be very fast and can be done with the instance still up.
In newer AEM versions with repositories under 1TB these maintenance processes — when run regularly (weekly) — can reclaim tens or hundreds of GB in a few seconds or minutes.
Additionally, having moved to a split FileDataStore model, you will (on AEM 6.4) be able to take advantage of a new “tail compaction” maintenance task,
which can be run online with even greater frequency, and only compacts data which has been added since the last compaction, giving you the advantage of always having an AEM instance which is lean and performant.

Storage flexibility:

Separating out the segment store and data store allows you to place each on their own storage media.
Segment stores can be placed on SSD volumes or Flash storage tiers for high performance, while your data store can leverage less expensive lower performance storage.
If leveraging AWS for you AEM deployment, you can use S3 for the data store, which is really inexpensive and can be shared between publishers and author, thus reducing storage costs even more.
Splitting these as well as logging onto separate volumes allows simultaneous writes to the different disks, further improving performance and removing potential bottlenecks.

Statement - Handling Vanity URLs Using the AEM Dispatcher Module

Solution:

Recent updates to the AEM Dispatcher module (since version 4.1.9 of the module) allow authors to directly control vanity URLs from within the Author UI, and these are automatically pushed out to the publishers, which then expose them to the dispatchers.

Steps to be followed:

On your AEM Publish nodes, download and install the VanityURLS-Components (https://www.adobeaemcloud.com/content/marketplace/marketplaceProxy.html?packagePath=/content/companies/public/adobe/packages/cq600/component/vanityurls-components)
package from Adobe Package Share, or pull it down and install it manually in /crx/packmgr.
Go to the /useradmin on your Publish instance and allow “Read” permission to /libs/granite/dispatcher/content/vanityUrls for the “Everyone” group. Do this by double-clicking the “Anonymous” user, Then go to “Permissions” and check the “Read” column for the above path.
If you don’t have an allow-all in your dispatcher configs, add a filter rule in the dispatcher to allow the vanity URL to be called on Publish instance:

/0100 { /type "allow" /url "/libs/granite/dispatcher/content/vanityUrls.html" }

/0001 { /type "deny" /glob
"/libs/granite/dispatcher/content/vanityUrls.html" }

/vanity_urls {
    /url "/libs/granite/dispatcher/content/vanityUrls.html"
    /file "/tmp/vanity_urls"
    /delay 300
}

Re-start Apache.
The file defined at the /file setting is not automatically created/updated at the time interval set at /delay, but only when a request is made that fails the /filter rules of your dispatcher. On fail, it checks to see if the file is there —
if not, it will generate and use it by pulling /libs/granite/dispatcher/content/vanityUrls.html from the publisher. If it is there, and not older than /delay seconds, it will use it. Finally, if it is older than /delay seconds, it will update it from the Publish instance and use it.

	/vanity_urls {
	/url "/libs/granite/dispatcher/content/vanityUrls.html"
	/file "/tmp/vanity_urls"
	/delay 300
	}