Перейти к контенту
  • 0

Большой форум


Chrno

Вопрос

Моему форуму пошел пятый год и стали одолевать мысли о дальнейшей жизни.

Ситуация такова: форум порядка 500 тысяч записей, одновременно ходят порядка 100 пользователей, в день 500 хостов, 3200 визитов. Сейчас живу на VDS (750 МГц/1536 Мб адресуемая/512 Мб гарантированная). Возникает ощущение, что достигнут некий предел. И запросы оптимизировались, и полнотекстовый индекс с таблицы постов убран (работает сфинкс), но крутится вот-вот впритык (в моменты пиковых загрузок падают сервисы - чаще всего php).

Вопрос первый: по количеству записей. Имеет смысл создать второй архивный форум и туда сбрасывать старые записи?

Сейчас разворачивать бекап базы - задача на пол-дня (очень здоровый выходит).

Вопрос второй: При какой загрузке наступает момент неизбежного перехода на выделенный сервер? Хотелось бы оттянуть этот момент, делалось все на голом энтузиазме и денег на сервер взять неоткуда.

Буду раз любым мыслям на эту тему.

Ссылка на комментарий
Поделиться на других сайтах

Рекомендуемые сообщения

  • 0

ИМХО, все решается проще.

 

1. Архивы - сгоняются все сообщения старого топика в первый пост, остальные посты удаляются; получается некое подобие версии для печати. Так уменьшается число строк в таблице сообщений. Пример в действии

 

2. Сообщения больше 4000 символов невыгодно хранить в БД, лучше вынести в файлы, да еще и зипануть на лету, чтобы места на хостинге меньше кушали.

У меня для этого сделано:

 

а. Все обращения на чтение из таблицы сообщений дополнены:

if( strlen($row['post'])<3)$row['post'] = $std->extract_archived_post($row['pid'], "arc");

 

б. Все обращения на запись в таблицу сообщений дополнены:

if(strlen($this->post['post']) > 4000)
{
$arc_poct_str = $this->post['post'];
$this->post['post'] = " ";
}
if($arc_poct_str != "")$std->create_archived_post($this->post['pid'], "arc", $arc_poct_str);

 

в. Сами функции:

	function extract_archived_post($pid, $j_type)
{
	global $ibforums;

	$arc_path = ($pid-$pid%1000)/1000;
	$arc_path = $ibforums->vars['base_dir']."arc/".$arc_path."/";
	$arc_file = $pid%1000;
	$arc_file = $arc_path.$arc_file.".".$j_type;
	if(file_exists( $arc_file.".gz" ))
	{
		@ob_start();
		readgzfile($arc_file.".gz");
		$archived_post = @ob_get_contents();
		@ob_end_clean();
	}
	else
	{
		$archived_post = "";
	}
	return $archived_post;
}

function create_archived_post($pid, $j_type, $txt)
{
	global $ibforums;

	$arc_path = ($pid-$pid%1000)/1000;
	$arc_path = $arc_path = $ibforums->vars['base_dir']."arc/".$arc_path."/";
	$arc_file = $pid%1000;
	$arc_file = $arc_path.$arc_file.".".$j_type;
	if(file_exists($arc_file))unlink($arc_file);
	if($txt != "")
	{
		if(!file_exists($arc_path))mkdir($arc_path, 0777);
		$fh = gzopen($arc_file.".gz", "wb5");
		gzwrite($fh, $txt);
		gzclose($fh);
	}
}

 

 

В результате спокойно живу на шареде. Сейчас из 160К постов в БД меньше 50К; вес таблицы постов всего около 40 Мб. На хостинге всего 24 Мб оперативной памяти php, процессор довольно мощный, но у меня лишь 1% (пиковая до 2,5%) ресурса процессора - форум спокойно тянет каждый вечер по 60-70 одновременных посетителей, выдерживал без напряга и моменты в 200+ одновременных, плюс поисковые боты пасутся непрерывно; да что говорить, со всеми поисковыми ботами уже больше 2М хитов в месяц.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Да, 1.3.

