ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList


 Страниц (6): « 1 2 3 [4] 5 6 »   

> Описание: О развитии нового форка движка.
Flat
Отправлено: 26 марта 2019 — 06:57
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

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

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

(Отредактировано автором: 26 марта 2019 — 07:18)

 
 
Flat
Отправлено: 27 марта 2019 — 10:06
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

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



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

(Отредактировано автором: 27 марта 2019 — 11:33)

 
 
1Bot
Отправлено: 28 марта 2019 — 17:05
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 767
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




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 секунд.
 
 
Flat
Отправлено: 29 марта 2019 — 04:12
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

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

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

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

(Отредактировано автором: 29 марта 2019 — 04:20)

 
 
Flat
Отправлено: 1 апреля 2019 — 11:52
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

(Отредактировано автором: 1 апреля 2019 — 12:07)

 
 
1Bot
Отправлено: 1 апреля 2019 — 13:15
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 767
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




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

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

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

3) Есть файл для быстрого доступа к данным (файл-индекс) - файл с наборами данных фиксированной длинны, а именно хранит массив структур вида
CODE:
(
id_block - уникальный идентификатор порции данных,
offset_block - смещение порции данных в байтах для прямого доступа в файле данных
length_data - длина в байтах, занимаемая порцией данных
length_block - длина в байтах, занимаемая блоком
)


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

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

Размеры сохраняемых блоков данных не имеют значения - лишь бы один блок помещался в память, т.к. данные будут сохраняться и считываться в режиме прямого доступа к файлу.
 
 
Flat
Отправлено: 2 апреля 2019 — 06:40
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

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

(Отредактировано автором: 2 апреля 2019 — 06:48)

 
 
1Bot
Отправлено: 2 апреля 2019 — 15:31
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 767
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




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


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

Блокировки при файловом доступе все равно придется использовать либо напрямую, либо опосредовано через готовые библиотеки.
 
 
Flat
Отправлено: 3 апреля 2019 — 06:44
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




1Bot пишет:
Вы пришли к самому правильному выводу - нужно использовать sqllite3 для хранения данных в файлах. Очень много плюсов.

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

(Отредактировано автором: 3 апреля 2019 — 06:49)

 
 
Flat
Отправлено: 8 апреля 2019 — 08:40
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




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

(Отредактировано автором: 8 апреля 2019 — 08:45)

 
 
1Bot
Отправлено: 9 апреля 2019 — 13:00
Post Id



Пользователь
Super Member


Покинул форум
Сообщений всего: 767
Дата рег-ции: Апр. 2009  
Откуда: Днепропетровск
Репутация: 69




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

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



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




1Bot пишет:
- откуда известно в скольки файлах располагается тема?

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

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

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

(Отредактировано автором: 9 апреля 2019 — 15:58)

 
 
Flat
Отправлено: 10 апреля 2019 — 10:42
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




Flat пишет:
При таком механизме в первом файле темы может быть от 1 до 60 сообщений в любом случае: сколько бы файлов не было, но в следующем файле темы НЕ может быть менее 30 сообщений, то есть все последующие файлы не могут иметь менее половины сообщений.

Уточню. Сливаем файл тогда, когда в одном из них количество сообщений будет достаточным, чтобы дополнить второй файл до уровня, который не превышает 60.
 
 
Flat
Отправлено: 22 апреля 2019 — 16:21
Post Id



Пользователь
Full Member


Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018  
Откуда: Красноярский край
Репутация: 14




По делам текущим, а то что-то форум совсем затих. Реализовано создание "больших тем". Реализовано удаление одного поста отдельно, и множественное удаление постов со страницы.
Медленно движется потому, что в коде много зависимостей и приходится учитывать и тестировать много нюансов. Однако движение вперёд идёт. Теперь на повестке дня перемещение постов..
 
 
Страниц (6): « 1 2 3 [4] 5 6 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Обсуждаем »

> Похожие темы: EXBB gold edition
Темы Форум Информация о теме Обновление
Перенос работающего форума
phpbb на ExBB?
Установка и обновление Ответов: 4
Автор темы: Degami
24 марта 2010 — 11:25
Автор: Degami
Поддомен или раздел домена? Куда лучше установить скрипт форума?
Существуют ли проблемы в работе движка в этих двух вариантах?
Раскрутка Ответов: 21
Автор темы: mastersound
21 июля 2009 — 20:16
Автор: Victor
Подфорумы
Имеется ли реально работающий мод «Подфорумы» для Exbb.FM.RC1
Обсуждение Ответов: 3
Автор темы: fdg
16 ноября 2009 — 07:03
Автор: fdg
Как вставить рекламу
на ExBB FM RC 1.0
Общие вопросы Ответов: 18
Автор темы: SmexotvoriN
10 февраля 2014 — 17:14
Автор: Zeg
Мод: Чат на форуме (Beta)
Ajax-чат для ExBB FM
Модификации и дополнения Ответов: 252
Автор темы: yura3d
26 октября 2009 — 19:17
Автор: electron
 



Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 




Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.1642]     [ ]