Обсуждение в Википедии:Не беспокойтесь о производительности

Статус страницы

Есть ли причина, по которой это не политика или руководство? — Omegatron 15:54, 14 июля 2006 (UTC) [ ответить ]

Не думаю, нет. Я изменил его на предложенный. — Simetrical ( обсуждение • вклад ) 20:51, 14 июля 2006 (UTC) [ ответить ]

Это должно быть политикой. -- Meno25 04:53, 29 ноября 2006 (UTC) [ ответить ]

Я согласен, что это должно быть политикой, поскольку это просто перефразирование заявлений разработчиков, которые лучше всех разбираются в таких вещах. HighInBC ^{(Нужна помощь?}^{Спросите меня}⁾ 19:11, 15 декабря 2006 (UTC) [ ответить ]

Статус руководства

Здесь не так много разговоров, и "мандат разработчика" из истории не выдерживает критики: Разработчик != суперпользователь. Я "понижаю" это обратно до эссе. Разве руководство против подмены инструкций не должно также учитываться, когда дело доходит до подмены инструкций?
152.91.9.144 05:36, 12 декабря 2006 (UTC) [ ответить ]

Я переделал это в эссе, и если кто-то захочет обсудить это, то вот страница обсуждения!
152.91.9.144 23:33, 12 декабря 2006 (UTC) [ ответить ]

Извините, но небольшое преданное меньшинство (вы) не мешает чему-либо стать политикой.

И да, разработчики могут устанавливать политику, например, относительно нагрузки на сервер, и даже большинство не может отменить их решение. Наши политики по этому вопросу на самом деле самореферентны в этом:

Как начинается политика?

Изменение политики теперь происходит из трех источников:
Кодификация текущих соглашений и общепринятой практики. Это предложения, которые документируют способ работы Википедии. Конечно, один пользователь не может диктовать, что такое общепринятая практика, но запись общих результатов хорошо используемого процесса — это хороший способ создания политики.
Предлагаемая политика, принимаемая на основе консенсуса . (См. Wikipedia:Как создать политику ). Обычно это предложения по изменению способа работы Wikipedia.
Заявления Джимми Уэйлса , Правления или Разработчиков , в частности, по вопросам авторских прав, правовых вопросов или нагрузки на сервер.
— Как начинается политика?

Теперь я не знаю. Может быть, вы правы. Может быть, это не относится к делу. Это, в конце концов, просто страница с дословными заявлениями разработчиков о нагрузке на сервер... — Omegatron 00:14, 13 декабря 2006 (UTC) [ ответить ]

Вы явно очень запутались... это даже не была страница политики изначально. Это была страница руководства , сделанная как таковая без обсуждения. Предполагать, что разработчики хотят сделать это политикой , чтобы мы не беспокоились о нагрузке на сервер, ну, странно. Также очень разочаровывает, что вы решили изобразить это как "меньшинство", то есть "меня", как некоего воина редактирования, когда я внес изменения, использовал страницу обсуждения, вы откатились, не используя страницу обсуждения, я снова использовал страницу обсуждения , и только тогда вы начали обсуждать, но после того, как меньшинство (ЭЙ! ЭТО ТЫ!!) попало в "политику" без обсуждения. Перестаньте быть воином редактирования и сначала обсудите на странице обсуждения. Я откатываю это к версии 09:54, 31 августа 2006 года Стив заблокировал , так как все последующие изменения вносились без использования страницы обсуждения.
152.91.9.144 00:52, 13 декабря 2006 (UTC) [ ответить ]

Как разработчик: я не знаю, имел ли в виду Брайон, что это должно быть политикой, предписанной Фондом. Использование терминологии типа «обычно должно» не то, чего я ожидал бы в этом случае. Если это должно быть одним из крайне немногих руководств/политик, которые предписаны Фондом явно, я определенно думаю, что Брайон, а не вы, должен быть тем, кто добавит этот тег. Вы не имеете права интерпретировать намерение сотрудников Фонда, если это намерение неясно. Если Брайон не создаст эту политику сам в своем официальном качестве технического директора, что он может сделать, используя свою собственную учетную запись, то она должна пройти обычный процесс сбора одобрений. Который, кстати, он, вероятно, пройдет, если, возможно, уже не прошел.

Сравните, кстати, с WP:AUM , которая была объявлена политикой по причинам, близким к «мандатам для каждого разработчика», и которую Брайон открыто отверг в той самой разнице, которая процитирована на странице этого эссе. — Simetrical ( обсуждение • вклад ) 01:46, 13 декабря 2006 (UTC) [ ответ ]

Использование терминологии типа «как правило, следует» — это не то, чего я ожидал в данном случае.

Политики могут включать такие термины, как «как правило, следует».

и которое Брайон явно отверг в той самой разнице, которая процитирована на странице этого эссе.

Точно. — Omegatron 02:32, 13 декабря 2006 (UTC) [ ответить ]

Политики могут включать такие термины, как «обычно следует», но также могут включать рекомендации или мнения. И я не думаю, что отклонение ведущим разработчиком слов разработчика, принимаемых не-разработчиками в качестве политики, благоприятствует любой попытке не-разработчика принять слова любого разработчика в качестве политики, даже если эти слова те же самые, что отвергают другие. Если вы понимаете, что я имею в виду. — Simetrical ( talk • contribs ) 17:00, 13 декабря 2006 (UTC) [ ответить ]

Опечатка

Я дважды (один раз выше и один раз в кратком изложении правок) сказал, что разработчики не создают политику. Это не было моим намерением, и только прочитав ответ S выше, я увидел свою ошибку. Я возражал против того, что слухи разработчиков были политикой, в своего рода вторичной апелляции к авторитету. Мой ответ также был в целом перегрет. Так что... Ничего не видно и не слышно, идите дальше.
152.91.9.144 03:24, 13 декабря 2006 (UTC) [ ответить ]

Перенаправить?

Основываясь на недавнем сообщении Брайона на wikitech-l, возможно, эту страницу следует перенаправить на Wikipedia:Use common sense . Angela . 20:44, 16 января 2007 (UTC) [ ответить ]

Согласен. Или мы могли бы вставить сюда и новый пост Брайона... — Эдвард З. Янг^{( Обсуждение )} 21:03, 16 января 2007 (UTC) [ ответить ]

Хе-хе. Брайон любит нажимать на эту клавишу , не так ли? Мы должны просто добавить эту цитату сюда, поскольку Википедия:Используйте здравый смысл не о проблемах сервера. — Omegatron 21:19, 16 января 2007 (UTC) [ ответить ]

Я уже добавил его до того, как увидел это обсуждение. -- HappyDog 22:38, 16 января 2007 (UTC) [ ответить ]

Удобство использования страницы

Чтобы быть хоть немного полезной, эта страница должна содержать примеры того, что может представлять собой реальные проблемы, а что нет. // habj 22:33, 23 января 2007 (UTC) [ ответить ]

Меньше покровительства, больше подробностей? (предупреждение: долго)

Ненавижу это говорить, но чтение этой страницы на самом деле заставило меня почувствовать себя менее комфортно по отношению к работе Википедии, чем когда-либо прежде, потому что все цитаты, похоже, состоят из нападок соломенного чучела и странных, конспирологических фраз типа «нет проблем, потому что мы говорим, что их нет». Нет, я не думаю, что у кого-либо из говорящих есть настоящие негативные намерения, но они, безусловно, могли бы лучше выразить свои позитивные. Я полагаю, что цитаты были получены из-за их усталости слышать, как люди постоянно выражают эти страхи, но это все равно не оправдание отсутствия источников на этой странице . Когда люди утверждают, что контакт с жабами вызывает бородавки, вы не просто говорите: «Это глупо! Вы не правы, и вы также много говорите «тэ». Вы представляете доказательства обратного, независимо от того, насколько утомительно это делать.

Все, что мне интересно, это (надеюсь) простая часть данных: какова, грубо говоря, емкость сервера? Какая часть из этого была «заполнена»? Какая может быть хорошая аналогия для того, насколько чертовски огромно доступное пространство? (Ответ на последний вопрос, каким бы надуманным он ни был, может быть особенно полезен для таких людей, как я, чтобы понять идею.) Я слишком упрощаю то, как работает емкость сервера (весьма вероятно, я знаю)? Или это все конфиденциальная информация для хакеров, которая не должна быть опубликована (хотя быстрая поездка в Тампу может дать ту же информацию...)?

В любом случае, «это наша работа» на самом деле недостаточно, чтобы удовлетворить самых параноидальных из нас (возможно, включая меня); это как если бы полицейский заверял граждан, что им не нужно беспокоиться о преступлениях в их сообществе, не из-за документально подтвержденного низкого уровня преступности, а потому что они полицейские и это «их работа». Никто не сомневается в том, что разработчики разрабатывают, или что они разрабатывают очень хорошо. Нам просто нужна уверенность в том, что либо (a) Википедия не похожа на наши жесткие диски для настольных компьютеров, либо (b) она похожа, но в степени, выходящей за рамки нашего понимания. (Или (c) что-то еще, о чем я не подумал.)

Кроме того, не помешало бы придумать способ примирить это руководство с таким напрашивающимся ответом: «Зачем же вам тогда нужны пожертвования ?» И я уверен, что такое примирение возможно, но только если оно будет сопровождаться уменьшением этого отношения «не беспокойте свои милые маленькие головы нубов». Lenoxus " * " 19:35, 26 марта 2007 (UTC) [ ответить ] $\сим$

Источники не могут быть предоставлены для каждой оценки влияния на производительность системным администратором или разработчиком. По сути, это то же самое, что допрашивать вашего врача о том, какие медицинские справочные работы он использовал при постановке вам диагноза, с заметными различиями, что системные администраторы и разработчики WMF, как правило, a) волонтеры b) плохо оплачиваются, если не являются волонтерами c) не получают от вас больше доли цента, если вы не пожертвовали действительно непомерные суммы и d) заняты.