http://vesvalo.net/uploads/user-1-1236695747.png

Пиковая нагрузка 1400 хитов в минуту, средняя 200 хитов в минуту.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

FatCat - браво! Истинно юниксовое решение! Действительно, если пост закрыт - это по сути статический файл. И доставать его с диска раз в 100 быстрее, чем из БД.

 

Позвольте все же несколько вопросов.

 

1. Точно ли, что именно длинные поля MEDIUMTEXT в MySQL приводят к резкому замедлению базы данных? Тестировали ли вы это специально, или просто таким образом разгрузили БД, уменьшив количество обращений к ней?

 

2. Как быть в этом случае с полнотекстовым поиском по форуму, особенно по архиву?

 

3. Не пробовали вы просто поставить прокси-сервер? Это, в общем, стандартный ход в подобных ситуациях: один сервер на заднем плане обслуживает php/БД, другой - быстро отдает кэшированные запросы. Причем для сообщений из архивного форума можно поставить большое время жизни, т.е. в каталоге кэша прокси-сервера будут лежать те же самые текстовые файлы.

 

ЗЫ. Повторюсь, ваш пост - бальзам на душу. :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0

1. Тестировал. Получилось, что время выполнения запроса растет в геометрической прогрессии от числа записей в таблице. Для заполненных однотипным текстом ibf_posts по 1000 символов в посте под денвером запрос селект * лимит 15 дал такие цифры (всего записей в таблице => секунды выполнения запроса):

50 000 => 0,2

100 000 => 0,4

150 000 => 0,8

200 000 => 1,5

...

450 000 => зависание mysql

 

2. Есть механизм поиска по файлам, ищет в принципе практически так же быстро, как и эскуэльный поиск; но когда объем данных слишком велик, любой поиск будет жрать слишком много времени и ресурсов.

http://phpforum.ru/index.php?showtopic=0&a...ost&p=69609 - тут хорошо расписано. В работе проверено, ищет вполне прилично и довольно шустро. Сейчас в планах переделать под поиск по зипам, и опробовать на сайте. Так как каждый архив сопоставлен своему айдишнику поста, результаты выводить естественно через форум.

 

3. Я на обычном гиговом шареде. И хочу на нем оставться как можно дольше. :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Понял, спасибо!

 

А можно уточнить, что за запрос вы выполняли к тестовой таблице ibf_posts? Было в вашем запросе обращение к индексам или нет? Имею в виду, что в таблице 6 индексов, а результаты тестирования похожи на полный перебор строк.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Запрос как при выборке сообщений для обычного отображения страницы темы:

SELECT * 
FROM ibf_posts WHERE topic_id =7098
ORDER BY pid ASC LIMIT 0, 15

Для чистоты эксперимента делал в пхпадмине без джоина других таблиц.

 

 

То же и при DELETE...

http://phpforum.ru/index.php?showtopic=14715 - вот тут обсуждали

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Чтоб я чего в этом понимал... :D Решил повторить ваш тест.

 

А. Копирую в чистую базу таблицу ibf_posts без данных.

 

Б. Делаю тестовый топик: 10 записей, в каждом сообщение длиной около полутора килобайт (в реале, конечно, посты короче, но мы ж тестируем :) ).

 

В. Этот топик "размножаю" с соответствующим увеличением pid и topic_id.

 

Данные таблицы ibf_posts: длина строки - 1528 байт, на диске 4491 байт.

 

Тест 1. 100000 строк в таблице, 10000 топиков; данные занимают 146 Мб, всего - 428 Мб. Захожу в phpMyAdmin, копирую туда ваш запрос из предыдущего поста.

 

SELECT *
FROM ibf_posts WHERE topic_id =7098
ORDER BY pid ASC LIMIT 0, 15

 

phpMyAdmin сообщает: Запрос занял 0.0024 сек.

 

Тест 2. 20000 строк в таблице, 20000 топиков; данные занимают 291 Мб, индекс 567 Мб, всего - 859 Мб.

 

