Тема превращается в некий девелоперский блог.

С файловой базой закончено. Строки останутся с пробелами, как и сейчас. Не зачем ужимать , так как и так она загружается в 2 раза быстрее.

Сейчас приступил к самой важной хирургической операции: созданию "длинных" тем. Всё сделаю горздо проще: при удалении/перемещении сообщения, мы просто заменяем текст сообщения на нечто вроде "(Удалено! - кем-то)/(Перенесено! - туда-то)".
Помню, на одном из форумов был такой слишком ретивый админ, который постоянно тасовал сообщения из одной темы в другую, видимо полагая, что делает доброе дело - тусует то по тематике, причём доходило до абсурда: читаешь тему и видишь, что человек беседует с кем-то, чьих сообщений в теме давно нет, с пустым местом... Такие покоцанные темы читать невозможно, и кроме плевков ничего на ум не приходит. Никогда не понимал, отсутствие хотя бы на месте удалённого сообщения, напоминания о том, что оно здесь было.
Если же оставить хотя бы сообщение о том, что оно удалено, все ссылки если таковые были на него в других сообщениях останутся валидными и при переходе по ссылке сразу будет видно, что сообщение удалено. Друзья, давайте немножко думать и о пользователях тоже и об их интересах, а не только о собственном всемогуществе. Это первое..
Второй этап - налаживание модуля подсчёта онлайн посетителей. Это вторая важнейшая вещь.
Третий этап - новая система шаблонов, тем более, что собственный шаблонизатор уже написан и протестирован. осталось только преобразовать в новый формат все шаблоны.
Всё, приступаю к неотложному вмешательству в тело пациента.

Если делить список сообщений, да и список тем, то трудно будет обеспечить сортировку по автору, названию и т.п. Если список один, то его легко отсортировать, но если список разделён по нескольким файлам, то придётся прежде открыть все эти файлы и собрать список в один, и только потом сортировать. Геморрно. А если тема ~ 5000 сообщений? надо будет открыть ~ 100 файлов?

А если пойти по другому пути: по пути оптимизации и разгона форума? Например если применить несериализованную текстовую базу, то скорость загрузки файла обьёмом к примеру 60 мегабайт будет 0,35 сек. Как я уже писал сериализированный массив такого обьёма загружается более минуты, честно говоря я перестал ждать загрузки такого массива через минуту.. На более лёгких массивах разница составляет 32 раза по скорости. К тому же в такую базу легко добавлять новые элементы без полной перезаписи массива, так как это позволяет сама файловая система ОС.
В таком случае мы сохраняем все фичи существующего форума, при этом разгоняем его. Мы можем иметь длинные темы примерно до 60 мегов, и форум по прежнему не будет тормозить. Сейчас темы делятся при обьёме около 300-400 килобайт.
Так стоит ли овчинка выделки? Не проще ли перевести форум на текстовую базу? Ведь сейчас база в общем-то не текстовая, а скорее просто отображения php сущности на файл.
Хочется услышать ваше мнение. Перевести на много более лёгкая задача, чем переделывать практически весь код.

Ещё раз протестировал, но теперь уже не на массивах с числом элементов доходящим до полумиллиона, а на массивах с числом элементов несколько тысяч, но с большим обьёмом информации в массиве. Оказалось, что функция сериализации ведёт себя очень хорошо, и главное быстро, практически не уступая, а иногда и превосходя загрузку текстовой базы, и даже формат var_export..
30 мегабйтный массив с числом элементов 10 000 грузится 0,15 сек., а через var_export 0,57 сек.
То есть где число элементов очень большое, эта функция тормозит, а на маленьком хоть и с большим обьёмом, всё нормально.
Думаю, при таких результатах незачем городить огород с новым форматом, тем более, что сериализированный массив, многие не знают, может хранить в себе бинарные данные, а var_export не может. Преимущество исключительно важное!
Так что остаёмся на старом формате