Если у вас есть технический опыт в администрировании серверов и/или разработке ПО, вы, вероятно, сразу поймете, почему большинство вещей, запрещенных за медлительность, медленные, если дать краткое изложение в два предложения, и то же самое касается вещей, разрешенных за немедлительность. Если бы вам было интересно, и вы знали, о чем говорите (я не говорю, что вы в частности не знаете, но подавляющее большинство не-разработчиков не знают), большинство разработчиков, вероятно, не будут иметь проблем с разговором о других реализациях или чем-то подобном. Если у вас нет опыта, чтобы полностью оценить последствия любого конкретного изменения, то, попросту говоря, вы не поймете должным образом ничего из того, о чем мы говорим, и вам придется довольствоваться либо «доверьтесь нам», либо какой-то технической тарабарщиной, которая сводится к одному и тому же. Это базовый факт такой интенсивной специализации, как у нас сегодня.

Чтобы ответить на ваш вопрос, это не так просто, как «емкость сервера». У серверов есть много, много, много узких мест, которые могут их замедлить. Это не простые устройства. Подводя итог грубому состоянию игры, насколько я знаю (что не очень подробно, потому что, хотя я и разработчик, я не системный администратор): у нас фактически неограниченное дисковое пространство, о чем я упоминаю, потому что это, пожалуй, единственное, что можно назвать «заполняемым» в каком-либо реальном смысле. Во многих других отношениях (ЦП, память, количество серверов в целом) нам не хватает. Сайт часто работает медленно, и это можно было бы исправить, добавив больше серверов. В настоящее время у нас нет столько серверов, сколько мы могли бы использовать, потому что Фонд Викимедиа работает на бюджет, который другие десять лучших сайтов потратили бы на туалетную бумагу. Google быстрее и надежнее, потому что у них примерно 450 000 серверов и их число растет; Фонд Викимедиа владеет примерно 300.

Ничто из этого не является конфиденциальным. Помимо паролей и криптографических ключей, только очень немногие мелочи являются строго конфиденциальными. Мы открыты как с технической стороны, так и с точки зрения содержания.

Полицейские, без обид, в лучшем случае полуквалифицированы, ближе к неквалифицированным. Неспециалист не может ожидать, что поймет детали работы программиста больше, чем физика-теоретика или разработчика ракетных двигателей. Вы можете понять только эффекты, но не средства или логику. Если это вас не устраивает, вы можете попытаться узнать об этом виде вещей и получить непосредственный опыт, но до тех пор вам придется поверить нам на слово, исходя из того, что мы, по-видимому, имеем гораздо лучшее представление о том, о чем говорим, чем вы. Что, без обид, мы и делаем, о чем свидетельствует тот факт, что серверы работают, а программное обеспечение в основном делает то, что должно, чего люди, не имеющие опыта в соответствующих областях, не могли бы заставить их делать. Мы не идеальны, но мы кое-что знаем; те, кто знает столько же или больше, могут критиковать нас, но те, кто знает гораздо меньше, не имеют возможности формировать критику.

Ничто на этой странице не подразумевает, что производительность не является проблемой. Больше серверов абсолютно необходимо. Но это проблема для разработчиков и других людей с техническими знаниями. Когда вы говорите, что то-то и то-то создаст слишком большую нагрузку на серверы, подразумевается, что вы знаете, о чем говорите; если вы не знаете, не говорите этого. В целом, мы постараемся удержать пользователей от совершения чего-либо слишком разрушительного, но в некоторых случаях мы этого не сделали или не можем, и тогда вам придется принять наши (в частности, основных администраторов сервера, таких как Брайон, Тим, Домас и Марк) инструкции не делать чего-либо. Смысл этой страницы в том, чтобы сказать, что вы не должны придумывать свои собственные инструкции не делать чего-либо, и вы не должны пытаться обобщать или расширять инструкции людей, которые знают, о чем говорят. И стоит упомянуть, что даже те, у кого большой опыт работы с серверами, не должны высказывать свое собственное мнение, если у них нет глубоких знаний о настройке нашего сервера и используемом нами программном обеспечении.

В любом случае, я думаю, что эту страницу лучше всего переписать как настоящее эссе, а не как набор вырванных из контекста цитат, адресованных чему-то другому. Думаю, я сделаю это сейчас. — Simetrical ( обсуждение • вклад ) 04:21, 27 марта 2007 (UTC) [ ответить ]

Хорошо. — Omegatron 04:50, 27 марта 2007 (UTC) [ ответить ]

Захват страницы

Я выкинул цитаты; они были частично вырваны из контекста и не особенно точны или проясняют ситуацию. Вместо этого я составил личное резюме идей, лежащих в основе этого. Я думаю, что лучше пока оставить это написанным разработчиками, как это было в прошлом, поэтому я буду следить за страницей и просматривать изменения. Если в какой-то момент кто-то захочет провести большие публичные обсуждения и получить одобрение этого в качестве руководства, полномочия автора-разработчика могут быть не нужны. В любом случае, я думаю, что текущая версия подчеркивает соответствующие моменты и более утонченна по сравнению с некоторыми путаницами, которые у нас были по этому поводу, в отличие от предыдущих версий. — Simetrical ( обсуждение • вклад ) 04:49, 27 марта 2007 (UTC) [ ответ ]