phpMyAdmin сообщает: Запрос занял 0.0029 сек.

 

Для очистки совести вводил разные значения id - время исполнения запроса не менялось (значит, индексы работали). Уменьшил максимальное значение памяти скриптам до 4 Мб, чтоб жизнь медом не казалась - все то же самое. MySQL версии 5.0.45.

 

Дальнейшие эксперименты, полагаю, проводить нет большого смысла, т.к. таблица и так уже почти под гигабайт. Машина достаточно скромная, да и в принципе при таких размерах индекса здесь тормозить будет не процессор, а диск. Похоже, что-то все же у вас со структурой данных... ;)

 

А вот в чем с вами согласен на 150% - что для статических данных нечего юзать БД вообще. И расход диска получается трехкратный.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
В. Этот топик "размножаю" с соответствующим увеличением pid и topic_id.

То есть, айдишники сгруппированы по десяткам?

 

Таблица БД - это по сути файл. И индекс - это второй файл. Физически - кластеры на диске.

Когда записи подряд, головка винчестера как встала в нужную точку, сразу десяток и прочитала.

А когда айдишники вразнобой, головке винчестера придется 15 раз точку входа искать...

 

Базу я брал исходную от живого форума в 50 000 сообщений, айдишники вразнобой.

 

 

Теперь попробую смоделировать Ваш эксперимент приближенный к живой обстановке. И MySQL 5.0.45 для совместимости, и машинку побыстрей.

SELECT * 
FROM `ibf_posts` WHERE `topic_id` = 'xxxx'
ORDER BY `pid` ASC LIMIT 0, 15

48,488 строк, 69.7 MB таблица.

Реальный топик: 0,0045 сек (топик с частыми сообщениями) - 0,0055 сек (топик скороткими постами заявок о членстве в группе, айдишники сильно вразнобой)

Функцией "копировать топик" делаю копию этих топиков, чтобы айдишники постов встали по порядку. 0,0035 сек.

 

Итак, имеем:

0,0035 - айдишники по порядку;

0,0045 - айдишники вразнобой в пределах пары сотен;

0,0055 - айдишники вразнобой по всей базе.

 

 

Удваиваю базу и повторяю те же запросы по тем же топикам:

0,004 - 0,006 - 0,009

 

 

Кстати, сделал-таки поиск по зипованным файлам. Но нагрузочно вышло. 24 Мб под зипом / 150 Мб текста - все это в 3500 файлах - поиск занимает до 4 секунд на юникс-сервере и до 20 секунд под виндовс на ноутбуке.

Но подозреваю, что будь все это добро в БД - поиск был бы не намного быстрей...

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Кстати, Вы подали еще одну замечательную идею для ускорения форума: физически отсортировать таблицу ibf_posts по полю topic_id. Поскольку, видимо, самый частый вид запросов - как раз обращения к конкретному топику. По Вашим тестам видно ускорение до 2 раз.

 

Так все-таки: что у Вас с таблицей произошло, что время обращения к ней росло в геометрической прогрессии? Теперь ведь, насколько понимаю, такого эффекта не наблюдается, и результаты сходны с моими.

 

Поиск по зипованным файлам: не пытались посмотреть утилитой time, сколько и чего кушает Ваш алгоритм? Простой перебор по строкам 150 Мб текста занимает времени всего ничего. У меня как раз лежит на диске текстовый файл в 156 Мб; простой grep ищет в нем строку за 0.2 сек. Правда, если его зазиповать, а строку искать при динамической раззиповке (zcat filename.gz | grep ), время поиска увеличивается в 6 раз. Да и памяти при этом расходуется немерено, на загруженном сервере поиск точно перекосит.

 

Может, все-таки держать отдельно здоровый текстовый файл, куда слить все архивные топики?

 

Насчет скоростей поиска по правильно организованной БД. Добавляю в поле post последней строки таблицы слово 'Caramba', задаю по нему поиск с учетом того, что поле post проиндексировано:

 

SELECT pid

FROM ibf_posts

WHERE MATCH post

