Перейти к контенту
  • 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 оптимизирован по скорости до предела и в "геометрической прогрессии" время не увеличивается. Правда, приходится платить за это местом на диске

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

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

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

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

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

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

Гость
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Ответить на вопрос...

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

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

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

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

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

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

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

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