Отличная, отличная работа; большое спасибо за то, что так отреагировали на мои опасения. Надеюсь, вы не против моих недавних незначительных изменений; я просто прочитал предыдущий раздел этой страницы, затем посмотрел на эссе и внес эти изменения до того, как увидел этот раздел, упс. Если вам интересно, я изменил «формулировать мнения» на «предполагать», потому что говорить людям, что они «не имеют права» высказывать мнения, хотя во многих случаях это может быть правдой, слишком часто неверно истолковывается как «отсутствие права высказывать мнения», что (я предполагаю) не было вашим намерением; «имеет право предполагать» должно подразумевать наличие полномочий делать выводы о работе сервера. Надеюсь, это круто.

И последнее небольшое замечание: неизбежно, кто-то, читая это, спросит: «Но я думал, что каждая маленькая часть имеет значение для Википедии; разве не в том дело, что миллионы людей, работающих вместе, могут добиться колоссальных результатов, которые не смог бы сделать один из нас?» Так что вы (или другой разработчик) можете подумать о том, чтобы перефразировать «нет ничего, что вы можете сделать, чтобы существенно ускорить или замедлить работу сайта» на что-то вроде «нет ничего, что может сделать добросовестное сообщество Википедии, даже с его миллионами (миллиардами?) ежедневных правок, чтобы существенно ускорить или замедлить работу сайта». (Я бы это добавил, но не знаю, как сформулировать это в терминах, понятных разработчикам. Я предполагаю, что существует достаточно простое различие между «общим объемом измененной информации» и «пространством на сервере».) О, и я не знаю, необходима ли ваша подпись в соответствии с правилами эссе Википедии, но это незначительно. Еще раз большое спасибо, и продолжайте в том же духе для Википедии! Lenoxus " * " 18:24, 27 марта 2007 (UTC) [ ответить ]

\сим

Миллионы людей замедляют работу сайта. В основном это отдельные люди. Возможно, это должно быть что-то вроде: почти никакие политики, которые вы могли бы ввести, не окажут положительного влияния на производительность сервера, которое перевесило бы их пагубное влияние на другие аспекты Википедии, или что-то в этом роде; если такая политика должна быть принята, она будет принята и реализована на уровне программного обеспечения или сервера, а не сообществом. Сегодня я не чувствую себя таким красноречивым, поэтому отложу перефразирование. ;)

Также я снова добавляю кавычки внизу, чтобы прохожие поняли, что это не только мое мнение... так выглядит лучше? — Simetrical ( обсуждение • вклад ) 23:44, 27 марта 2007 (UTC) [ ответить ]

Да, это так; мило. Позвольте мне попытаться перефразировать то, что я имел в виду: люди, которые делают добрые дела здесь и там, как в Википедии, так и в жизни в целом, часто думают в терминах бесчисленных «невидимых других», которые, предположительно, делают примерно то же самое, часто вдохновленные одним человеком. В реальной жизни серверное пространство — это не то, о чем беспокоятся здравомыслящие люди (которые не верят, что «Матрица » реальна), но в Википедии это то, о чем беспокоятся многие (наивные, но вдумчивые) люди. Так что я веду к тому, как благонамеренный пользователь может подумать: «Ну, я бы с удовольствием добавил такую-то категорию на соответствующие страницы, но тогда все другие пользователи будут делать то же самое, и поскольку эта конкретная категория имеет огромный диапазон включения и ее просто невозможно разделить на подкатегории, существование всех этих строк [[Категория:Выдуманная гипотетическая]] наверняка приведет к краху серверов!»

Или, если использовать более правдоподобный пример, у новичка может быть веская причина сделать ряд правок, например, 30, в одной и той же статье, вместо одного большого изменения, и он будет беспокоиться, что если достаточно много других последуют примеру, это создаст ненужную нагрузку на серверы. (Или последнее действительно возможно, учитывая ваш пункт "Миллионы людей замедляют работу сайта"?) Вот о чем я говорю. Неужели такие возражения просто слишком "непонятны" (что я, полагаю, понял бы), чтобы иметь место в эссе? О, и, пожалуйста, не беспокойтесь об ответе, пока не почувствуете себя более красноречивым; это, безусловно, может подождать много времени. Lenoxus " * " 02:44, 28 марта 2007 (UTC) [ ответить ] $\сим$

Примечание

Из WP:POL , "Изменение политики теперь исходит из трех источников... Заявления Джимми Уэйлса, Совета директоров или Разработчиков, в частности, по вопросам авторских прав, правовых вопросов или нагрузки на сервер" . > R a d i a n t < 08:42, 10 апреля 2007 (UTC) [ ответить ]

Ни один разработчик не объявлял эту страницу политикой или руководством. Поэтому в настоящее время она таковой не является, даже если использовать эту логику. Насколько мне известно, разработчики никогда не объявляли политику как таковую. Скорее, они могут указывать людям делать или не делать определенные конкретные вещи в каждом конкретном случае (например, удалять Wikipedia:Sandbox , создавать нелепо нагружающий шаблон на es-wiki), или они могут внедрять проверки программного обеспечения, которые полностью предотвращают действие (например, ограничения на включение шаблонов, переименование пользователей с большим количеством правок). Ни то, ни другое не может считаться политикой.

Конечно, любой, кому Фонд предоставил любую должность с полномочиями (например, системный администратор), может использовать эти полномочия при необходимости, что в зависимости от его роли может распространяться на объявление поведения официально требуемым или неприемлемым, т. е. на разработку политики. Это свойственно не только системным администраторам; я припоминаю, что когда Эссджей был должностным лицом на выборах, он угрожал лишить Джени привилегий системного оператора, когда Джени удалил объявление о периоде выдвижения кандидатур из уведомления на сайте. Я почти не сомневаюсь, что он бы добился успеха, если бы Джени неразумно настаивал. Поэтому ваша цитата кажется мне плохо продуманной.

О, и если вы все еще хотите добавить его обратно, я разработчик, так что, по вашему мнению, я имею право говорить вам, что делать. Таким образом, если вы не правы, вы не должны добавлять его снова, потому что он неправ, а если вы правы, вы не должны добавлять его снова, потому что я, святой Разработчик, сказал не делать этого. :P — Simetrical ( talk • contribs ) 02:41, 12 апреля 2007 (UTC) [ ответить ]

Вы немного упускаете суть. Руководство не создается тегом на странице, это бюрократический подход. Практический подход заключается в том, что (1) разработчики, нанятые MediaWiki, говорят нам не беспокоиться о производительности, (2) эти разработчики получают зарплату и знают о таких вещах, поэтому (3) нам не следует беспокоиться о производительности. Это не чье-то мнение, это наш способ работы. Очень просто. Руководство не является чем-то юридическим. > R a d i a n t < 08:38, 12 апреля 2007 (UTC) [ ответить ]

Или, говоря иначе, пожалуйста, найдите мне любого, кто (1) не согласен с тем, что нам не следует беспокоиться о производительности, и (2) действительно знает, о чем говорит в этой области. > R a d i a n t < 08:41, 12 апреля 2007 (UTC) [ ответить ]
Есть разница между несогласием с общей предпосылкой и несогласием с идеей, что большую впечатляющую наклейку «руководство» следует налепить на точные слова эссе. Если кого-то не убедили технический директор и два отдельных разработчика, заявляющих, что им не следует беспокоиться о производительности, я сомневаюсь, что {{ руководство }} убедит их в любом случае. Мне не нравится идея, что мои слова будут разбирать на части, как какой-то священный текст, что, несомненно, произойдет, если/когда возникнет спор, связанный с производительностью, и одна или другая сторона попытается утверждать, что слова руководства подтверждают их. Я не вижу, чтобы что-то послужило тому, чтобы сделать это руководством. И я тот, кто написал страницу в ее нынешнем виде, черт возьми.
Однако я не заинтересован в том, чтобы ввязываться в войну возвратов. Вы хотите оставить это {{ guideline }} , я не собираюсь пытаться остановить вас. — Simetrical ( talk • contribs ) 17:32, 12 апреля 2007 (UTC) [ ответить ]
- Дело в том, что руководящие принципы не должны быть большими и впечатляющими, и уж точно не священным текстом. Кроме того, не все знают имя Брайона. > R a d i a n t < 08:14, 13 апреля 2007 (UTC) [ ответить ]