AGAINST (

'Caramba'

)

 

Запрос занял 0.0255 сек при общем объеме текста около 300 Мб. Раз в 20 быстрее получается, чем последовательным перебором строк.

 

3200 визитов. Сейчас живу на VDS (750 МГц/1536 Мб адресуемая/512 Мб гарантированная). Возникает ощущение, что достигнут некий предел. И запросы оптимизировались, и полнотекстовый индекс с таблицы постов убран (работает сфинкс), но крутится вот-вот впритык (в моменты пиковых загрузок падают сервисы - чаще всего php).

Вопрос первый: по количеству записей. Имеет смысл создать второй архивный форум и туда сбрасывать старые записи?

Сейчас разворачивать бекап базы - задача на пол-дня (очень здоровый выходит).

Простите, если у вас VDS и вы имеете физический доступ к файлам MySQL, то почему бы не сохранять сами файлы таблиц вместо их дампов? Это ведь в MySQL абсолютно законный метод. :D А дампы по определению восстанавливаются долго - одна переиндексация занимает массу процессорного времени.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Кстати, Вы подали еще одну замечательную идею для ускорения форума: физически отсортировать таблицу ibf_posts по полю topic_id. Поскольку, видимо, самый частый вид запросов - как раз обращения к конкретному топику. По Вашим тестам видно ускорение до 2 раз.

 

Так все-таки: что у Вас с таблицей произошло, что время обращения к ней росло в геометрической прогрессии? Теперь ведь, насколько понимаю, такого эффекта не наблюдается, и результаты сходны с моими.

Вот и Вы уперлись в проблему фрагментации информации.

Я с ней впервые столкнулся еще в 93-м, когда занимался медстатистикой на FoxPro.

Как мне объяснили специалисты по железу, проблема кроется в том, что таблица - это файл; чтение из таблицы - это все равно чтение с диска: головка винчестера ищет точку начала записи, затем считывает; итого, есть 2 операции: поиск точки начала и само считывание. Процедура поиска точки начала на маленьких файлах настолько мала, что ей можно почти пренебречь, но с ростом размера файла она растет в геометрической прогрессии.

 

На фоксе гениальное решение нашел Саша Тустановский: таблица индексируется, затем копируется, при этом получаем файл, где записи индексированы физически.

На sql... Хмммм... Наверное можно отсортировать физически просто путем создания новой таблицы и последовательным выполнением инсертов... Надо попробовать ради любопытства.

 

 

 

Поиск по зипованным файлам: не пытались посмотреть утилитой time, сколько и чего кушает Ваш алгоритм? Простой перебор по строкам 150 Мб текста занимает времени всего ничего. У меня как раз лежит на диске текстовый файл в 156 Мб; простой grep ищет в нем строку за 0.2 сек. Правда, если его зазиповать, а строку искать при динамической раззиповке (zcat filename.gz | grep ), время поиска увеличивается в 6 раз. Да и памяти при этом расходуется немерено, на загруженном сервере поиск точно перекосит.

В цикле несколько тысяч повторяющихся действий: открыть файл, раззиповать, осуществить поиск. Под виндой тоталкомандер то же самое делал минуты 3 наверное. 20 секунд под виндой и 3-4 секунды под юниксом - это очень быстро.

 

Меня скорее интересует другой вопрос: для меня не столь критично время поиска; я на шареде, и мне критична загрузка процессора, чтобы не погнали с хостинга. Как бы ограничить процесс по ресурсам; пусть работает дольше, но с небольшим потреблением ресурсов.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

А если делать по-хорошему, то придется копировать таблицу (ibf_posts_prepared), в которую писать инсерты по одному в отсортированном порядке, стирать ibf_posts, переименовывать (?) prepared в posts

Запускать процесс по мере необходимости.

Наверно сильно много толку это даст для заглохших тем, в которые уже не будут писаться ответы, ведь ответы будут писаться физически в конец таблицы, тоесть вероятно далеко от отсортированных заранее.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
А если делать по-хорошему, то придется копировать таблицу (ibf_posts_prepared), в которую писать инсерты по одному в отсортированном порядке, стирать ibf_posts, переименовывать (?) prepared в posts

