For you to understand how your site could benefit from multi-server scaling, let us list the components of any KVS-powered site first:
- Software logic of site/administration panel (kernel).
- Content-processing software.
- MySQL database.
- Primary content (videos and/or photo albums).
- Auxiliary content:
- Images used in page design, CSS files, JS files, ads.
- Other dynamic content
- User and category avatars.
- Video screenshots.
- Images of content providers, DVDs, channels, models.
- System content (Source files of videos and/or Source files of screenshots).
The software logic powering the site and the administration panel is your site's kernel. This system occupies very little disk space and its CPU requirements are average or below average in case your caching is set up correctly. RAM requirements of this system are between 512Mb and 8Gb.
The content-processing software system mainly requires CPU power, which, with priority settings, influences only the time needed to process content.
MySQL databases can generate high CPU load and some disk load as well.
Primary and auxiliary content require correct disk configuration. On the one hand, you need to have enough space to store your content, on the other hand, your disks need to be fast enough to serve content without delays.
System content only needs storage space.
With this classification in mind, let us take a look at some options of scaling your KVS-powered site:
- Storing videos and photo albums on remote servers / CDN.
- Migrating all your auxiliary content to remote servers.
- Video encoding and screenshot creation using remote servers.
- Moving search to a remote server, search powered by Sphinx.
- Moving MySQL to a remote server.
KVS lets you create server groups with any number of servers in every group. A group of servers stores the same content, which means adding more servers to a group decreases this group’s overall load. By adding more server groups, you increase your site’s total storage space where primary content is stored.
A server can be connected either as a local server, as a mounted folder, or via FTP (recommended).
In a group, you can balance load (weight) between your servers. For instance, if you assign a weight of 10 to one server and 1 to another, the first server will handle 90% of traffic while the remaining server will process the remaining 10%.
You can also use geotargeting; assign a group of countries to a server, and this server will process traffic from these countries only, or servers, if you do this for multiple servers.
KVS lets you use mass operations to change the storage group for video files. The software lets you configure automated storage group selection, CDN support, protect video files on remote servers from hotlinking as well as fine tune access privileges and stay secured against unauthorized access.
We feel we should address remote storage of video source files separately. By default, source files are stored not on servers in groups, but on your primary server. If the source format will be one of the formats you use on your site, we recommend setting a correct postfix (e.g. .avi or .mp4). If the source format will be a system format and will only be used to create files of other formats, you can use any postfix and any ffmpeg string. As a rule, the postfix is set to .dat here. Also, you need to enable creating other formats in this format’s settings, and set it as optional format. After that, you need to choose this format for all new videos that you upload. As a result, storage of both the source files and other formats will have multi-server support.
There are two ways for you to migrate such content to remote servers:
- By mounting a folder on a remote server.
- By syncing content with a remote server.
Mounting lets you physically store all content on a remote server, and serve the content from there as well. Syncing lets you store content on both the primary and a remote server. In this case, content will be served from the remote server. This is a simple way to make your entire system more reliable.
When you use syncing, there is a tiny delay before files on a remote server get updated. Starting from version 3.3.2, KVS lets you customize the publishing delay for new videos and photos on your site so that your content always remains fresh.
Both options let you mount or synchronize the contents folder from your root directory easily (by the time you are setting this up no videos or photos should be there) and configure serving of content from a remote server at http://contents.your_domain.com/. After that, change the URLs in admin/include/setup.php accordingly to serve all the content that you have just migrated.
You can migrate images and other design and layout elements in a similar way.
Migrating system content using synchronization makes little sense, as only your primary server needs this content. You can migrate system content using mounting. However, usually content of this type does not occupy a lot of storage space and you should not normally need to do this (if you do not store your video source files).
You can move all your content encoding tasks to a remote server. The manual describes doing this extensively, and it takes only a few minutes.
Starting from version 3.3.0, KVS lets you send data directly from the conversion server to a storage server. This considerably decreases primary server load. Enable this in conversion server settings.
You can optimize the search on your site by choosing any of these search strategies:
- Search on remote server powered by KVS.
- Search on remote server powered by Sphinx.
- Search on primary server powered by Sphinx.
The first option is the easiest. It lets you migrate the MySQL tables you need via syncing and power your search by the remote search plugin.
The remaining options are much more complicated. However, they let you achieve much better search quality and speed.
When you choose searching through Sphinx, we recommend setting this up on the primary server. This lets you make your search much better and faster. It's rare that you will need to move your search to a remote server. Still, high-traffic sites can use it.
There are numerous technical details here, so all options are set up by our tech team with the tasks your site needs to perform in mind.
This is done by your server administrators. Use this to optimize large-load sites with tens of millions of daily hits.
Usually sites are launched either on an average server (with the purpose of growing the site on the same server), or on an entry level server or VDS. If your plans are serious, please remember that it may take longer to implement your custom design, prepare content and debug your site before launch.
As most sites grow, usually the need to migrate videos to remote storage servers arises. Large volumes of video data logically require separate servers to store and serve the content. Also, servers used for tasks of this kind are usually configured in a special way while their maintenance costs are lower. KVS has all the features you may need to connect a remote server(s) or CDN to a working site.
If you need to encode large volumes of data or want to decrease primary server CPU load, you can set up a remote conversion server(s). KVS lets you do this in just a few minutes directly from the administration panel of your working site.
When your traffic is high or your optimization strategy is complex, you may also want to move auxiliary content to a remote server.
If free disk space is an issue, you may want to migrate system content or disable storing of video source files. If you want, you can delete existing video source files with a mass operation.
If your site gets a huge volume of traffic, you can move your search, the most load intensive operation, to a remote server or power it by Sphinx. The latter option will yield you better search results and faster searching. This is advanced system tuning and is carried out by our tech team under a custom program.
If you have satellite sites (usually language versions of your primary site), they can work on remote servers. They will need to remain physically close to your primary server as they use the same database.
If your system is configured correctly, you will not need to migrate MySQL to a separate server. You still can still technically do it.