Испытывая судьбу

10 июля 2007 г.: Ох, с чего бы мне начать? Самое подходящее предостережение : опасайтесь « искушать судьбу » (хвастовства тем, что что-то не имеет значения). Сказав это, я получил сообщение: «Корабль вики непотопляем» (re: Titanic ), так что не волнуйтесь, будьте счастливы .

Теперь вернемся к реальности. Узкие места производительности развиваются практически в любой долгосрочной среде, в любом поколении. Есть несколько основных растущих проблем, которые следует отметить в WP/Wikimedia:

Файлы PNG съедают производительность Wikipedia: многие статьи, которые раньше на 70% состояли из текста (+30% изображений JPEG ), теперь представляют собой файлы на 180% из PNG , ожидающие отображения, поскольку файлы PNG часто в 6 раз больше формата JPEG (6 x 30 = 180%). Знаете ли вы, что фанатики PNG активно конвертируют/УДАЛЯЮТ быстрые файлы JPEG и заставляют людей отображать тысячи огромных файлов PNG? Если быть точным, файлы PNG могут быть в 5-21 раз (да, в двадцать один) больше формата JPEG из-за алгоритмов изменения размера WP или Wikimedia, которые отдают предпочтение формату JPEG и поддерживают файлы JPEG примерно в 10 раз быстрее. Это не минимальная проблема производительности в 8%: файлы PNG обычно на полную величину (в 10 раз = 1_000%) медленнее. Однако есть и отрицательная синергия : люди узнали, что отображение PNG-файлов в виде маленьких миниатюр делает их всего в 3 раза медленнее, чем JPEG обычного размера, но, конечно, теперь, чтобы увидеть какие-либо детали, люди должны «нажать для увеличения» и просмотреть полный «350-килобайтный» PNG-файл, который часто в 15 раз больше, чем изображение JPEG обычного размера (20 КБ), которое было достаточно четким для просмотра без увеличения.

Всплывающие анимации: Несколько пользователей начали опасную тенденцию: статьи с движущимися картинками (и это, понятно, «путь будущего»). Однако статья, которая начиналась как 25 Кб текста, теперь включает в себя анимацию «короткометражного фильма» по умолчанию, сгенерированную путем автоматической загрузки 1-мегабайтного анимированного графического файла. Анимация — это не ссылка «кликни, чтобы повернуть», а скорее автоматическая загрузка по умолчанию всего короткометражного фильма: 1050 Кб против 25 Кб, поэтому статья попадает на серверы WP как в 42 раза больше данных, чем раньше.

Я остановлюсь на этом. Общая тенденция такова (можете догадаться): данные бродяги теперь лезут автостопом во многие статьи, делая скорость широкополосного доступа почти такой же медленной, какой была скорость коммутируемого доступа много лет назад. Революция производительности широкополосного доступа скоро будет побеждена, потому что они "не беспокоятся о производительности", и это было до того, как вы их подбодрили. "Мадам, сам Бог не мог потопить этот корабль". - Wikid77 08:50, 10 июля 2007 (UTC) [ ответить ]

ОБНОВЛЕНИЕ: Корабль затонул к декабрю 2008 года; см. ниже: #Обновление реальности за июнь 2009 года . -Wikid77 08:01, 23 июня 2009 г.

Примечание для заинтересованных читателей: обсуждение продолжается на Talk:Windows Vista#Windows Vista Snapshot изменен на JPG и #All PNG с JPEG . Powers ^T 19:30, 10 июля 2007 (UTC) [ ответить ]

Конечно, все пункты в этом эссе предназначены для применения только к производительности сервера, а не к скорости загрузки на стороне клиента. Это не имеет отношения к редакционному решению о том, какой баланс выбрать между качеством изображения и размером изображения, и не должно цитироваться в любом таком обсуждении. Я добавил примечание по этому поводу. Что касается аналогий с Титаником , ну, я не думаю, что пассажиры на этом благородном судне могли бы сделать много, чтобы предотвратить его затопление, если бы они решили (не посоветовавшись с экипажем), что необходимо подпрыгивать вверх и вниз, чтобы уменьшить его вес. Если вы читаете это как «мы непобедимы», а не как «оставьте вопросы производительности сервера тем, на кого возложена ответственность за управление им», вы неправильно поняли. — Simetrical ( обсуждение • вклад ) 05:26, 11 июля 2007 (UTC) [ ответ ]

Суть этой страницы в том, что невежественные пользователи склонны делать крайне непрактичные предложения, основанные на предполагаемых проблемах с производительностью. И они не должны этого делать. Это не значит, что люди должны конвертировать все JPEG в PNG, но это происходит по причинам, совершенно не связанным с производительностью. > R a d i a n t < 12:25, 6 августа 2007 (UTC) [ ответить ]

- И проблема с этой страницей в том, что всякий раз, когда кто-то делает совершенно глупое предложение, которое будет иметь адские проблемы с производительностью (например, рефакторинг тысяч существующих шаблонов в один большой шаблон с получением миллиона трансклюзий — не гипотетический пример), и кто-то указывает на это, предлагающий настойчиво указывает на этот случайный набор цитат. То, что настаивают на том, что это руководство, только ухудшает ситуацию. Мы не можем винить в этом кого-то, кто пользуется своим положением и навязывает нам ужасную версию довольно сомнительного «правила» (как мы можем с WP:IAR ), это не предписано разработчиками, это полностью дело рук (или, в более общем смысле, неспособность делать что-либо иное) сообщества. Давайте вернемся к «эссе», ожидая либо решительного вмешательства разработчиков, либо появления поддерживаемой сообществом версии, которая будет иметь тот эффект, который, по утверждению Radiant, она должна иметь. Алай 02:10, 10 августа 2007 (UTC) [ ответить ]
  - Такие вещи, как рефакторинг тысяч существующих шаблонов в один большой шаблон, как раз и призваны решать эти рекомендации (/эссе). В этом случае их обязательно нужно цитировать, а производительность следует полностью игнорировать по всем указанным здесь причинам. Конечно, у вас могут быть и другие проблемы, например, такой большой шаблон, который может сломать страницы, достигнув предела длины включения шаблона, но это не проблемы производительности. Если есть проблемы с производительностью, ими займутся системные администраторы, а не вы, и вам не о чем беспокоиться. Это их работа, а не ваша. (Существует очень малая вероятность того, что шаблон действительно вызовет очевидные проблемы, и вам скажут прекратить его использовать, но это произошло только один раз, насколько я знаю, на любом сайте Wikimedia, поэтому я бы не стал об этом беспокоиться.) — Simetrical ( обсуждение • вклад ) 20:02, 10 августа 2007 (UTC) [ ответ ]
    - Очевидно, у меня здесь вообще нет «работы», но если вещи существенно влияют на меня и на то, что я так-так-бесполезно пытаюсь здесь сделать, мне нисколько не поможет, если мне скажут, что мне «не нужно беспокоиться о них». («Я не в состоянии сделать что-либо существенное, чтобы исправить их», ну, очевидно, так.) Миллион элементов в очереди заданий на полурегулярной основе квалифицируется как «проблема» в моей книге (хотя, надо сказать, это не редкость), и я не вижу смысла определять их как несуществующие на основании того, что они выше моей зарплаты или находятся слишком далеко в списке разработчиков того, о чем они считают достойным беспокойства. Alai 20:46, 10 августа 2007 (UTC) [ ответить ]
      - Миллион элементов в очереди заданий на полурегулярной основе — это не проблема, при условии, что число скоро уменьшится, а не просто увеличится. Гарантированно (насколько мне известно, не изучая механику очереди заданий), что изменение любого широко используемого шаблона добавит в очередь несколько сотен тысяч элементов, по одному на каждую страницу, использующую шаблон. Это не значит, что часто используемые шаблоны следует оставлять неизменными навсегда. Если очередь заданий остается очень длинной, это может указывать на проблему, которую заметят и решат системные администраторы. В любом случае, единственная доступная вам цифра очереди заданий — это довольно смехотворно неточная оценка, которая может отличаться от фактического числа в десять раз.
        И это как раз то, о чем я говорю. Вы не имеете права говорить, что повредит производительности сайта, а что нет, и поэтому вам не следует пытаться решать это на уровне политики. Вместо этого вы должны оставить это тем, кто тратит весь свой день на поддержание работоспособности сайта и точно знает, что может вызвать проблемы с производительностью. Проблемы, на которые вы жалуетесь, не «определены как несуществующие», они изначально никогда не существовали. Это эссе/руководство просит вас прекратить придумывать проблемы, которых не существует.
        Если вы хотите серьезно заняться повышением производительности сайта, вам нужно прочитать код и данные профилирования, запустить тесты и иным образом информировать себя. Если вы этого не сделаете, все, что вы собираетесь сделать, это сделать законное, полезное и неразрушающее использование сайта неудобным или запрещенным. Убийство бумажных тигров никому не поможет. — Simetrical ( обсуждение • вклад ) 17:19, 13 августа 2007 (UTC) [ ответ ]