Ага!

Так тоже можно ускорить.

И это решит проблему тормозов на показ старых топиков, но не избавит от тормозов на новых, а именно в них как раз самая большая активность.

Плюс поиск будет тормозить и жрать ресурсы.

 

И, что немаловажно для шаредхостинга, - дисковое пространство. У меня сейчас прирастает по 15-20 Мб в месяц в виде сообщений. Хочется подольше умешаться в пол-гига на хосте. Благодаря выносу в зипы архивов и просто крупных сообщений вопрос увеличения платы хостеру сильно отодвигается в будущее. :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0

значит сортировать надо не только просто по ид тем, но и по дате последнего ответа, например

в самое начало файла писать со самой старой датой последнего ответа

получится, что активные темы будут шариться в конце файла

 

мне же подобные улучшения сильно далекая перспектива, имея свое железо, не просто у хостера отдельный сервер, а машину, стоящую в центре сетевого управления института, плюс не сильно активный форум, посещаемый только институтом, это все еще как-то далеко

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Мир вашему дому! ;)

 

1. Физически отсортировать таблицу по ключу несложно:

 

SELECT * INTO OUTFILE 'ibf_posts.sql' FROM ibf_posts ORDER BY topic_id

 

Дамп тестовой таблицы в 200000 записей занял 6 секунд. Ключ topic_id составной, туда уже входит и post_date, но в принципе для наших целей достаточно отсортировать только по topic_id, чтобы информация считывалась с диска за один проход. Обратно в БД данные данные грузятся с помощью LOAD DATA INFILE. Ничего сложного, но надо будет повозиться маленько с ESCAPED BY, FIELDS TERMINATED BY, LINES TERMINATED BY.

 

Однако все эти ходы с упорядочением файла на диске - только подчиненные задачи по сравнению с грамотным составлением индексов и запросов.

 

2. Повторю вопрос к FatCat. Я ведь все эти тесты затеял только потому, что FatCat меня всерьез напугал возрастанием времени запроса к таблицам в геометрической прогрессии. Так все же - что это было? Или Ваши тогдашние результаты сейчас не воспроизводятся?

 

3. Насчет быстрого полнотекстового поиска перебором строк в файле: Вы, скорее всего, измеряете скорость дискового кэша, увы. После первого перебора весь ваш файл оказывается в кэше и дальнейшие циклы мерят только скорость обращения к оперативной памяти. Поэтому и получается "несколько тысяч за 4 секунды". Более близкий к реалиям, полагаю, все же мой результат - 0.2 секунды на 150 Мб grep'ом. Grep - программа маленькая и неплохо оптимизированная.

 

А с кэшем возможны смешные вещи. Лет десять назад я на спор написал на Visual Basic программульку в несколько строк, которая брала с диска текстовый файл в 100 Мб и перекодировала из одной кодировки в другую со скоростью около 20 Мб/сек. Причем программка была на классическом VB без прямых обращений к памяти, а машина - Pentium 100 или около того. Запускали 100 циклов и действительно - получались неслыханные скорости. Время считывания файла с диска и размещения его в оперативке при этом как-то растворялось в общем тайминге. :D

 

4. Еще вопрос к FatCat. А что у Вас за тарифный план? Я поглядел - у NewHost.RU свой IP с Апачей предоставляется уже в плане за 250 рублей и 500 Мб диска. Это уже не shared. Если Вы на этом плане или более высоком, то можете спокойно поднять кэширующий прокси-сервер и закрыть вопрос раз и навсегда. Добавьте к этом любой компилятор PHP и с процессорными ресурсами проблем не будет.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

В MySQL есть специальный арзхивный тип таблиц - MERGE.

Суть в том, что большая таблица хранится не в одном файле, а в нескольких - это и есть MERGE таблицы. И если мы селектим новый топик, то сканируется только тот фрейм, в котором он хранится, а не читается все MERGE тома.

 

