Обсуждение:Новый движок Абсурдопедии

Плавали, знаем. Вот только похоже, что это не слухи. --Anonim 19:51, 5 декабря 2010 (UTC)

Несколько вопросов

Будет ли движок совместим с расширениями MediaWiki? Планируется ли интегрировать функциональность некоторых имеющихся расширений в новый движок (например, CheckUser, AbuseFilter, ParserFunctions)?

Исходный код движка и/или его файлы будут открыты? — Анонимус

1. Основные расширения (вроде ParserFunctions) я перепишу на Си (они будут работать так же, как в MediaWiki). Но AbuseFilter - один из последних по приоритету, он слишком сложный. Почти наверняка первые версии будут без него.
2. Исходный код будет открыт (GPL). Но, вероятно, не ранее лета. Также замечу, что я мало времени трачу на переносимость; вероятно, работать он будет только в Linux. Edward Chernenko 14:48, 7 декабря 2010 (UTC)

1. Эти расширения будут интегрированы в ядро движка или же они будут подключаться отдельно (как в MediaWiki)?
2. Если на сервере, на который будет установлен этот движок (включающий в себя веб-сервер), уже есть веб-серверы типа Apache или Nginx, не возникнет ли конфликтов? — Анонимус

1. Пока не решил. По соображениям производительности, конечно, разумно вкомпилировать вообще все расширения в движок (если вам понадобится добавить стороннее расширение - понадобится движок перекомпилировать), а отключать/включать их действие уже в конф. файле. Мне не хочется использовать Hook-функции (как в MediaWiki), быстрее подставлять код расширений туда, куда нужно, препроцессором... А это, к сожалению, исключает возможность сделать расширение подгружаемым модулем.
2. Их на другой порт можно повесить. Тогда, естественно, не помешают. Edward Chernenko 11:44, 8 декабря 2010 (UTC)

Еще вопрос. Какие требования этого движка к памяти и мощности процессора сервера? Например, на VDS Марс он нормально работать сможет (в случае использования движка для небольшого вики-проекта типа Заговор.Орг)? — Анонимус

1. К мощности процессора требования минимальные. Оптимизировано буквально всё.
2. Движок может работать и на маленьком количестве памяти (скажем, мегабайт 40). В настройках есть опция, жёстко ограничивающая её расход. Но это не рекомендуется: вы же понимаете, что экономиться память будет за счёт уменьшения кэша.
3. Если памяти полным-полно, то движок использует всё возможное кэширование на полную катушку. Это очень предпочтительный вариант работы. Представьте себе все шаблоны в парсер-кэше и все готовые HTML-страницы в кэше обычном, в сжатом и несжатом вариантах. Для читателя скорость ответа будет, как у статического сайта.
4. На маленьком проекте (на Заговор.Орг сейчас не более 100 статей и десяток авторов) 256 мегабайт памяти можно считать за то самое "полным-полно", о котором я говорил в предыдущем пункте.
5. От количества посетителей расход памяти практически не зависит. Только от количества шаблонов и страниц.
6. P.S. в обычной схеме MediaWiki+Apache+MySQL+memcached+Squid мне всегда не нравилась ситуация, обратная нехватке памяти - когда на сервере много свободной памяти, а кэшируется не всё. В новом движке такой проблемы не будет.

Edward Chernenko 19:31, 23 декабря 2010 (UTC)

Внешний вид

Сабж? — Юрник 20:05, 11 декабря 2010 (UTC)

Для читателя — визуально неотличим от MediaWiki (100% совместимый скин Monobook). Редактирование, история, Special:Contributions и т.п. — возможно, немножко изменятся. Скин Vector будет чуть позже. Edward Chernenko 20:23, 11 декабря 2010 (UTC)

Кроме Monobook, с самого начала будет скин RilPoint. Выглядеть это будет так. Edward Chernenko 07:25, 24 декабря 2010 (UTC)

Смысл

Оффтопик  

Так весь смысл переезда — научная работа Черненко в вузе?! Anton-rigin 17:52, 8 марта 2011 (UTC)

Ненуачо? — Юрник 18:20, 8 марта 2011 (UTC)

А то, что вы все работаете на человека, для которого вы — всего лишь научный эксперимент. Задумайтесь над этим. Anton-rigin 13:09, 9 марта 2011 (UTC)

Всяко круче чем работать на косноязычную личность, тоже в свою очередь, работающего на Викию, которая выкачивает баблосы с проектов и плюет на права и удобства редакторов. Morgenstern 13:15, 9 марта 2011 (UTC)

За правами редакторов там слежу я, теперь, кстати, тоже бюрократ. Anton-rigin 13:22, 9 марта 2011 (UTC)

Лишний повод обходить тот проект стороной. Morgenstern 13:34, 9 марта 2011 (UTC)

А вот слежу я как раз хорошо. Кроме того, я думаю, Черненко закроет проект, после защиты работы, ведь на содержание серверов всё-таки немалые деньги нужны. Anton-rigin 13:36, 9 марта 2011 (UTC)

Меньше знаешь — крепче спишь. Лучше пойдите на туда, где Вы бюрократ, и разгребите всю адову чушь, которую там накидали. — Юрник 17:31, 9 марта 2011 (UTC)

Как продвигается?

Эдвард, обнови информацию в статье, пожалуйста. — Юрник 19:51, 29 марта 2011 (UTC)

Разработка временно отложена. Решил уделить время решению пары десятков небольших задач, которые давно было нужно сделать. В ближайшее время новостей о движке ожидать не стоит. — Еd 17:23, 31 марта 2011 (UTC)