Я думаю, более разумным решением было бы добавить несколько известных исключений. Например, было показано несколько раз, что удаление страницы с десятками тысяч ревизий имеет негативные последствия для сервера. Так что не делайте этого. Правила не высечены на камне. > R a d i a n t < 12:28, 13 августа 2007 (UTC) [ ответить ]
- Я упомянул пару из них в эссе. Я думаю, что все они ограничены системными операторами, и были высказаны идеи по их исправлению (например, маркер «последней неудалённой ревизии» для таблицы страниц, чтобы обрабатывать случай удаления большой страницы). — Simetrical ( обсуждение • вклад ) 17:19, 13 августа 2007 (UTC) [ ответить ]

Удаление песочницы

Действительно ли удаление песочницы приводит к краху сайта? Это уже случалось? user:hillgentleman | user talk:hillgentleman |Sat, 4 Aug 2007 13:12:06 +13:12 13:12, 4 August 2007 (UTC) [ ответить ]

Да и да. — Simetrical ( обсуждение • вклад ) 07:12, 5 августа 2007 (UTC) [ ответить ]

Слишком много правок

В голландской Википедии люди беспокоятся о том, что пользователи делают слишком много правок. Новых пользователей предупреждают не делать слишком много правок на странице, а вместо этого все время использовать «показать предварительный просмотр» перед сохранением. Люди беспокоятся о том, что на серверах закончится свободное место из-за слишком большого количества правок. У нас даже есть специальный шаблон предупреждения для этого. Мне кажется, что не стоит беспокоиться о пространстве на сервере, если речь идет только о тексте. Может ли какой-нибудь системный оператор подтвердить мою точку зрения или сказать, что я не прав?

JacobH 10:11, 4 сентября 2007 (UTC) [ ответить ]

Английская Википедия на несколько порядков больше голландской, и здесь разработчики сказали нам не беспокоиться об этом. Так что да, вы правы, это несколько параноидально. Если вы хотите поговорить с разработчиками, вам следует попытаться связаться с ними по IRC. > R a d i a n t < 10:51, 4 сентября 2007 (UTC) [ ответить ]

Я разработчик программного обеспечения MediaWiki, и я могу вам авторитетно сказать, что нет абсолютно никакого вреда серверам, если делать правки вместо предварительного просмотра. Если Фонду Викимедиа нужно больше места, он может купить больше жестких дисков, которые в настоящее время стоят около пятидесяти центов за гигабайт, и отбросить. Одна дополнительная правка для исправления опечаток и всего остального будет использовать намного меньше килобайта, сжатого, по цене (предполагая репликацию на десять разных дисков) максимум 0,0005 цента. 2000 таких правок в день составят целых 3,65 доллара в год, что составляет порядка одной миллионной бюджета Фонда Викимедиа и стоит намного меньше, чем раздражающие тысячи участников голландской Википедии.

Однако редактирование вместо предварительного просмотра может раздражать в плане засорения истории повторяющимися правками, когда достаточно одной. Вы можете запретить повторяющиеся правки на этой основе. Но, пожалуйста, не беспокойтесь о серверах. — Simetrical ( обсуждение • вклад ) 16:38, 4 сентября 2007 (UTC) [ ответить ]

Re: Дополнение

Мне стало известно, что это упоминается как причина использовать высококачественные изображения вместо изображений низкого качества. Поэтому я должен отметить, что это эссе касается только проблем производительности на стороне сервера, и на самом деле вы можете определенно замедлить загрузку страниц, если забьете их изображениями по 100 КБ. Приемлемо ли это для вас — это выбор редакции, и на самом деле разработчики или системные администраторы не могут или не будут делать ничего, чтобы предотвратить или поощрять это. —Simetrical (обсуждение • вклад) 05:21, 11 июля 2007 (UTC)

Изображения изменяются в размере на стороне сервера и кэшируются в измененном виде (как обнаружил на этой неделе любой, кто не знал об этом), поэтому это руководство по-прежнему применимо. Теперь, количество и размер изображений, размещенных на одной странице, могут влиять на проблемы со стороны клиента/пропускной способности, но я не вижу, как это относится к выбору загрузки изображения 100x100 или 900x900, которое в любом случае будет отображаться на странице с разрешением 50x50. Тот факт, что Image:Whole_world_-_land_and_oceans_12000.jpg не только присутствует, но и используется на World , должен быть основой для сравнения здесь - Учитывая это руководство, нет причин ограничивать размер загружаемых изображений) -- Random832 15:10, 18 сентября 2007 (UTC) [ ответить ]

Видите ли, теперь мое дополнение тоже неправильно истолковывают. :) Я сказал «высококачественные изображения вместо низкокачественных», а не «большие изображения вместо маленьких». Это применимо к PNG против JPEG, где последний меньше, и, возможно, высококачественному JPEG против низкокачественного JPEG. Дело в том, что обслуживание больших изображений не вредит серверам, но замедляет просмотр страниц для пользователей с медленным соединением. Я уточню это еще раз. — Simetrical ( talk • contribs ) 18:27, 18 сентября 2007 (UTC) [ ответить ]

В обсуждении это приводилось в качестве оправдания ограничения общедоступных материалов (с истекшим сроком действия авторских прав) TIME низким разрешением, как будто это было добросовестным использованием; и, что несколько зловеще, для утверждения, что изображения с низким разрешением _в целом_ [даже явно бесплатные изображения] являются "лучшей практикой". -- Random832 18:29, 18 сентября 2007 (UTC) [ ответить ]