Это короче что-то напоминает партиционирование на оракле.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
SELECT * INTO OUTFILE 'ibf_posts.sql' FROM ibf_posts ORDER BY topic_id

Мне очень стыдно, но я не знал о такой возможности.

Поиграюсь. Если получится потом заливать обратно такой дамп юниксом - это будет классно.

 

 

2. Повторю вопрос к FatCat. Я ведь все эти тесты затеял только потому, что FatCat меня всерьез напугал возрастанием времени запроса к таблицам в геометрической прогрессии. Так все же - что это было? Или Ваши тогдашние результаты сейчас не воспроизводятся?

У меня поменялись с того времени php+sql с 4-х на 5-е.

Но вряд ли в этом разница.

Скорее я что-то забыл, уж больно цифры не совпадают. По старым записям, селект к 50-тысячной таблице занимал 0,02 секунды, а сейчас занимает 0,004 - в 5 раз меньше.

Может быть я при первых тестах запускал не простой селект, а джойнил мемберов...

 

В этот раз я не прогонял тесты до 500К, а сделал лишь для 50 и 100 К записей.

Если будет время - попробую прогнать до 500К физически несортированых, посмотреть время выполнения.

 

 

Вы, скорее всего, измеряете скорость дискового кэша, увы.

Под виндой на денвере: Включаю компьютер, загружаю винду, стартую денвер, запускаю поиск - откуда быть кешу? Поиск занимает 20 секунд. Запускаю повторный поиск (сейчас верю, что кеш может быть, хотя винда у меня экономная) - те же 20 секунд.

ИМХО, из этих 20 секунд бОльшую часть времени занимают именно дисковые операции: у меня ноутбук, и винчестер сами понимаете не быстрый...

 

На сервере может быть файлы прокешировались при заливке на сервер?

Что первый поиск, что последующие - все примерно 3,5 секунд при поиске по одному слову, и чем длинней подстрока поиска - тем больше времени занимает поиск. Поиск по 1 букве и по одному слову из 5-6 букв занимают примерно одинаковое время, а вот если больше 5-6 букв - тогда время начинает расти пропорционально длине подстроки.

 

 

4. Еще вопрос к FatCat. А что у Вас за тарифный план? Я поглядел - у NewHost.RU свой IP с Апачей предоставляется уже в плане за 250 рублей и 500 Мб диска. Это уже не shared. Если Вы на этом плане или более высоком, то можете спокойно поднять кэширующий прокси-сервер и закрыть вопрос раз и навсегда. Добавьте к этом любой компилятор PHP и с процессорными ресурсами проблем не будет.

У меня свой апач, но нет доступа к конфигурации пхп (он один на сотню площадок) и я просто не умею поднимать сервера, я всего-навсего врач, по иронии судьбы вынужденный заниматься еще и этой работой.

 

 

В MySQL есть специальный арзхивный тип таблиц - MERGE.

Заманчиво звучит. А как-то можно сделать таблицу ibf_posts таким типом таблицы?

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Касательно дисковых операций.

 

Вообще, записи, которые идут друг за другом на диске - это интересная теория. Но, скажите, как быть с явлением фрагментации? Ведь не секрет, что крупные файлы физически записываются в разные места. А дефрагментатор их потом собирает поближе друг к другу.

 

Чем больше операций удаления\записи, тем мельче фрагменты.

 

Или как быть с RAID-массивом, которые на серверах используются повсеместно? Я в этом не очень хорошо разбираюсь, но вроде бы там, грубо говоря, файл пишется кусками на все винты сразу.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Эх, дорогой FatCat, если бы у всех были такие познания в PHP и IPB, как у вас! Ну хотя бы у официальной службы поддержки IPB. :D

 

Насчет поиска по файлам: получается, что один запрос у вас занимает 4 секунды. Это очень много, к тому же тратится много ресурсов на открытие/закрытие файлов, поиск по каталогам и т.п. Повторюсь, лучше содержание согнать в один большой текстовый файл - выигрыш получится десятикратным.

 

