レガシーシステムから新しいシステムへの移行プロジェクトがあります。新しいシステムに移行すると、移行するオブジェクトの新しい一意のIDが作成されます。ただし、私のユーザーと検索インデックスには、古いIDのURLが含まれます。これを処理するためにapacheリダイレクトまたはリライトを設定したいのですが、その多数のオブジェクトでのパフォーマンスが心配です（約500Kの古いIDから新しいIDへのマッピングがあると予想されます）。
誰かがこれをこの規模で実装しましたか？または、Apacheがこの大きなリダイレクトマッピングに耐えられるかどうかを知っていますか？
最近まったく同じ質問がありました。実用的な答えが見つからなかったので、htaccess 6 ルールを実装しました。そのうちの 3 つは 200,000 条件でした。
これは、サイズが 150 MB の htaccess ファイルを意味します。ページの読み込み時間は数秒でしたが、この特定の Web サイトを誰も使用していない半日は、実際には問題ありませんでした。しかし、翌日、サーバー全体が 400 をはるかに超える負荷で大打撃を受けました (マシンは 8 コア、16 GB RAM、SAS RAID5 であるため、通常はリソースに問題はありません)。
このようなものを実装する必要がある場合は、お勧めします。条件を必要としないようにルールを設計し、それらを dbm 書き換えマップに入れます。これにより、パフォーマンスの問題が簡単に解決されました。
http://httpd.apache.org/docs/current/rewrite/rewritemap.html#dbm
固定のマッピング セットがある場合は、ハッシュ ファイルタイプの mod_rewrite 書き換えマップを試してください。
より少ない数のルールを使用して書き直しを表現できますか？古いURLを新しいURLにリンクするパターンはありますか？
そうでなければ、私は500K以上のリライトマッピングを備えたApacheについて心配するでしょう。それは、その快適ゾーンをはるかに超えています。それでも、それはあなたを驚かせるかもしれません。
リダイレクトを処理するためだけにデータベースベースのアプリケーションを作成し、マッピング自体をデータベースに保存する必要があるように思えます。それははるかに良くスケーリングするでしょう。
これは古いトピックですが、皆さんは解決策を見つけましたか?
RedirectMatch開発者が htaccess を使用して、ファイル内で使用する 30,000 以上の URL をリダイレクトしているケースがあり.htaccessます。
このファイルのサイズを考えると、パフォーマンスと管理のエラーが心配です。
私がお勧めするのは、すべての古い URL には次のようなものがあるためです。
/sub/####
これをデータベースに移動して作成すること
/sub/index.php
すべてのリクエストをリダイレクト:
www.domain.com/sub/###
に
www.domain.com/sub/index.php
次に、データベースで新しい URL と古い ID を検索できるため、index.php にリダイレクトを送信させます。
このようにして、すべての HTTP リクエストではなく、古い URL に対する HTTP リクエストのみが再書き込みプロセスにヒットします。