Дело в миниатюрах . Размер миниатюр напрямую влияет на качество просмотра для пользователей с медленным подключением. Размер базового изображения — нет. — Simetrical ( обсуждение • вклад ) 02:54, 20 сентября 2007 (UTC) [ ответить ]

Если это действительно проблема (а она может быть), то, вероятно, лучше использовать [[File:...|thumb=whatever.jpg]] - так, чтобы получить преимущество размера JPG с четкостью клика PNG. Это требует дополнительных усилий на стороне редактирования, но для типа страниц с высоким трафиком это, вероятно, не является большой проблемой. GreenReaper ( talk ) 23:05, 26 августа 2009 (UTC) [ reply ]

Кризис связи

Кто-нибудь уже видел страницу Wikipedia:Overlink crisis ? Wikid77 серьезно обеспокоен производительностью и начал вносить изменения, чтобы решить эту проблему. --Explodicle ( обсуждение ) 16:41, 13 февраля 2008 (UTC) [ ответить ]

Спасибо, что упомянули об этом здесь. Я заменил часть Wikipedia:Overlink crisis на объяснение того, почему нет никаких технических проблем, что и есть. Конечно, могут быть еще вопросы эстетики или удобства использования, хотя они кажутся немного незначительными, чтобы называть это «кризисом». — Simetrical ( обсуждение • вклад ) 00:31, 14 февраля 2008 (UTC) [ ответить ]

См. ниже: #Reality обновление июнь/2009. - Wikid77 ( обсуждение ) 08:02, 23 июня 2009 (UTC) [ ответ ]

Упоминание песочницы

Зачем упоминать об этом здесь? Почему бы просто не заблокировать его удаление кем угодно и не решить проблему? -- Emesee ( обсуждение ) 04:50, 15 июня 2008 (UTC) [ ответить ]

Это был просто пример. На самом деле, его удаление сейчас заблокировано, хотя на момент написания это было не так. Почему это заняло так много времени — вопрос, не имеющий отношения к эссе ― в принципе, решение, при котором его можно было удалить без сбоя сайта, было предпочтительнее, и пока не стало ясно, что это не произойдет в ближайшее время, никто не собирался вводить хакерский обходной путь. — Simetrical ( обсуждение • вклад ) 19:12, 15 июня 2008 (UTC) [ ответ ]

В двух словах

Может быть, эта страница могла бы получить поле «эта страница в двух словах», как и многие другие политики Википедии? (например, WP:NPOV ). -- OscarBor ( обсуждение ) 11:23, 30 июля 2008 (UTC) [ ответить ]

Добавлен один. — Simetrical ( обсуждение • вклад ) 16:37, 30 июля 2008 (UTC) [ ответить ]

Спасибо, выглядит хорошо. -- OscarBor ( обсуждение ) 12:16, 3 августа 2008 (UTC) [ ответить ]

Обновление реальности Июнь/2009

23 июня 2009 г.: В 2007 г. я написал эссе « WP: Кризис сверхлинковки », основанное на математических следствиях растущей проблемы. Я не просто «хотел быть правым», но, конечно, к декабрю 2008 г. серверы Википедии больше не могли переформатировать страницы в течение 1 часа, где были изменены навигационные поля. Насколько все стало плохо: (если бы вас здесь не было, вы бы не поверили) в начале 2008 г. серверы переформатировали набор из 400 статей, которые имели измененный навигационный блок, за 4 минуты (эта скорость была одинаковой во многие разные дни); однако к декабрю 2008 г. серверам потребовалось несколько дней, чтобы переформатировать только 20 статей, которые имели измененный навигационный блок. Проверка некоторых из этих статей на следующий день показала, что старый навигационный блок все еще отображался, более 24 часов спустя. Если упростить время задержки до 2 дней или 48 часов для переформатирования 20 статей, тогда как ранее 400 статей обрабатывались за 4 минуты (в любой день в начале 2008 года), то разница в скорости будет колоссальной.

Сравнение скорости для производительности: раньше 400 за 4 минуты, или 100 в минуту (1 за 0,01 мин), против 20 за 48*60 (или 2880) минут, или 1 за 144 минуты. Время, необходимое в декабре 2008 года, было медленнее в 144/0,01 = 14 400 раз, чем в начале 2008 года. Вот что происходит, когда вы «не беспокоитесь о производительности»: она не просто становится вдвое хуже, или в 10 раз хуже, или в 100 раз хуже, или в 1000 раз хуже. Извините, но производительность ухудшается в 14 400 раз (и это низкая оценка). Разница в скорости не просто гигантская, но, скажем так, «Титаник».

Что касается аналогии между « Титаником» и WP:PERF , то, ну, «этот корабль тоже должен быть потоплен».

Как разработчики могли так ошибаться, что то, что сделали пользователи, вместо этого, резко снизило производительность для всех, на несколько дней? ...потому что проблемы производительности очень сложны, и то, что поняли разработчики, было лишь малой частью всей системы. На самом деле, всем нужно беспокоиться о производительности, и чем больше люди изучают проблемы, тем больше они могут сосредоточиться на важных факторах и узнать, какие проблемы относительно незначительны, чтобы их игнорировать. Вопреки представлению «Не беспокойтесь об этом (потому что вы никогда не поймете)» , когда люди работают вместе и обсуждают различные проблемы, тогда действительно происходит более широкое понимание, и люди узнают, что игнорировать, и тогда все могут работать вместе, чтобы все работало быстрее и плавнее.

Итак, перечитайте эссе " WP:Overlink crisis " и другие эссе, свяжитесь с некоторыми полезными разработчиками и начните изучать проблемы производительности и как помочь. То, как пишутся статьи сегодня, может радикально повлиять на производительность через много лет. - Wikid77 ( обсуждение ) 08:02, 23 июня 2009 (UTC) [ ответить ]

Я не понимаю, как это относится к делу. "Не беспокойтесь о производительности" — это предостережение от преждевременной оптимизации вместе с замечанием, что в отличие от прямого эффекта домино, который переработка ваших пивных банок оказывает на популяцию белых медведей, редакторы не могут по отдельности ничего сделать для улучшения глобальной производительности Википедии. Ваш анализ ничего не меняет и, более того, не содержит никаких показателей, которые бы указывали на то, что рекомендуемые вами шаги оказывают какое-либо заметное влияние. Крис Каннингем (не на работе) — обсуждение 09:30, 23 июня 2009 (UTC) [ ответить ]

См. ниже: #Метрики должны объединять тысячи статей. - Wikid77 ( обсуждение ) 10:25, 30 июня 2009 (UTC) [ ответить ]

Насколько все было плохо: (если бы вас здесь не было, вы бы не поверили) в начале 2008 года серверы переформатировали набор из 400 статей, которые имели измененный навигационный блок, за 4 минуты (эта скорость была одинаковой в разные дни); однако к декабрю 2008 года серверам потребовалось несколько дней, чтобы переформатировать только 20 статей, которые имели измененный навигационный блок.

Это стандартный случай post hoc ergo propter hoc . То, что навигационные поля стали больше, а время парсинга увеличилось, не означает, что одно стало причиной другого. На самом деле я могу с большой долей уверенности сказать, что этого не произошло. Время, необходимое для парсинга страниц, по сути, никак не связано с количеством ссылок, ведущих из любого места в любое другое место, и если есть какая-то зависимость, то она должна быть приблизительно линейной. Она зависит в основном от доступного процессорного времени, объема текста, который необходимо парсить, и того, какие еще задачи находятся в очереди заданий по какой-либо причине (в случае обновления шаблона).

