Архив:Edward Chernenko:Фуршет в феврале 2011 года
Материал из Викиреальностя
Ветка Edward Chernenko на фуршете в ru_wikipedia в феврале 2011 года.
20-Фев-2011 5:55 am none (UTC)
Я администратор Абсурдопедии.
Программист, разрабатываю новый вики-движок.
-
20-Фев-2011 10:56 am none (UTC)
Какой наибольший недостаток существующего движка?
-
20-Фев-2011 11:37 am none (UTC)
Скорость и расход системных ресурсов.
Классический вики-сайт на MediaWiki — это связка толпы независимых приложений: веб-сервер, Squid, MySQL, memcached, иногда поисковой движок вроде Sphinx (последний используется в Абсурдопедии). Любое общение между ними ведёт к потере времени.
Кроме того, в MediaWiki довольно медленный парсер.
И, самое худшее — внесение правки или обращение к action=purge ведёт к сбросу существенной доли кэша, даже если пересчитывать ничего на самом деле было не нужно. Это очень лёгкая цель для DOS-атаки. Новый движок распознаёт такую ситуацию и отклоняет действие purge.
-
-
20-Фев-2011 12:15 pm none (UTC)
В вики-проектах в качестве кеширующего прокси часто используется Nginx, а не Squid. Какие преимущества у Squid?
Для чего нужен поисковый движок Sphinx?
-
-
20-Фев-2011 12:33 pm none (UTC)
> В вики-проектах в качестве кеширующего прокси часто используется Nginx, а не Squid.
> Какие преимущества у Squid?
Я не имел дела с Nginx, поэтому на вопрос "какой акселератор лучше" ответить не могу.
Мне известно, что движок MediaWiki немедленно оповещает Squid, когда элемент в кэше устаревает.
-
-
20-Фев-2011 01:07 pm none (UTC)
> Для чего нужен поисковый движок Sphinx?
Это вполне очевидно.
Он индексирует страницы несколько раз в день, а обычный поиск MediaWiki — при каждой правке. Угадайте, что медленнее.
Ищет сам Sphinx значительно быстрее, чем обычный поиск, хранящий индекс в MySQL.
Стандартный поиск MediaWiki годится только для очень маленьких сайтов.
Кроме того, если отвлечься от вопроса скорости, Sphinx выдаёт более удобные и подробные результаты поиска.
-
-
20-Фев-2011 12:10 pm none (UTC)
Почему есть сомнения в необходимости расширения CheckUser для нового движка?
-
20-Фев-2011 01:11 pm none (UTC)
Потому что в новом движке оно не используется для предотвращения вандализма, а в MediaWiki используется.
Приведу простой пример. Обычный вандал использует динамические адреса из нескольких сетей своего провайдера. В MediaWiki приходится проверить его, по IP выявить диапазон или город, а потом их заблокировать. Человек должен сесть и проделать все эти манипуляции.
Новый движок собирает статистику по действиям из определённого диапазона, города, определённым юзер-агентом и т. п. На странице блокировки будут опции: «заблокировать весь диапазон», «заблокировать весь город», «установить [такой-то] троттлинг для диапазона/города сроком на […]».
При этом сами эти юзерагенты, IP и т. д. показываться никому не будут.
* 25:61, 32 мартобря 6666 Василий Пупкин (Обсуждение | вклад | заблокировать)
ограничил диапазон %%36%% на период 1 день (запрещена регистрация учётных записей,
троттлинг: 10 правок / 2 часа) (вандализм) (разблокировать | изменить блокировку)
* 25:65, 32 сопреля 6666 Василий Пупкин (Обсуждение | вклад | заблокировать)
ограничил город %%77%% на период 1 неделя (запрещённые действия: move)
(неконсенсусные переименования) (разблокировать | изменить блокировку)
-
-
20-Фев-2011 06:39 pm none (UTC)
Интересно.
1. А какой смысл ограничивать по городу? Например, если вандал правит с адресов провайдера MTU-Intel, обычно нецелесообразно блокировать всю Москву.
2. Как поступать с открытыми прокси? Без проверки и получения конкретного IP-адреса проверить его на открытый прокси нельзя. Таким образом вандалов с прокси остановить будет значительно сложнее.
3. Как в новом движке осуществляется проверка на дополнительные учетные записи? Описанный выше механизм эффективен для борьбы с явными вандалами, а вот без прямого получения и анализа IP-адресов и юзерагентов вычислить куклы невозможно.
Для Абсурдопедии последнее, может быть, и не нужно, но вот если движок планируется публиковать для использования широким кругом участников, такая возможность должна быть.
-
-
20-Фев-2011 06:48 pm none (UTC)
1. По любому полю whois можно будет ограничивать. Например, по OrgName.
Это, конечно, не означает, что при каждой правке будет выполняться whois-запрос (их результаты будут кэшироваться).
2. > Как поступать с открытыми прокси?
Превентивно грузить списки прокси, как это делает WindAdminBot.
3. > Как в новом движке осуществляется проверка на дополнительные учетные записи?
В необходимости этого я, собственно, и сомневаюсь.
-
-
20-Фев-2011 04:08 pm none (UTC)
Зачем понадобился новый движок и какими особенностями он будет обладать?
-
20-Фев-2011 05:17 pm none (UTC)
Не секрет, что движок MediaWiki достаточно тормозной (подробнее в ответе выше).
Я ищу возможности оптимизировать всё, что только можно, чтобы сделать самый быстрый вики-движок на свете.
Для Фонда Викимедия, ежегодно собирающего миллионы пожертвований, неэффективность движка может и не представлять особенной проблемы (ну, закупят ещё сотню серверов, не проблема для них). А вот не имеющим таких астрономических доходов возможность купить всего 20 серверов вместо 30 под вики-сайт кажется довольно перспективной.
> какими особенностями он будет обладать?
Я стараюсь сделать так, чтобы он был максимально совместим с MediaWiki (пользователям не надо будет переучиваться: та же разметка, интерфейс почти не изменится). Все существенные изменения касаются а) скорости работы и б) источников, из которых получаются тексты страниц.
-