Попробую обобщить мысли по оптимизации IPB.

 

===

 

1. PHP прекомпиляторы:

 

Alternative PHP Cache (APC) - http://pecl.php.net/package/apc

eAccelerator - <a href="http://www.eaccelerator.net/" target="_blank">http://www.eaccelerator.net/</a>

 

Есть и другие, эти наиболее известны. Что делают: хранят в кэше откомпилированные скрипты PHP. Выигрыш - до 10 раз. На скриптах типа "Hello world!" выигрыш минимальный, Друпал ускоряют примерно в 6 раз.

 

eAccelerator богаче в настройках, несколько быстрее. APC официально поддерживается командой PHP, по достоверным сведениям, будет включен в PHP 6. Документация по APC уже включена в документацию PHP 5.

 

Я включил APC для тестового форума, далее замерил скорость обращения с помощью программы ab (Apache Benchmark из стандартной поставки). В целом скорость возросла в 2-2.5 раза. При этом в кэше находится около 9 Мб откомпилированных скриптов - вот это все хозяйство Апаче без акселератора приходится компилировать каждый раз.

 

Необходимые условия. Доступ к php.ini, библиотека подгружается оттуда.

Минусы. 1. Немного съедается памяти для кэша. 2. Все акселераторы страдают падучей болезнью - segmentation fault и сервер умер. ;) Лечение: пишем скрипт, который проверяет каждую минуту из крона, не оканчивается error_log строчкой с текстом "Segmentation fault" и если да - перезапускает веб-сервер.

 

2. Двухуровневая структура доступа: легкий проксирующий сервер на front-end - Апача с php на back-end.

 

На front-end работает быстрый кэширующий сервер, который занимает мало памяти. Он отдает статический контент - графику, таблицы стилей, джава-скрипты. За динамическим контентом он обращается к Апаче, которая крутится на другом порту, например, 8080.

 

