0

大規模なWebサイトの開発はほぼ完了しました。

唯一の問題は、MySQLが常にエラーを解消することです...

ここにstackoverflowに別の質問を投稿しましたが、回答が得られませんでした

だから私の質問は、Joomlaが大規模なユーザー（500万人のユーザー）に十分に適合しているか、適切なCMSソリューションであるかということです。

私はこれを開発するのにほぼ5か月を費やしました...そして今、私はQuad専用サーバー（2 GB RAM）を使用していますが、Joomlaはおそらくこの大規模なデータベースWebサイトに適したソリューションではないと感じています。

編集：私はこれを明確にしたいのですが、私はトラフィックについて話しているのではありません...その真新しいサイト。私はいくつかのテーブルの行数について話している

お知らせ下さい

MySQLサーバー情報：

MySQL error log: /var/lib/mysql/eta.etalenthunt.com.err

root@eta [~]# cat /etc/my.cnf
[mysqld]
safe-show-database
open_files_limit = 5000
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_limit=1M
query_cache_size=100M ## 32MB for every 1GB of RAM
query_cache_type=1
max_connections=100
collation_server=utf8_unicode_ci
character_set_server=utf8
delayed_insert_timeout=40
interactive_timeout=30
wait_timeout=60
connect_timeout=60
thread_cache_size=64
key_buffer=32M ## 32MB for every 1GB of RAM
join_buffer=1M
max_connect_errors=20
max_allowed_packet=16M
table_cache=2048
record_buffer=1M
sort_buffer_size=3M ## 1MB for every 1GB of RAM
read_buffer_size=3M ## 1MB for every 1GB of RAM
read_rnd_buffer_size=3M ## 1MB for every 1GB of RAM
thread_concurrency=8 ## Number of CPUs x 2
myisam_sort_buffer_size=16M
innodb_file_per_table=1
innodb_buffer_pool_size=18M ## (>= 18M)

dediサーバーXEONQUAD2GBを実行しています

4

1 に答える 1

2

わかった！問題ない。これは Joomla と Wordpress の一般的な問題であることを認識する必要があります (ここで別の質問に対する他の回答で説明したように: Is Joomla 2.5 much fast than Joomla 1.5 Querywise )

あなたは過去6か月間それに取り組んでおり、このWebサイトの背後にある巨大なデータベースをすでに知っているので、私が話していることはまさにJoomla CMSの限られた境界であなたを助けることができるものです.

これは、どの Joomla CMS 内でも簡単に対処できない問題だと思います。しかし、（私の意見では）あちこちで負荷を少し減らすことができる方法がいくつかあります。

これらの手順の両方に従うことができます。さらに多くの手順がある可能性がありますが、最初に次の 2 つを試してみましょう。

解決策 #1: データベースを 2 つ以上のデータベースに分割する (その方法について説明します)
解決策 #2: ユーザー テーブルとセッション テーブルにヒットする Joomla コアをハックする
解決策 #3: jos_users テーブルを同じ数のレコードに分割する
解決策 #4: 書き込むセッションテーブルをクリーンアップする cronjob

解決策 1:

ステップ 1: jos_users および jos_session テーブルを 2 つの新しい別個のデータベースに移動します。それらを db_jos_user および db_jos_session と呼びます。

ステップ 2: メイン データベースから jos_users および jos_session テーブルを削除します。

ステップ 3: それぞれの名前でそれぞれのビューを作成し、そのデータベース名を使用してテーブルをポイントします。

CREATE VIEW jos_users AS SELECT * from db_jos_user.jos_users;
CREATE VIEW jos_session AS SELECT * from db_jos_session.jos_session;

これにより、データベースのサイズが実際に縮小され、データベースの負荷も実際に軽減されます。Joomla は驚かず、それがビューなのか、その背後にあるテーブルなのかわかりません。

解決策 2:

ユーザー認証プラグインをハックし、データベースの新しいインスタンスを作成して別のデータベースからユーザーを認証します (次のソリューションで分割します)。どのユーザーに対してどのテーブルをヒットするかを決定するロジックを開発できます。そうすれば、データベースの負荷を軽減できる場合があります。ユーザーをそれぞれのデータベースに挿入/更新するためのロジックを実装する必要がある場合もあります。これは、コア ユーザー コンポーネントとユーザー ログイン モジュール内で作業する必要がある場所です。

解決策 3:

テーブルを複数のデータベースに分割できます。カスタム認証モジュールで、'union' または 1 つずつ使用して、単一のクエリでデータベースを 1 つずつすべてのデータベースにヒットするようにしてください (そうすれば、いくつかのデータベース ヒットを節約できます)。ユーザー名で並べ替えて、ログイン時にヒットするデータベースがわかるようにすることができます。これにより、ヒット数が大幅に減少します。

解決策 4:

セッションテーブルを消去する設定された間隔で実行されるcronジョブを作成します。セッション テーブルには、ゲストまたはユーザーに属するすべての情報が含まれています。そのため、定期的に掃除することを覚えておく必要があります。ユーザー セッションが最大 20 分間非アクティブである場合、または必要に応じて削除できる場合にも、これを行うことができます。20 分以上アクティブなユーザー セッションが自動的に削除されるか、よりユーザー フレンドリーな何かをユーザー セッションに通知する通知を Web サイトに配置する必要がある場合があります。

結論：

データベースと特に 1 つのテーブルを多くの断片にスライスするのはばかげているように思えますが、実際にはそれを行うのに理想的な時期です。Joomla/データベースに損害を与えることもありません。裏返すのはとっても簡単！

これらすべてがうまくいくことを願っています。これらすべてを一緒に実行しても問題はありませんが、作業のオーバーヘッドが発生しますが、データベースに +5mn レコードがある場合は実際には許容されます。

これらすべてのことを一緒に行う上で、これが大いに役立つことを本当に願っています。

于 2012-05-13T13:33:59.780 に答える