Flat,
Теперешнюю структуру нет смысла менять, т.к. для одинаковых данных:

• serialize дольше выполняется, чем json_encode
  
• unserialize выполняется быстрее, чем json_decode
  
• для данных до 70М serialize текст занимает меньше, чем json
  
• у serialize практически неограниченная вложенность структур, у json - до 256 уровней
  
• в serialize можно хранить экземпляры классов со всеми свойствами, в json - только публичные свойства
  
• unserialize может полностью восстановить экземпляры классов, json_decode - восстановит свойства в StdClass

Дополнительно хочу порекомендовать Вам выставить для тестов у себя настройки как на реальных хостингах:

• Суммарная нагрузка за день (статистическая нагрузка) не должна превышать 50 cp на CPU, 1000 единиц на MySQL.
  
• Запрещается использование процессами процессоров сервера более 60% в течение 5 секунд и более 10% в течение 25 секунд. В случае превышения данного лимита процесс завершается.
  
• Максимальное число процессов пользователя не может превышать 40.
  
• Максимальное использование оперативной памяти на процесс (memory limit): 128 Мб
  
• Максимальное время исполнения скрипта (параметр max_execution_time): 120 секунд.

Единственно, что напрягает, так это то, что для массивов с большим числом элементов serialize начинает безбожно тормозить. Например есть массив 500 000 элементов, к примеру файл users.php(на нём и проверялось). serialize грузит его 30 сек, а var_export 3 сек. То есть если форум имеет более 100000 пользователей то, всё, приплыли. Но тут можно поделить users на несколько файлов, что может несколько спасти положение.
Некоторые тут задавались вопросом: при каком числе пользователей форум будет тормозить, где предел? Вот он, предел. То есть без перестройки структуры данных мы производительность не поднимем.

Спасибо, учту.
-------------

По делам текущим.
Плотно взялся, за создание "длинных" тем. Это самое главное, что не хватает exbb. Если это реализовать то форум приблизится вплотную к гигантам.. При создании темы, в папке data/forums/forum(id)/создаётся папка с темой. В этой папке формируются сами файлы topic(id).php по 60 сообщений в файле, а также несколько подсобных файлов, которые обслуживают тему. Это уже реализовано: автоматически создаются папки и файлы.
По моим прикидкам, такая система не будет тормозить если в теме будет до 60 000 сообщений... Это достаточно даже для супер-форумов.. Далее могут возникнуть определённые задержки при удалении/перемещении сообщений, если удаляемые/перемещаемые сообщения находятся в начале темы. Если они в конце темы, как обычно и бывает, то тормозов не будет и тема может иметь хоть миллион сообщений.
Сообщения удаляются физически. Протестировал: даже при открытии 1200 файлов на это уходит менее секунды, поэтому удалять будем физически с перестройкой темы, естественно с он-лайн проверками на целостность в процессе пересоздания, чтобы ничего не потерять.
Сейчас занимаюсь пагинатором в topics.php, чтобы всё корректно выводилось. Штатная функция пагинатора останется такой же.


Изменены некоторые поля в list.php в файле топика. Например раньше было поле 'state' где было записано состояние темы: состояние темы: open - открыта, closed - закрыта, moved - закрыта и перемещена. Теперь вместо одного поля 'state' два поля - 'isOpen' и 'isMoved', при этом у нас тема может быть одновременно и открыта и перемещена, а не как сейчас. Как сейчас это бред сивой кобылы в тёмную ночь..
Такой же бред кобылы наблюдается и в allforums в полях [stview], [stnew], [strep]. Вместо того, чтобы сделать отдельные поля для каждой группы по типу 'stviewGe' , 'stviewMe', 'stviewMo', 'stviewAd' - кто может просматривать форум? - гости 1/0, пользователи 1/0, модераторы 1/0, администраторы 1/0. Пр этом мы можем по каждой группе выставить права на просмотр, чтение, запись и т.д. Это я уже давно хотел изменить. В этом случае легко выставляются права в любом порядке по группам.