В качестве front-end сервера стандартно используется squid (http://www.squid-cache.org/), он входит в поставку большинства сборок Линукса. Хорошие отзывы я слышал также об nginx http://sysoev.ru/nginx и lighttpd http://www.lighttpd.net/.

 

Разгрузку машине такая схема дает кардинальную. Тем более что сервер приложений можно развернуть на другой машине вообще. Кроме того, на короткое время можно кэшировать и динамические запросы: например, если установить TTL 60 секунд, а за 1 минуту новые топики читает в среднем 10 человек, то число запросов к серверу приложений и БД по этим топикам снизится в 10 раз.

 

Минусы. 1. Необходим доступ администратора к серверу. 2. При кэшировании динамического контента придется отказаться от возможности выбора разных скинов на форуме, т.к. в URL выбор скина не отражается.

 

3. Упорядочение таблицы ibf_posts.

 

Физически упорядочить записи в таблице, чтобы строки, принадлежащие одному топику, следовали в файле друг за другом:

 

Дамп таблицы: SELECT * INTO OUTFILE 'ibf_posts.sql' FROM ibf_posts ORDER BY topic_id

Обратная загрузка: LOAD DATA INFILE ...

 

Кроме всего прочего, подобная перегрузка таблицы приводит к пересозданию индексов и резкому уменьшению их размеров на диске.

 

Позволяет ускорить выборку, по тестам FatCat, примерно в 2 раза. Кстати, возможно, именно пересоздание индексов и приводит к ускорению запросов.

 

Также - для этих целей можно пользоваться утилитами mysqlcheck и myisamchk.

 

4. Быстрое архивирование/разархивирование БД

 

Если права доступа позволяют - вместо дампа и дальнейшего поштучного восстановления строк в БД можно просто физически копировать файлы таблиц MySQL *.frm, *.MYD, *.MYI. В поставку MySQL входит специальная утилита mysqlhotcopy.

 

===

 

Но самое главное - не зависать на одном хостинг-провайдере и одном тарифном плане. Если система переросла текущий хостинг или план - менять их смело.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Пора менять название темы на более умное/ разделять тему?

 

Кстати у меня вопрос по настройкам httpd

Лог httpd-access.log растет в одном файле. Нехорошо это тем, что он уже 20+ ГБ (!!!)

Можно где-нибудь в конфиге указать ограничение его размера, чтоб он автоматически разбивался на части при достижении оного (в php.ini видел нечто подобное)?

 

+ реально ли установить nginx по ssh (имея возможность зайти под рутом туда)?

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Для разделения файлов я использую программку cronolog (http://cronolog.org/). В конфиг Апачи вместо указания файла для записи лога в этом случае пишем pipe:

 

CustomLog "|/usr/local/sbin/cronolog /var/log/httpd/httpd-access-%Y-%m.log" combined

 

Cronolog в данном примере будет разбивать логи по месяцам. Есть другие варианты - см. документацию. Можно воспользоваться и rotatelogs из дистрибутива Апачи, но у нее возможностей меньше. Уже существующие логи в формате common можно разбить на логи по годам/месяцам/дням программкой cronosplit.

 

При этом варианте удобнее делать архивы логов и работать с анализаторами.

 

Насчет установки nginx - не совсем понял вопрос. Конечно, а что может помешать администратору сервера установить программу?

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Насчет поиска по файлам: получается, что один запрос у вас занимает 4 секунды. Это очень много, к тому же тратится много ресурсов на открытие/закрытие файлов, поиск по каталогам и т.п. Повторюсь, лучше содержание согнать в один большой текстовый файл - выигрыш получится десятикратным.

На сегодняшний день у меня число обращений к архивированным сообщениям в сотни раз превышает число полнотекстовых поисков.

При простом запросе страницы открывать 150-метровый файл для считывания в нем пары десятков килобайт текста - безумие.

Потом это сейчас он 150-метровый. Форум сейчас растет в геометрической прогрессии, и сейчас прирост информации на форуме составляет 15 Мб в месяц. Даже если форум перестанет расти, через пару лет файл станет полугиговым. И это тоже открывать при каждом обращении к странице?

 

 

 

Лог httpd-access.log растет в одном файле. Нехорошо это тем, что он уже 20+ ГБ (!!!)

Можно где-нибудь в конфиге указать ограничение его размера, чтоб он автоматически разбивался на части при достижении оного (в php.ini видел нечто подобное)?

У моего провайдера можно запускать по крону предустановленный скрипт:

#!/bin/bash
for a in ~/log/*http*log
do
mv -f $a.0.gz $a.1.gz 2> /dev/null
mv -f $a $a.0 2> /dev/null
done
gzip ~/log/*.0
apache_restart

 

У меня он отрабатывает раз в неделю: лог зипуется, зип прошлой недели переименовывается; логу даляется и начинает писаться заново.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Угу, сейчас на поиск уходит 4 секунды, а через пару лет будет уходить минута - и он станет бесполезным. А вот полнотекстовый поиск в MySQL оптимизирован по скорости до предела и в "геометрической прогрессии" время не увеличивается. Правда, приходится платить за это местом на диске - но разве это проблема? Впрочем, как этюдная задача - очень даже интересно.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
полнотекстовый поиск в MySQL оптимизирован по скорости до предела и в "геометрической прогрессии" время не увеличивается. Правда, приходится платить за это местом на диске

Когда я буду готов платить местом на диске - сделаю копию архивных файлов в одном размеченном файле и ребилд копии раз в сутки по крону.

Сейчас же с дисковым пространством дефицит. Проект некоммерческий, и на нем нет и никода не будет ни рекламы, ни других способов заработка. Форумчане честно скидываются на хостинг, и я не хочу вешать на их плечи дополнительные затраты.

Пока же полнотекстовый поиск по файлам доступен только администраторам, остальным доступен поиск по неархивированным топикам и удобная форма гуглового поиска.

Ссылка на комментарий
Поделиться на других сайтах

Присоединиться к обсуждению

Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.

Гость
Ответить на вопрос...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

Зарузка...
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.