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

[Chrno]

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

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

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

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

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

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

[alexei1966]

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

 

Тем более что на групповом хостинге вы можете сделать все абсолютно верно, но форум все равно будет жить кое-как, потому что нагрузка на сервер MySQL у провайдера превысит норму. А IPB только для вывода главной страницы использует 14 запросов.

 

И тогда все равно вам придется заплатить лишние 10-15 долларов в месяц, чтобы уйти на виртуальный сервер и самому регулировать ресурсы, которые будет получать движок форума. Тогда возникнет вопрос - зачем нужны были такие сложные и, повторюсь, по-своему замечательные действия по переписыванию кода IPB... И стоили ли они тех 10-15 долларов в месяц, которые вы пока выигрываете в борьбе за оптимизацию.

[FatCat]

Сложно-то как все.

Все намного сложней.

Я строю систему под вполне определенные задачи. Мне не очень важен поиск по старым сообщениям. При этом хранение информации в файлах жизненно необходим для межсерверного обмена информацией, когда на другом домене и на другом сервере импортируется информация из форума. Можно конечно инклайдить php-файл из форума, который будет брать информацию из форумной БД, при этом снова нагружая и так самый ненадежный компонент системы. А можно просто вытянуть нужные файлы и обработать информацию на сервере-получателе.

 

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

 

А вот уже чуть более функциональное создание: http://stenocardia.ru/ На хосте лежит только index.php да графика; вся информация берется с форума в совсем другом домене, пока еще на одном сервере, но это уже не имеет значения.

 

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

[alexei1966]

Впечатлен! Без шуток. Замечательные по тематике форумы. Ответил на вопросник про стенокардию - понравилось!!

 

Знаете, как бы я решил проблему распределения контента между форумами?

 

1. Добавляете пользователя MySQL, который имеет право на SELECT из таблицы ibf_posts.

 

2. Разрешаете этому пользователю доступ к вашей базе данных извне, можно - для безопасности - с определенных хостов.

 

И не нужно лезть в код форума-"донора" (ох, уже на вашу терминологию незаметно перелез ). Клиентский форум в любой момент забирает ровно столько контента, сколько ему нужно. Нет проблем с обновлением движка вашего форума и т.п.

 

Для этого, конечно, надо иметь администраторский доступ к БД. Но зато сделали раз - и забыли. В общем, переходите скорее на VDS. Я вам готов помочь с наладкой на новом месте - как созреете, пишите мне в личку.

 

 

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

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

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

До кучи. В Линуксы по умолчанию входит утилитка logrotate, которая крутит логи и может много чего делать - prerotate, postrotate, зиповать, посылать логи по почте и т.п. По умолчанию она крутит раз в неделю все логи в /var/log. Можете посмотреть документацию. Для httpd - не самый удачный выбор, потому что: 1. Надо прибивать веб-сервер, а на загруженной машине он может гаситься при включенном KeepAlive несколько минут. 2. Логи переименовываются "по цепочке", это неудобно, если предполагается их дальнейшая обработка анализаторами логов. Скажем так, logrotate - для тех демонов, доступа к формированию логов которых вы не имеете или нет желания и смысла с ними возиться.

[Arhar]

мне нравится запуск по крону скрипта FatCat

не нравится там только apache_restart - зачем оно нужно?

может просто touch $a и его соответствующий chmod сделать, ведь рестартуем мы,как я понял, только для того, чтобы создались убранные нами файлы?

[alexei1966]

Нужно, нужно, поверьте на слово. Повторюсь, в Апаче возможно гораздо более тонкая настройка логов - лучше воспользоваться ей. На следующем этапе вам захочется прикрутить к логам webalizer или awstat - снова придется голову ломать, как данные для анализа не потерять. Или такая задачка, как хранить логи в архиве на предмет ретроспективного анализа (взломы, атаки, производительность и т.п.) - придется как-то их дополнительно именовать, сортировать записи и т.п., потому что с logrotate и им подобными программами у вас будет получаться набор файлов вида .log/.log.1/.log.2 и т.д., а что у них внутри - от названия не зависит. Многие программы не позволяют нормально настраивать и крутить свои логи, для них logrotate и придумали, а в Апаче прокрутка логов уже заложена в стандартном пакете.

[Arhar]

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

можно я буду спрашивать у специалистов?)

[FatCat]

Знаете, как бы я решил проблему распределения контента между форумами?

 

1. Добавляете пользователя MySQL, который имеет право на SELECT из таблицы ibf_posts.

 

2. Разрешаете этому пользователю доступ к вашей базе данных извне, можно - для безопасности - с определенных хостов.

Программист, работавший до меня, именно так и делал.

И быстро столкнулся с проблемой: сетка сайтов довольно большая; я видел пиковую активность более 50 000 запросов в минуту по всей сетке. Представляете, если на один sql-сервер падает такая лавина?

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

 

Я лишь упростил систему: все обращения только по айдишникам топика или поста; обращения на входе интвалятся; имя и путь к файлу определяются айдишником.

 

 

 

мне нравится запуск по крону скрипта FatCat

не нравится там только apache_restart - зачем оно нужно?

Иначе не обнулится файл лога.

А чем он так плох?

Вот его код:

#!/bin/sh
kill -HUP `cat ~/run/httpd.pid`

