1つのDrupalコアで数百のサイトを実行するのは理にかなっていますか？
当社がサポートしているサイトは100以上あり、サブドメインとしても表示できます。 Drupalコアを1つだけ使用してこれらのサイトをすべて実行することは、技術的な観点から合理的ですか。
技術的には、あるべきではありません。しかし、十分なサーバーリソースがあったとしても、私のアプローチを再考します。考えられるいくつかの問題。それらは本当に小さな迷惑であり、回避策があることに注意してください。ネットワークの各サイトを非常に深刻なサイトにする必要があり、サーバー上のファイルが少なく、更新が簡単であると期待している場合、それは悪い考えだと思います。
sites.phpファイルは大きくなります。sites/sites.phpファイルで使用するsettings.phpファイルを指定できます。そのファイルは、ネットワーク内のサイトの数とともに大きくなります。ただし、$GLOBALSに100個の構成を保存する時代には、これは問題になりません。すべてのモジュールを
sites/all/modulesフォルダーに配置すると、モジュールページの読み込みが遅くなりますが、いくつかのサイトでのみ使用する必要があります。コアモジュールまたは共有モジュールの更新では、 1つの間違った動きをすると、誰もが知ることになります 。
別のrobots.txtを使用することはできません。
実際、「既知のファイル」のほとんどを使用することはできません。 favicon.ico、Apple-touch-icon、Bing検証ファイル。
複雑なvhostsファイルと
.htaccessに挨拶してください。私は太っている人なので、そうあるべきです。
確かに、パフォーマンス上の理由からスタックを分離する方が理にかなっているキャップがあります。
@Ayesh Kはいくつかの良い点を述べました。これらの問題のほとんどに対処する方法があります。
- sites.phpは必須ではありません。
- これは本当です。申し訳ありません:)ただし、[siteA.com]にのみ必要なモジュールを
/drupal/sites/siteA.com/modules/。その後、それらのモジュールは他のサイトのモジュールリストに表示されません。 - 仰るとおり。間違いなく、drushを使用して更新を行ってください。事前にバックアップを作成し、障害時に自動ロールバックします。
- @Drupalistが述べたように https://drupal.org/project/robotstxt 。
- ここには、少なくともファビコンには解決策があると思います。
- Httpサーバー用のモジュラースタイルのインクルードがこれに役立ちます。 （例として、AegirがNginxに対して行うことを見てください）。
この議論で私の頭の中で際立っていたのは、OPcodeキャッシングです。 opcacheやAPCなどを使用すると、シングルスタック（マルチサイト）のメリットが得られると思います。
主に次のことを決定します。
- ハードウェアを最大限に活用してパフォーマンスを向上させる方法。
- Ayeshによって言及された問題を解決できる場合（またはそれらは使用する問題ではありません）。