Разработка возобновлена? --Klouman 18:16, 17 апреля 2011 (UTC)

Ребят, дайте отдохнуть, честно. Мне ещё себе на еду напрограммировать надо. Когда я говорю «отложено», то это не на неделю из-за простуды, а перенесено на неопределённое будущее. Извините, в ближайшие месяцы не будет новостей. — Еd 21:10, 17 апреля 2011 (UTC)

А разве скриптовый язык является узким местом?

Байт код же может висеть в одном месте ОЗУ, или это фантастика? А на его интерпретацию, если не крутить безумных циклов, требуется по идее ничтожное в общем масштабе время. X-romix 12:56, 28 апреля 2011 (UTC)

Дело не в интерпретируемости. Время теряется вот где: 1) управление памятью (автоматическая сборка мусора вместо явного освобождения), при её нехватке — невозможность mlock()нуть наиболее важные вещи. 2) многочисленные уровни абстракции на вводе-выводе, когда нужны-то только mmap, epoll и (при нехватке памяти на пополнение кэша) sendfile. 3) не знаю, как в PHP, но в Perl сейчас отвратительно нестабильная библиотека мультипоточности. В итоге придумываются такие фокусы, как очередь заданий (такая очередь заданий, как сейчас в MediaWiki, это ИМХО нонсенс — задания выполняются чаще, когда больше всего правят, то есть при максимальной нагрузке, а если сервер полностью ненагружен и все ответы идут из кэша, то очередь заданий простаивает). — Еd 20:17, 28 апреля 2011 (UTC)

Так скрипт когда отработает - он же все освободит, зачем ему что-либо в памяти держать? Все шаблоны все равно не закешируешь, там может быть чуть ли не равномерное распределение без явных пиков обращения к чему-то конкретному... А вот уже отрендеренные страницы я бы кешировал (см. ниже). X-romix 09:16, 29 апреля 2011 (UTC)

Это мы понимаем, что память должна освободиться вся разом по окончании обработки запроса. А в какой момент её PHP бросится освобождать, мы не знаем. Может, после выхода из блока if где-то внутри. Может, неоднократно. Итог - трата времени и внешняя фрагментация памяти. — Еd 12:38, 29 апреля 2011 (UTC)

Переменные же можно обнулять принудительно (а="")? X-romix 13:02, 29 апреля 2011 (UTC)

Да, но запретить освобождение памяти мы в PHP не можем. Для сравнения. Как я делаю на Си? Я выделяю (системным malloc'ом) один большой кусок фиксированного размера (теряя на внутренней фрагментации). У меня есть версия malloc(), которая берёт память оттуда (просто возвращает указатель на конец занятого места), и версия free(), которая ничего не делает. Когда запрос обработан, этот кусок памяти не возвращается системе (системным free), а передаётся на обработку другого запроса. — Еd 13:08, 29 апреля 2011 (UTC)

Насколько я помню то же самое делает Дельфи, да и Си по-моему тоже имеет какой-то буфер для malloc(). X-romix 13:23, 29 апреля 2011 (UTC)

Мы говорили о том, что это невозможно в скриптовых языках. — Еd 13:26, 29 апреля 2011 (UTC)

Скорее всего там оно встроенное - иначе бы большие ресурсы тратились каждый раз на системный вызов. X-romix 12:33, 30 апреля 2011 (UTC)

Там своя разумная система управления памятью. Разумная в большинстве случаев. Но не оптимальная. Пример я привёл - PHP нельзя сказать, что с такого-то по такой-то момент память не надо чистить. Offtopic: Системы распределения памяти я специально изучал. — Еd 12:37, 30 апреля 2011 (UTC)

Касперского (который Крис) посмотрите, у него таки впечатляющий разбор. Что уж там такое с памятью-то, неужели нельзя рендерить статью по каждому подзаголовку в отдельности? (то есть, при отрисовке до HTML брать по очереди изолированно каждый подзаголовочек, не глядя на соседние). Ну и где там расход памяти. X-romix 18:22, 1 мая 2011 (UTC)

Мы будто бы на разном языке говорим. Вы об экономии памяти, я об экономии времени :) — Еd 18:46, 1 мая 2011 (UTC)

Шаблонизация и кеширование

Мне кажется узким местом шаблонизация: многоэтажные шаблоны на шаблоне и шаблонами погоняют, плюс при правке шаблона сбрасывается кеш для неопределенного количества статей. Я бы предложил кешировать шаблоны без параметров отдельно (на выдаче их возвращать или через Iframe, или считывать текущую версию из кеша). А шаблоны с параметрами если изменились - ничего не трогать (я не помню случая в реальных статьях, чтобы это требовалось). Это позволит сделать файловый кеш со 100% попаданием, и читатель никогда не окажется в ситуации, когда у него чего-то перед носом рендерится. Также тут: Участник:X-romix/Соображения по кешированию. X-romix 12:56, 28 апреля 2011 (UTC)

Самое узкое место

Самое узкое место — это парсер. Даже без шаблонов (они легко кэшируются). — Еd 20:20, 28 апреля 2011 (UTC)

На небольших базах то быстро парсит, а на больших нагрузку создают читатели или поисковики. Мне вот интересно что там за туева куча кода исполняется при забирании из файлового кеша. По идее можно же при записи страницы формировать ее образ (расширением МедиаВики), а при чтении - брать из кеша и инклудить шапку, подвал и шаблоны без параметров, без обращения к СУБД. Недостаток такой схемы - без перезаписи страницы не обновляются шаблоны с параметрами, а по мне так это ни в одном случае делать не нужно. X-romix 08:54, 29 апреля 2011 (UTC)