Короче говоря, ваша вера в то, что вы понимаете, что вызывает проблемы с производительностью в Википедии и как их лучше всего решать; больше, чем люди, которые потратили годы на оптимизацию производительности сайта; несмотря на то, что вы никогда не вносили существенного вклада в работу сайта, не проводили контролируемые тесты своих гипотез и даже не удосужились довести свои опасения до сведения системных администраторов, а вместо этого пытались убедить пользователей enwiki, которые вообще не в состоянии судить об их легитимности; это именно тот тип отношения и модели поведения, который это эссе пытается опровергнуть.

Если вы хотите, чтобы ваши аргументы были серьезно рассмотрены, я бы посоветовал вам

Получите некоторые фактические данные. Не стройте догадки и не делайте преждевременных выводов. Если вы считаете, что страница с N ссылками будет отрисовываться за O(N ² ), то создайте страницы с различным количеством ссылок и попробуйте несколько раз отрисовать их, и посмотрите, сколько времени это займет. Не пытайтесь угадывать причины поведения на основе неконтролируемых наблюдений, если у вас нет глубокого и конкретного понимания того, как работают соответствующие процессы. Общих знаний в области программирования или компьютерных наук недостаточно: вам нужно знать точные алгоритмы, используемые для априорных выводов.
Излагайте свои доказательства и выводы лаконично и нейтрально и позвольте читателю решить, оправдывает ли одно другое. Не пишите диатрибы или длинные разглагольствования о том, как все остальные были неправы, а вы, увы, правы. Не принимайте полемический или спорный тон. Такие посты побудят людей игнорировать вас.
Разместите на wikitech-l, где информированные люди смогут легче читать и комментировать ваши предложения. Разработчики и системные администраторы обычно не читают случайные эссе enwiki.

До тех пор я бы сказал, что ваши аргументы — это именно те вещи, которые это эссе призвано рассмотреть, и я надеюсь, что его существование способствовало восприятию ваших аргументов таким образом, что это пошло на пользу сайту. — Simetrical ( обсуждение • вклад ) 18:03, 23 июня 2009 (UTC) [ ответить ]

Метрики должны объединять тысячи статей

30 июня 2009 г.: Метрики включают тысячи навигационных блоков в тысячах статей. Это не влияние одного пользователя, а совокупное влияние тысяч пользователей, выполняющих схожие действия. Проблемы росли годами, поэтому приведенные выше комментарии не перечисляют тысячи примеров, которые, вместе взятые, составляют проблему производительности. Пожалуй, я могу упомянуть одну статью, « Марокко », как пример избыточной перелинковки: в этой статье 11 (одиннадцать) нижних навигационных блоков, что удваивает размер статьи за счет добавления еще 840 вики-ссылок (что также удваивает размер HTML data-kb). Вы можете знать, что, кроме того, психологически, люди будут испытывать «опустошение навигационных блоков», когда количество ссылок навигационных блоков вырастет до просто океана «вещей» внизу (но это проблема человеческой производительности, а не нагрузки на сервер). Плюс, эти «1 человек» были очень заняты (используя ботов или убеждая других) ставить навигационные окна на «900» статьях за раз. Старая концепция в информатике называется «данные бродяги» как несвязанные данные, которые требуют обновления затронутых модулей (страниц) просто потому, что кто-то бросил элемент данных (навигационное окно) в конец 10 000 статей.
Между тем, мне нравятся небольшие или ограниченные навигационные окна: нормально поместить редко меняющееся навигационное окно на 50 000 статей или поместить большое, нестабильное навигационное окно на 40 статей. Однако множество людей поместили нестабильные навигационные окна на «900» статей за раз. Почему это стало проблемой: если 900 статей ссылаются на общую статью, эти 900 не нужно обновлять при изменении этой статьи, но 900 статей, использующих общее навигационное окно, нужно обновить (чтобы предоставить точный список для «Что ссылается сюда»). Влияние в 900 раз больше, и когда что-то в 900 раз больше, то производительность, скорее всего, пострадает. Высокоскоростные интернет-соединения, как правило, всего в 50-70 раз быстрее, чем скорости коммутируемого соединения: если пользователи увеличили до 10-мегапиксельных изображений в статьях, то эти 900-кратные данные изображений перегрузят в 50-70 раз более быструю интернет-линию (в 12-18 раз медленнее). Аналогично, когда статьи ранее были связаны только викиссылками (или навигационными блоками, используемыми в 30 статьях), то время задержки было небольшим. Однако навигационные блоки используются в тысячах статей, и многие из них предназначены для изменения каждую неделю (например, «Продукты и менеджеры большой компании ZZZ»). Раньше тенденция заключалась в том, чтобы просто 900 раз ссылаться на статью «Большая компания ZZZ», но теперь тенденция заключается в том, чтобы транслировать 900 раз с коробочным содержимым этой компании-статьи как навигационный блок «Продукты и менеджеры большой компании ZZZ». Вот почему проблема разрастается и становится в 900 раз больше. Надеюсь, это объяснение прояснит вопросы. - Wikid77 ( обсуждение ) 10:25, 30 июня 2009 (UTC) [ ответить ]

Я повторяюсь, но: да, использование шаблонов действительно создает большую нагрузку на сайт, и единственное, что действительно помогло бы производительности сайта, — это быть более осторожным с часто используемыми шаблонами. (Домас предложил, чтобы мы предоставляли пользователям данные профилирования шаблонов и поощряли их оптимизировать самые дорогие шаблоны. Это был бы особый случай, к которому это эссе не применимо, поскольку усилия по оптимизации были бы выполнены по запросу разработчика.)

Но это не имеет никакого отношения к количеству ссылок . Единственная стоимость здесь — повторный анализ всех страниц. Неважно, содержит ли шаблон сотню ссылок или один символ ASCII, если он изменился, то страницы, на которых он находится, должны быть очищены из кэша и повторно проанализированы. Это все, что имеет значение. Если есть ссылки, то WhatLinksHere (таблица pagelinks) должна быть обновлена, но даже если это просто текст страницы, мы должны обновить фактическое содержимое страницы. Стоимость обновления pagelinks незначительна по сравнению с фактической операцией анализа (которая требуется для выяснения того, как должны быть обновлены pagelinks).

И если вы не можете запустить метрики самостоятельно, чтобы напрямую измерить, есть ли проблема, вы все равно можете предложить добавить профилирование в программное обеспечение, и, возможно, написать поддержку самостоятельно. Анекдотические свидетельства бесполезны в любом случае. — Simetrical ( talk • contribs ) 21:18, 1 июля 2009 (UTC) [ ответить ]

Обновление реальности Май/2010

К концу 2009 года многие люди осознали, что essay WP:PERF не является оправданием для использования больших изображений или массивных шаблонов в часто читаемых статьях. К сожалению, использование навигационных блоков продолжало расти, например, в медицинских статьях, при этом многие добавляли несколько навигационных блоков, в общей сложности более 2500 дополнительных вики-ссылок в нижних навигационных блоках. Как и следовало ожидать, люди перестали размещать каждый навигационный блок на "каждой" возможной статье, например, использовать навигационный блок только на 50 из 700 статей, связанных в навигационном блоке. Медленные или громоздкие шаблоны вызывали загадочные фатальные ошибки, все еще в мае 2010 года (см. ниже: "#Template limits cause: WIKIMEDIA FOUNDATION ERROR" ). - Wikid77 08:57, 8 мая 2010 (UTC) [ ответить ]

Причина ограничений шаблона: ОШИБКА ФОНДА WIKIMEDIA

08 мая 2010 г.: В период с 2009 по 2010 г. некоторые массивные шаблоны при многократном использовании на странице вызывали длительную задержку, за которой следовало сообщение об ошибке Wikimedia Foundation, как показано ниже:

