пардон, ступил. Вот так должно работать:
RedirectMatch 301 "/Russian Federation" http://russia.xxx.com
пишите Russian%20Federation
Главное, чего опасайтесь - это систем, написанных парой пионеров в интернет-кафе (если, конечно, их фамилии не Джобс и Возняк ;) )
смотрите на развитость сообщества, периодичность обновлений, зайдите на живые сайты, сделанные на этих цмс.
У многих есть демо-сайты с админскими панелями - очень удобно, и помогает быстро понять, нравится ли вам подход разработчиков к вопросу.
зависит от того, как именно управлять. Чтобы просто с помощью одного набора скриптов держать несколько сайтов, то можно, как писали выше, использовать друпал. При определенной ловкости рук на нем можно даже сделать единый пул юзеров на все сайты (если это нужно, конечно). Но каждый сайт будет независимый, будет у них своя админка и настраивать их придется каждый раз заново.
Если речь идет об управлении несколькими сайтами из одной админки, нужно что-то другое. Что именно - не подскажу, самому интересно было бы узнать про такую систему.
только все-таки это не такая уж "простая" цмс. Жалоб на высокий порог вхождения достаточно много.
для небольшого портала это будет легкий перебор. Если автор топика не знает, что ему лучше, то пусть берет цмс с самым никзким порогом вхождения, ту же джумлу, напимер. Покопается, сделает первый вариант своего сайта, и уже понятнее будет, чего не хватает, что искать в других системах.
если большая таблица, он мог, например, вышибать из кэша другие запросы. Посмотрите статистику кэша через mysql: show status like 'qc%'; прежде всего Qcache_lowmem_prunes и Qcache_free_memory. Еще обратите внимание на параметр query_cache_limit - не стоит делать его слишком большим, чтобы избежать ситуации, о которой я говорил.
Другая ситуация (зависит от типа запроса), если не хватает памяти для группировок (параметр read_rnd_buffer_size, если не ошибаюсь)
Нередко бывают ситуации, когда некоторые из параметров - количество строк в таблицах, фрагментированность страниц, объем таблиц - пересекают явные или неявные пороги, такие как размеры кэша или буферов, в результате чего резко падает производительность либо из-за того, что выбранные сервером БД стратегии работы с данными перестают быть эффективными, либо сервер сам ошибочно меняет стратегию на менее эффективную.
просто у корейцев судя по всему, легче всего оказалось троянов размещать