Реализовал систему "длинных" тем, за исключением переноса и удаления сообщений. А так всё пофиксил: множественное прикрепление сообщений, пагинацию, добавления и т.д. Всё работает как часики . Голову пришлось поломать конкретно. Осталась только реализация переноса и удаления, самая трудная и важная. И хотелось бы посоветоваться, насчёт того, как реализовать это дело..
Тут всего два варианта, как мне представляется:
1) Так как у нас в папке с темой файлы по 60 сообщений в файле, то чтобы всё корректно работало, при удалении надо перераспределить сообщения между этими файлами так, чтобы в каждом из них по прежнему было по 60 сообщений за исключением последнего файла либо первого файла если этот первый файл и последний в теме.
Допустим нам нужно удалить ВСЕ сообщения пользователя во всех темах, форумах и т.д. В данном случае операция перестройки всех тем с его сообщениями довольно затратна и опасна, так как придётся перестраивать все темы, в которых находятся его сообщения. А хочется всё-таки реализовать такую функцию, как удаление все сообщений разом. В этом недостаток подобного способа.
2) В данном случае мы удаляем только тело поста пользователя(текст сообщения), а само сообщение помечаем как удалённое, без перераспределения сообщений между файлами. Данная операция довольно быстра и гораздо менее опасна, так как не требует перестройки темы. При просмотре темы, в которой есть удалённое сообщение, пользователь видит на месте удалённого сообщения текст "удалено".
Конечно, могут найтись люди, которым может не понравится такой вариант, хотя я не знаю причин, при которых людям не нужно видеть информацию о том, что здесь когда-то было сообщение. Но ведь мы не удаляем сообщения пользователей каждый день не так ли? Только сообщения откровенных спаммеров - да, а сообщения зарегистрированных пользователей наоборот чаще подвергаются редактированию админами, чем удалению. Ведь каждый админ заинтересован, чтобы пользователи как можно больше постили своих сообщений, это полезно для продвижения форума. А если часто удалять сообщения без особой на то причины по типу мне не нравится этот человек, то с такого форума люди просто разбегутся.. Да, это будет определённым, незначительным ограничением, но не является ли таковым, сегодняшнее деление тем на множество фрагментов? Мне кажется что первое ограничение ни в какую не может сравнится со вторым, по неудобству для пользователей. А для админов это является скорее чисто психологическим мотивом..
Во втором случае можно довольно быстро удалить все сообщения юзера без опасности что-то запороть, как в первом случае.
Интересно ваше мнение по данному вопросу, так как от его решения будет зависеть каким будет новый движок форума в будущем(данный форк движка).

Flat.
Есть у меня одна идея для хранения произвольной информации в файлах прямого доступа.
Возможно Вы попробуете ее реализовать.

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

2) Каждая хранимая структура имеет уникальный идентификатор (по которому ее можно добавить/удалить/изменить).

3) Есть файл для быстрого доступа к данным (файл-индекс) - файл с наборами данных фиксированной длинны, а именно хранит массив структур вида


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

Остается реализовать несколько операций над такой структурой с учетом возможного одновременного параллельного доступа:
- вставка нового блока
- изменение существующего блока
- удаление существующего блока

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