Делов-то на пол-секунды...

[alexei1966]

Программист, работавший до меня, именно так и делал.

И быстро столкнулся с проблемой: сетка сайтов довольно большая; я видел пиковую активность более 50 000 запросов в минуту по всей сетке. Представляете, если на один sql-сервер падает такая лавина?

Многовато запросов будет... Но:

 

1. MySQL очень не хило оптимизирован, и запросы, кстати, кэширует. Так что завалить его на выделенной машине простыми запросами очень сложно. На невыделенной - да, часто тот же Апач отъедает у него ресурсы и оба сервера уходят в даун.

 

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

 

Быстрее уж точно не получится. Т.е. на уровне интуиции: раздача кэшированных файлов легким сервером вроде Squid'a будет заведомо быстрее и экономнее по ресурсам, чем передача статических файлов через здоровенный скрипт PHP тяжелой Апачей.

[FatCat]

чем передача статических файлов через здоровенный скрипт PHP тяжелой Апачей.

Не так.

Давай лучше покажу.

http://vesvalo.net/index.php?act=Print&amp...n=0&limit=1 - страница с выводом одного сообщения; айдишник сообщения 69602.

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

Если я хочу получить этот текст на другой сайт, я не буду ломиться через index.php, я запрошу напрямую http://vesvalo.net/arc/69/602.arc.gz

Таких запросов даже шаред спокойно держит до 500 в секунду.

[alexei1966]

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

 

...Анекдот вспомнил. Последняя фраза: "Но смекалка какова!" А вообще круто сделали!

[Sannis]

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

можно я буду спрашивать у специалистов?)

Если не отходить от функциональности Апача, то можно воспользоваться http://httpd.apache.org/docs/1.3/logs.html#piped. Если хочется удобнее управлять логами, например чтобы в именах архивных файлов была полная дата или ещё что-то, то можно добавить в dayly/weekly cron скрипт такого вида, и при необходимости допиливать его.

[alexei1966]

Собственно, это то, о чем я писал несколькими постами выше. Но! Если уж связываться с внешними утилитами, которые крутят логи на живом сервере, логичнее делать не graceful, а полный рестарт.

[xRay]

FatCat

При поиске по zip-ваным файлам ты не построишь поисковый индекс это и есть потолок в скорости поиска таким макаром. Вот к примеру поисковый движок с построением индекса http://risearch.org/rus/risearch_php/index.html .

Можно еще скинуть не в zip-файлы а в базу SQLite и уже по этой базе поиск мутить. Но это все дикий изврат.

 

Как вариант насчет старых тем: Разбиваем таблицу постов на более мелкие таблицы например по годам (или если надо то можно и по месяц + год).

Да возни в коде движка море, но новые темы тормозить из-за старых уже не будут. Был подобный мод, он там был перенос постов просто в архивные посты и соответственно в одну архивную таблицу.

[FatCat]

FatCat

При поиске по zip-ваным файлам ты не построишь поисковый индекс это и есть потолок в скорости поиска таким макаром.

Повторюсь, возможность поиска для меня сейчас стократ менее значима, чем дисковое пространство.

 

Если же поиск станет важней экономии мегабайтов, есть простое решение: кешировать не результаты поиска, а цельный текстовый файл: при первом поиске одновременно с выдачей результатов поиска пишется проиндексированный текстовый файл; имя файла содержит 10 цифр, берущихся из time(). При повторных поисках используется уже текстовый файл; по истечениии заданного времени делается перекеширование уже в фоновом режиме: результаты поиска отдаются еще по старому файлу, затем файл удаляется и генерируется новый.

[alexei1966]

Повторюсь, возможность поиска для меня сейчас стократ менее значима, чем дисковое пространство.

Иногда Кулибины рождаются из Плюшкиных.

 

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

 

Кстати, вот еще ход придумался на основе того, что реализовал уважаемый FatCat. Запускаем по крону раз в час скрипт, который шерстит ibf_posts и генерирует зипованные файлы: один топик - один файл. Естественно, база файлов перегенерируется не полностью, а обновляются/создаются только обновленные/новые топики. Поскольку поля post_date и topic_id проиндексированы, такое обновление происходит очень быстро.

 

Преимущества: 1. Не надо лезть в код форума. 2. Не нужна ручная редакторская работа по объединению постов топика в один длинный пост. 3. "Раздавать" таким образом можно все топики, а не только старые, архивные. 4. Посадить на раздачу можно "легкий" сервер вроде nginx/lighttpd, которые, кстати, можно поднять на непривилегированном порту в рамках тарифного плана уважаемого FatCat.

[FatCat]

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

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

Удалил полнотекстовый индекс, и все просто летает.

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

Для пробы переключил настройки на поиск по LIKE - и сразу тормоза при поиске.

Оставил у себя полнотекстовый поиск без полнотекстового индекса: звучит дико, но работает шустро и качественно, я доволен.

[WildRAID]

Лютое шаманство какое-то..

 

Возможно, я что-то путаю, но когда полтора года назад копался с полнотекстовыми индексами, оно мне писало ошибку при попытке сделать MATCH(...) AGAINST(...) по полям, на которых FT индекса нет.

 

А Сфинкс не пробовали? В теории, он намного круче и FT, и, конечно, LIKE.