Поскольку экран читателя полностью перезаписывается этим окном сообщения, пользователям необходимо понять, какая страница, которую они пытались прочитать, привела к экрану ошибки Wikimedia. Если страница, вызвавшая ошибку, изменена для использования более быстрого шаблона, то эта страница сообщения WIKIMEDIA больше не отображается повторно. - Wikid77 ( обсуждение ) 8 мая пересмотрено 11:37, 13 мая 2010 (UTC) [ ответ ]

Я думаю, эта драма произошла, когда я был под постоянным запретом.

Был ли симметричный неправильным, а Wikikid правым? TCO ( обсуждение ) 06:51, 12 июля 2013 (UTC) [ ответить ]

Я, конечно, не эксперт, но в целом ответ, похоже, «Симметричный». Вы можете увидеть номера очередей заданий на https://gdash.wikimedia.org/dashboards/jobq/ В последнее время, похоже, что в обычный день отправляется двадцать или тридцать миллионов заданий. Обрабатывается почти всегда одинаковое количество, хотя всякий раз, когда кто-то отправляет миллионы заданий больше, чем обычно (возможно, массово перемещая кучу шаблонов или изменяя один из тех немногих шаблонов, который используется на миллионах страниц), требуется некоторое время, чтобы наверстать упущенное. Когда это происходит, люди замечают и (справедливо) жалуются; когда этого не происходит, что случается большую часть времени, вы просто не слышите много об очереди заданий. Но если у вас уже двадцать или тридцать миллионов заданий в день, то добавление нескольких сотен или даже нескольких сотен тысяч в список просто не будет иметь большого значения.

И если бы это имело значение, то, по моему мнению, правильным способом исправить это было бы выделение большего количества ресурсов для очереди заданий, а не говорить редакторам, что им в любом случае нужно предоставлять меньше вариантов навигации. Избыточные ссылки являются проблемой, когда они вредят читателям, а не когда они на некоторое время перегружают компьютерную систему.

Как я уже сказал, я не эксперт, и если разработчики считают, что я полностью не прав, я уверен, что кто-то из них опубликует более точный ответ. Но такова ситуация, как я ее понимаю. Whatamidoing (WMF) ( talk ) 05:56, 17 марта 2014 (UTC) [ ответить ]

Обновление спустя 10 лет?

Эти сведения: «Эта платформа образует кластер из более чем четырехсот серверов, с более чем пятью терабайтами оперативной памяти и более чем 2400 процессорными ядрами […]» и «[…] ограничения на включение шаблонов, блокировка удаления страниц с более чем 5000 ревизий и максимальный размер страниц 2 МБ» — им уже около 10 лет. А что насчет сегодняшнего дня? Мне также была бы интересна информация об общем объеме памяти Википедии во всем мире. — Bestoernesto ( обсуждение ) 22:30, 9 июня 2016 (UTC) [ ответ ]

Редакторам Bestoernesto , Wikid77 и SMcCandlish и другим: Я хотел бы отметить , что состояние таких проблем с производительностью (используя Template:As of возможно?) должно быть обновлено на этой странице проекта, где это применимо, и определенно на этих трех других: Я пришел сюда из Wikipedia:Overlink crisis . Эту страницу я нашел в разделе See also в Wikipedia:Page Reformat Crisis , эссе, написанном и последний раз отредактированном в 2014 году. В этом разделе также упоминается Wikipedia:Wikimedia Foundation error , в котором, в частности, говорится:

Это сообщение создает впечатление, что веб-серверы «слишком заняты», чтобы ответить, но часто это вызвано сложностью страницы, которую нужно отобразить. Довольно часто это можно увидеть после редактирования сложной статьи, такой как Barack Obama. Обычно ваша правка успешно выполняется, но вы не видите результат сразу. Это может раздражать редактора. Это известный побочный эффект сложных страниц, который указан как проблема 19262.

Упомянутая проблема ( «T21262 Страницы с большим количеством шаблонов испытывают чрезвычайно медленную отрисовку или превышение времени ожидания чтения для вошедших в систему пользователей». phabricator.wikimedia.org .) отмечен как Закрыто, Решено с последними комментариями в мае 2013 года с одобрением. Однако эссе Page Reformat Crisis было написано в следующем году, что указывает на то, что некоторая проблема все еще существует, и с тех пор прошло несколько лет. Следует ли отметить три страницы проекта, которые я упомянул выше, как исторические, или их следует обновить или объединить?

Извините, все, что я могу сделать, это указать на это, но мои реальные ограничения не позволяют мне сделать больше. Кроме того, я не смог прочитать ни одну из этих страниц с необходимой глубиной, чтобы сравнить их дальше, поэтому я могу связывать воедино несвязанные проблемы или размещать это не в том месте. Заранее спасибо за всю вашу тяжелую работу! — Geekdiva ( talk ) 10:32, 5 апреля 2017 (UTC) [ ответить ]

Проблема реальна и сохраняется; я вижу эту ошибку время от времени. С другой стороны, я не посвящен во внутреннюю работу сервера, так что возможно, что она (или практически неотличимое сообщение об ошибке) также вызвана какой-то другой проблемой, а не той, которая, как утверждается, была решена в 19262. Поскольку у меня нет такого доступа, я также не знаю, как обновить страницу новой статистикой. Я согласен с идеей слияния; нам не нужно несколько страниц об этом, и у нас слишком много непонятных пользовательских эссе, большинство из которых следует объединить в набор более полных страниц. —  SMcCandlish ☺ ☏ ¢ ≽ ^ʌ ⱷ҅ _ᴥ ⱷ ^ʌ ≼ 02:07, 16 апреля 2017 (UTC) [ ответить ]

Редакторы все еще должны играть свою роль

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

Я думаю, что читателям было бы полезно ознакомиться с некоторыми общими принципами о том, о чем стоит беспокоиться, а о чем нет, или примерами того, о чем стоит беспокоиться . Если бы я мог попытаться подвести итог вышеизложенным обсуждениям, то чрезмерные шаблоны, похоже, являются проблемой, даже если лучше оставить ее решение разработчикам. Overlink уже упоминался, поэтому читателей можно перенаправить к другим руководствам, таким как WP:OVERLINK, которые рассматривают эти проблемы как вопрос стиля и содержания, а не как проблему производительности.

Вместо того, чтобы говорить читателям, чего не следует делать, лучше проявить позитивный настрой и порекомендовать редакторам то, что им следует делать, поместив раздел «Редакторы играют свою роль» выше в статье и добавив в него больше пояснений. -- 109.79.73.193 ( обсуждение ) 12:41, 21 декабря 2018 (UTC) [ ответить ]

Идея изменить информационную страницу

«В некоторых случаях системные операторы могут сделать что-то, что замедлит работу сайта или приведет к его сбою. Это случается редко и, как правило, не стоит беспокоиться; хотя есть несколько действий, которые администраторы могут совершить злонамеренно и которые очень трудно исправить, ни в коем случае нельзя допускать того, чтобы что-то привело к постоянной потере данных или неустранимой поломке».

Я бы упомянул, что большинство вещей можно восстановить из дампа данных, даже в случае повреждения базы данных. И несколько общедоступных файлов конфигурации на Gerrit. Может быть, кроме AbuseFilter, конфигурации пользователя (с паролями), удаленных вкладов(?)... Предполагая, что даже если основная БД уйдет в прошлое, есть надежда, поэтому потеря данных маловероятна (также зеркала) Luhanopi ( обсуждение ) 15:10, 4 сентября 2024 (UTC) [ ответить ]