Fork Drupal for High Performance purposes.

Today Drupal becomes a very big part of the Web. It's a very powerful tool for creating a small or medium site of any kind with minimal effort. It may satisfy almost all business needs on the market.

But there is a big gap between business card website which have 50 visitors per day on 10 pages and a high performance site which should handle 1k+ visitors per day and serve 500k+ pages.
Right now I can see a lot of contrib modules which are solving some of the performance problems that will certainly appears while your site traffic is growing.

There are several different approaches for making Drupal core able to handle a lot of traffic, but I believe that optimizing layers outside Drupal core is not efficient. The core should be optimized as much as possible by design.

So why not to gather all those modules, use that experience and make a separate "Drupal-HA" core which will include all community solutions?

Right now I'm talking about D6 and D7. All the high-performance stuff seems not ready for production in D8 yet and seems like work on contrib modules (which will make D8 high-performance-ready) is only began.

Here how I see it:

• Better caching API. D8's cache tags and cache contexts engine looks promising and may be implemented in some way by using procedural approach in D6 and D7 as separate cache implementations.
• Include the D8 strategy about "caching all". In ideal a simple request should not make a database call at all. That will opens a lot possibilities for horizontal scaling.
• High-Performance-ready installation profiles that will include Memcache/Redis/APC support out of the box.
• Core-provided tools for cache warmup. I think when client opens the page it should be already in cache. If page is static then entire cache could be fetched by using default Drupal cache system. If page is dynamic then all the objects/arrays/data that are needed to build and render the page should be cached. It's crucial for user experience when "everything works fast" on your site and it also define positions of your site in SEO Ranking.
• Provide entry point to separate database storages in the same way as cache storages. For example, all data which is needed for bootstraping Drupal may be stored in a small separate sqlite database file. All content-related stuff may be moved somewhere else, even to NoSQL storage thus Drupal could be less SQL-dependent. Results from this is that database connections, cache connections, other storage connections should be opened only on demand, that will give the additional speed boost.
• Support of Master/Slave installations out of the box as in autoslave module by core (probably for Master/Master too). Database replication is a key for High Availability and Data Reliability.
• Load modules by demand. When you have a big site with a lot of functionality with 50+ installed modules, each page request is making a vain inclusion of all of them. There is a workaround: menu router contains data which module and files it should load and module itself contains dependencies list in .info file. Also module_exists() and module_invoke_all() may load necessary modules.
• Refashion and add into the core some developer tools and profilers in the way when they may be launched on a production site without hitting performance for your visitors. It could be very useful to discover bottlenecks that may appear only on production.
• Make simple clustering tools that will work with other software for HA, e.g. health check url for HAProxy or Nginx.
• Simple lightweight console that shows cluster nodes status and entire cluster status will be very useful. It also may monitor all resources status that cluster is using in a realtime, e.g. Database availability, Master/Slave status, Cache backends status, free space left on disks and memory, CPU usage. Also some custom pluggable user metrics via hooks should be supported. Yes, I'm aware about the bunch of existing monitoring systems but most of them are very heavy and hard to configure. Drupal knows about itself much more and may provide a complete working solution out of the box.
• Entry point to change core elements theming. That will allow to include some modern libraries easily (like Bootstrap or Foundation).
• Documentation and guidelines for different optimization strategies and environment setups. Examples in which cases one or another optimization strategy or tool may be suitable.
• Since D6 will be closed on Feb 2016 and D7 support will be ended in 2-3 years, the both HA-branches should have a LTS (Long Term Support) feature.

For the better chances to persuade Drupal community to make a right decision I've gathered some statistics from our local Web counter about "big", "medium" and "small" websites in Kazakhstan.
As a "Big" site I mean a website with more than 50k visitors. "Big" site companies usually have a big developers department, they develop and support their own engines, they use a stack of different solutions and not interested in Drupal. As a "medium" site - all sites between 50 and 50k visitors per day, they are a "target group" for Drupal-HA.
Yes, our country is a very small part of WWW and not yet growed as well as Europe/US/Japan segments does but I think the statistics could be representative.
The numbers for one day are:

• "Big sites": 36 sites total, 43,9 million hits per day total;
• "Medium sites": 1316 sites total, 6 million hits per day total;
• "Small sites": 2270 sites total, 92k hits per day total ("business card website");

As you can see there is a big number of small (possibly Drupal) sites but it's a drop in the ocean.
Drupal can't be used by "Web Giants" but a lot of the "medium" sites may use Drupal if it will possess appropriate tools and experience. Yes, in the "medium" sites list there may be Drupal sites with a lot of hits per day but they probably have only static content (with agressive caching) or already went through painful optimization process.

If you doubt in supporting of "obsolete" D6 I already done the nasty job and backported D7 tests into D6. That's my private D6 fork with performance fixes. I don't suggest to use them, it just can be an example how everything may work. Slightly modified D6 with core tests and core modules tests may be cherry-picked.

Thank you for the attention.