Я не только думал над этим, но и реализовал часть функций по работе с подобной базой, только без индексного файла. С индексным файлом можно реализовать записи с разной длиной. Я знаком по крайней мере с двумя подобными наработками, которые присутствуют в сети.
В чём тут загвоздка именно для нас?
В том, что гораздо проще не париться, а перевести базу на sqlite, при этом у нас будет та же самая база прямого доступа в одном файле, который для нас доступен. Но тут возникает момент: файл-то доступен, но его практически невозможно редактировать вручную. Даже сериализированный файл уже трудоёмко редактировать, ведь надо высчитать длину поля, его тип, да и правильно всё прописать, что не каждый сможет корректно сделать. А представим, что у нас база прямого доступа. В этом случае файлы становятся абсолютно нередактируемыми. И чтобы исправить что-то в такой базе, надо будет пройти через огонь, воду, и медные трубы.. Править бинарные файлы та ещё мука. Так уж лучше вообще на мускул перейти, там хотя бы следят за целостностью данных. Но это не наш путь.
Нам нужна база, которую легко отремонтировать самим, своими силами. Если слетит мускул, то это катастрофа, если слетит файловая база есть шансы всё поправить в ручном режиме. Я видел админов, которые теряли на мускуле половину загрузок, к примеру, хотя были опытными сисадминами, работающими в компаниях по разработке web приложений. А теперь представьте менее опытного человека.. Думаю не надо будет говорить, что малейшая ошибка в мускуле его может поставить в ступор. Малейшая ошибка в такой базе может поставить под вопрос существование всей базы целиком!
Вот поэтому я и отказался от идеи файлов прямого доступа.
Существующую базу можно легко ускорить на порядок, применив разделение больших файлов типа users на более мелкие фрагменты. Например имеем один файл со всеми emailами, один файл со всеми никами. Или для большей оптимизации делим файлы по номерам пользователей: в файле от 1 до 100 номеров, от 101 до 200 и так далее, или по алфавитному принципу для адресов почты, ников и пр.
Таким образом ускоряем всё на порядок и больше. и имеем форум с 500000 пользователей без мускула.
Вот это и есть наш путь.

Вы пришли к самому правильному выводу - нужно использовать sqllite3 для хранения данных в файлах. Очень много плюсов. Да и в редактировании данных вручную совсем нет необходимости - есть множество готовых клиентов: DB Browser for SQLite, SQLite Manager, DBeaver, SQLiteStudio.

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

Ну, да - если использовать файлы прямого доступа , то есть у же готовая ОТЛИЧНАЯ база для этого, но... во-первых - существует уже много движков которые поддерживают sqlite из коропки - mybb, flatbb, punbb и др, поэтому незачем городить огород и лучше поставить соответствующий форум, во-вторых, как я уже говорил, мы находимся и разрабатываем ФАЙЛОВУЮ версию, причём версию, которой нет равных среди файловых движков. И двигаться нужно в сторону продолжения развития данного движка. То есть чисто на файлах. Поэтому дальнейшие разговоры по поводу перевода exbb на мускул или ещё куда-нибуль ничего хорошего exbb не дадут, мы только потеряем своё время..
А менять надо много чего. Развитие прекратилось потому, скажу вам по секрету, потому, что этому препятствует сама механика структур данных движка. Все боятся большой работы по реструктуризации оного. А я не боюсь: давно уже копаюсь в его внутренностях, поэтому стал опытным хирургом.
К сожалению, все разработчики разбежались, и мне придётся самостоятельно принимать решения.

Изменил, концепцию удаления/перемещения сообщений в теме, приходится всё переписывать.
Идея такая:
теперь мы не будем перестраивать ВСЮ тему целиком, если, к примеру, мы удаляем сообщение/я из начала темы. Теперь будем удалять сообщение/я только из того файла, в котором находится данное сообщение, без перестройки темы. По ходу проверяем файл на количество сообщений. Если в нём менее половины или половина сообщений(на файл), то проверяем следующий файл и если в нём тоже менее половины сообщений, обьединяем соседние файлы.
При такой схеме при показе темы мы откроем максимум 2 файла. А при удалении_перемещении также будут обработаны в лучшем случае 1 файл, а в худшем 2, даже если в теме большое количество файлов.
Это только сейчас меня торкнуло. И это окончательное решение.
Пользователь по прежнему имеет право выбрать ПРОИЗВОЛЬНОЕ количество сообщений на страницу.
Для exbb лучше не придумаешь! Бывают просветления..

