alexei1966

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

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

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

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

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

Впечатлен! Без шуток. Замечательные по тематике форумы. Ответил на вопросник про стенокардию - понравилось!! Знаете, как бы я решил проблему распределения контента между форумами? 1. Добавляете пользователя MySQL, который имеет право на SELECT из таблицы ibf_posts. 2. Разрешаете этому пользователю доступ к вашей базе данных извне, можно - для безопасности - с определенных хостов. И не нужно лезть в код форума-"донора" (ох, уже на вашу терминологию незаметно перелез ). Клиентский форум в любой момент забирает ровно столько контента, сколько ему нужно. Нет проблем с обновлением движка вашего форума и т.п. Для этого, конечно, надо иметь администраторский доступ к БД. Но зато сделали раз - и забыли. В общем, переходите скорее на VDS. Я вам готов помочь с наладкой на новом месте - как созреете, пишите мне в личку. До кучи. В Линуксы по умолчанию входит утилитка logrotate, которая крутит логи и может много чего делать - prerotate, postrotate, зиповать, посылать логи по почте и т.п. По умолчанию она крутит раз в неделю все логи в /var/log. Можете посмотреть документацию. Для httpd - не самый удачный выбор, потому что: 1. Надо прибивать веб-сервер, а на загруженной машине он может гаситься при включенном KeepAlive несколько минут. 2. Логи переименовываются "по цепочке", это неудобно, если предполагается их дальнейшая обработка анализаторами логов. Скажем так, logrotate - для тех демонов, доступа к формированию логов которых вы не имеете или нет желания и смысла с ними возиться.

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

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

Для разделения файлов я использую программку cronolog (http://cronolog.org/). В конфиг Апачи вместо указания файла для записи лога в этом случае пишем pipe: CustomLog "|/usr/local/sbin/cronolog /var/log/httpd/httpd-access-%Y-%m.log" combined Cronolog в данном примере будет разбивать логи по месяцам. Есть другие варианты - см. документацию. Можно воспользоваться и rotatelogs из дистрибутива Апачи, но у нее возможностей меньше. Уже существующие логи в формате common можно разбить на логи по годам/месяцам/дням программкой cronosplit. При этом варианте удобнее делать архивы логов и работать с анализаторами. Насчет установки nginx - не совсем понял вопрос. Конечно, а что может помешать администратору сервера установить программу?

Эх, дорогой FatCat, если бы у всех были такие познания в PHP и IPB, как у вас! Ну хотя бы у официальной службы поддержки IPB. Насчет поиска по файлам: получается, что один запрос у вас занимает 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. === Но самое главное - не зависать на одном хостинг-провайдере и одном тарифном плане. Если система переросла текущий хостинг или план - менять их смело.

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

Кстати, для создания значков есть куча онлайновых редакторов, можно ничего на локальную машину не инсталлировать. Например, вот этот: http://www.favicon.ru/

Кстати, Вы подали еще одну замечательную идею для ускорения форума: физически отсортировать таблицу 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 быстрее получается, чем последовательным перебором строк. Простите, если у вас VDS и вы имеете физический доступ к файлам MySQL, то почему бы не сохранять сами файлы таблиц вместо их дампов? Это ведь в MySQL абсолютно законный метод. А дампы по определению восстанавливаются долго - одна переиндексация занимает массу процессорного времени.

Чтоб я чего в этом понимал... Решил повторить ваш тест. А. Копирую в чистую базу таблицу 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% - что для статических данных нечего юзать БД вообще. И расход диска получается трехкратный.

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