Идея не до конца раскрыта, так не понятно:
- откуда известно в скольки файлах располагается тема?
- какая последовательность сообщений в файлах темы?
- как производить все манипуляции объединения при MSFIOA (Multiprocess Simultaneous File Input Output Access / многопроцессный одновременный файловый ввод вывод)?

Для этого предназначен файл post_places.php, формат которого: "номер_поста => номер_файла_темы". При манипуляциях с темой мы постоянно обращаемся не к файлу темы, а к этому файлу, как реестру темы. При этом в процессе например удаления поста проверяется соответствие фактическому количеству постов в файле, с записью в файле реестра, и если что не так то пишем в эррор лог.

Попытаюсь рассказать более подробно, чтобы было понятней механизм работы.
При добавлении нового поста создаётся папка с темой, а в ней первый файл темы, затем файл реестра, который я упоминал выше, а также файл pin_posts.php, в котором хранятся прикреплённые посты.
Производится соответствующие записи в в файлы allforums.php и list.php.
Далее, при последующем добавлении постов, посты добавляются в этот первый файл темы до 60 поста(цифра может быть иной, но я выбрал эту). После 60 поста, автоматически создаётся второй файл темы, в который добавляется 61 пост. По ходу делаются соответствующие записи в файл реестра. И так далее.
К слову сказать, я уже реализовал этот механизм, и проверил при добавлении более 60 постов. Всё работает, в том числе множественное прикрепление и открепление постов.
При удалении поста, открываем файл реестра, смотрим в каком файле находится пост, затем открываем соответствующий файл темы и удаляем пост из темы.Сразу же проверяем: если пост последний в файле, то удаляем файл, и удаляем запись из реестра. Иначе, если следующий файл темы существует, то проверяем количество постов в нём, и если там менее половины или ровно половина(30) постов, и в том файле, из которого удалили пост тоже менее половины или ровно половина, то ОБЬЕДИНЯЕМ эти два файла в один! Здесь ПРИНЦИПИАЛЬНЫЙ момент! Далее ничего не перестраиваем.
При таком механизме в первом файле темы может быть от 1 до 60 сообщений в любом случае: сколько бы файлов не было, но в следующем файле темы НЕ может быть менее 30 сообщений, то есть все последующие файлы не могут иметь менее половины сообщений. При этом в файле topic.php, реализуется механизм вывода постов такой:
Из функции printPaginator(), получаем (в переменной first) индекс начального поста, а также инфо количества постов на страницу из файла профиля пользователя. Затем из файла реестра темы получаем список с записями от начальной позиции + кол. постов на страницу. В соответствии с этим списком открываем соответствующий файл темы, к тому же, если некоторые посты в следующем файле, то второй файл темы и получаем список постов на страницу, прикрепляем к нему прикреплённые посты если они есть, и выводим.
Тут надо заметить, что юзер получает право выбрать произвольное количество постов на страницу, но только до определённого уровня. при 60 постов на файл темы, юзер имеет возможность выбрать от 1 до 30 постов на страницу. В большинстве случаев этого достаточно.
При такой схеме мы в худшем случае откроем всего два файла темы.
Если до сих пор не ясен механизм, то его можно будет пощупать в реальном движке.
Немножко сложновато? Но ведь мы не ищем лёгких путей. Сейчас тупо качается вся тема, и, конечно так легче программировать, но так программировать нельзя.

Это тоже предусмотрено. Перед данными манипуляциями предварительно прописываем в файле list.php инфо что тема закрыта для изменений. После манипуляций открываем тему. Хотя можно закрыть только эти файлы, в которых меняем, а юзеру выдать заглушку.

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

По делам текущим, а то что-то форум совсем затих. Реализовано создание "больших тем". Реализовано удаление одного поста отдельно, и множественное удаление постов со страницы.
Медленно движется потому, что в коде много зависимостей и приходится учитывать и тестировать много нюансов. Однако движение вперёд идёт. Теперь на повестке дня перемещение постов..