↓
 ↑
Регистрация
Имя

Пароль

 
Войти при помощи
Картинки ссылками
До даты

Все новые сообщения

ReFeRy
15 января в 19:32
#внутренности_фанфикса #будни_админа #исправление_ошибки #веб_разработка

Вот уже около недели анализирую лог медленных запросов к БД, вношу изменения в код или в структуру БД для устранения узких мест. Удалось ускорить несколько групп запросов.

- Часть проблем была связана с тем, что Фанфикс вырос. Когда код писался, данных в БД было значительно меньше, и написанный тогда запрос не приводил к проблемам. Позднее стал тормозить на большом объеме данных.

- Ещё часть проблем это мои ошибки в проектировании запросов, неверные решения, принятые, когда от не знания, когда от недостатка опыта, когда по недосмотру.

- Существенная часть проблем - это нехватка каких-то индексов в БД. Фанфикс я пишу долго, при создании таблицы могли быть нужны одни индексы, а потом был дописан новый функционал, запросы к БД стали более разнообразными, а необходимые индексы вовремя добавлены не были.

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

Что по итогам:

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

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

- Никуда не делать проблема ежедневного бэкапа. Каждую ночь сайт очень сильно тормозит в течение примерно часа. С этим пока ничего не делал. Решение существует. В этом должен помочь второй сервер, который я арендовал в ноябре. Надо реализовать репликацию - это технический процесс, когда все изменения в базу данных одновременно вносятся на два сервера. Одновременно существует две копии базы данных. Тогда бэкапить можно будет дублирующую БД, а основная в этот момент не будет тормозить. Сложностей тут несколько: во-первых, я этого ещё никогда не делал - надо внимательно изучить вопрос и просто решиться, во-вторых, процесс репликации увеличивает среднюю постоянную нагрузку на базу, надо будет убедиться, что сервер это без проблем выдерживает, в-третьих, репликация требует прилично свободного места на диске, надо убедиться, что его достаточно, ибо у основного сервера Фанфикса диски быстрые, но довольно маленькие.

Работаю дальше.
Свернуть сообщение
Показать полностью
ReFeRy
15 января в 02:33
#технические_работы #внутренности_фанфикса #исправление_ошибки

Обещанные на вчерашнюю ночь работы произведены сегодня. Добавлен индекс на очень большую и важную таблицу. Это должно ускорить некоторые запросы, которые раньше могли тормозить.
ReFeRy
14 января в 17:47
#внутренности_фанфикса #исправление_ошибки

Нашел наиболее вероятную причину, почему сайт притормаживал в полночь. В 00:02 запускается скрипт, который обновляет статистику фандомов (в энциклопедию когда заходите, там некоторые строки статистики обновляются только раз в сутки). Вот в этом обновлении статистики у меня был написан довольно сложный запрос, для выполнения которого БД анализировала 75 миллионов строк. Сегодня ночью этот запрос выполнялся 52 секунды, пока он выполнялся БД могла тормозить на остальные запросы и ещё минуту-две после этого.

Переписал весь скрипт, теперь он посылает всего один не очень тяжелый запрос, потом в цикле считает данные по фандомам и обновляет только те фандомы, где цифры поменялись. В тестовом прогоне получилось гораздо быстрее, чем предыдущая версия.

Примечательно, что этот скрипт я уже оптимизировал. Самая первая версия всё делала за счет одного запроса в БД. Сейчас я прикидываю, что тот запрос должен был пройтись примерно по 250 миллионам строк. В прошлый раз я заменил этот супер-тяжелый запрос на просто тяжелый + цикл по одному запросу на обновление каждого фандома. Получилось ~1800 запросов вместо одного, но это работало быстрее и меньше грузило сервер, чем один супер-тяжелый запрос. Сейчас я написал один совсем не тяжелый запрос (просматривает 48 тысяч строк), затем идёт цикл по этим же 48 тысячам строк, а потом примерно 700-800 запросов на обновление данных в БД. Тестовый прогон скрипта выполнился менее чем за две секунды, что для скрипта, выполняющегося один раз в сутки, нормально. А запрос на вывод данных вообще занимает всего несколько десятков микросекунд, то есть БД не блокируется, другим запросам этот скрипт не мешает.
Свернуть сообщение
Показать полностью
Показать 5 комментариев
ReFeRy
12 января в 20:32
#фанфикс #технические_работы #внутренности_фанфикса

Если не усну, то где-то ночью по москве будут техработы - выключу сайт на полчаса-час. Надо добавить новый индекс на таблицу в 25 миллионов строк, при работающем сайте это нереально провести.

P.S. За вчера и сегодня подлечил несколько узких мест, которые приводили к излишней нагрузке на БД, из-за чего страницы сайта могли генерироваться по несколько секунд вместо нескольких микросекунд. Работаю дальше.
Показать 1 комментарий
ReFeRy
10 января в 13:58
#внутренности_фанфикса #исправление_ошибки

Вчера и позавчера мне пару раз жаловались, что сайт иногда тормозит или не отвечает. Но я не попадал на такие моменты. Сейчас вот попал и смог посмотреть, в чем проблема. Оказалось, что проблема не новая, я уже пытался её решить в октябре - вот описание проблемы и решения https://fanfics.me/message476095

Нюанса два:

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

2. Самое последнее предложение в посте от октября "Сейчас ещё припишу проверку на параллельное создание кэша, и будет вообще хорошо". Я это сделал, но сделал неправильно. Как и в первом пункте, облегчил ситуацию, но только чуть-чуть и не решил проблему окончательно.

Прямо сейчас я исправил второй пункт - параллельно теперь запросы точно не пойдут. Буду думать, как решить проблему кардинально.
Показать 7 комментариев
ReFeRy
26 ноября 2020
#внутренности_фанфикса #фанфикс

Предположительно ошибка с работоспособностью меток на странице чтения фанфика решена. У кого она была, проверьте, проблема ещё есть или исчезла?
Показать 3 комментария
ReFeRy
26 ноября 2020
#исправление_ошибки #внутренности_фанфикса

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

1. Исправлена ситуация, когда при попытке повторно поставить метку выводилась "ошибка при добавлении в избранное". Теперь метка просто проявляется на странице.

2. Часто юзеры имеют минимум две открытые вкладки с одним и тем же фанфиком и ставят метку с этих двух вкладок.

Анализирую дальше. Где-то проблема все же есть, но я не знаю где.

P.S. Вопрос про не работающие метки на странице чтения всё ещё актуален.
Показать 5 комментариев
ReFeRy
25 ноября 2020
#фанфикс #внутренности_фанфикса

У кого есть проблема с меткой "Пометить прочитанным" в конце текста фанфика?

Мне нужен скриншот консоли браузера после загрузки страницы (f12 в винде надо нажать). Если там много всего в консоли и есть прокрутка, то в скиншот должна попадать ошибка.
Показать 16 комментариев
ReFeRy
12 ноября 2020
#внутренности_фанфикса #публичная_бета

Работа над публичной бетой немного затормозилась, у меня тут в реале дела нарисовались, да ещё интересную серию книг подкинули, да Волди требует внимания, а Иоланта болеет.

Тем не менее, уже работоспособен механизм отправки сообщений читателями - при выделении текста появляется плашка, по клику на плашку или по нажатию Ctrl+Enter появляется окно сообщения, сообщение отправляется и сохраняется в БД (работает только у меня на локальной машине).

Обдумываю раздел просмотра сообщений автором. Выходит, что надо реализовывать все те же разделы, что и для "Истории изменений" - общий раздел в "Работе с фанфиками", в котором будет три вкладки: Мои произведения, Соавтор/сопереводчик, Бета; лента сообщений по конкретному фанфику и лента сообщений по конкретной главе. В связи с такими планами не очень понятно, как реализовывать привычный механизм "Сохранить изменения и перейти к следующему сообщению" - видимо придётся запоминать, из какой ленты автор перешёл на сообщение об ошибке и из той ленты выдавать следующее сообщение.

В историю изменений записи буду делать по тому же принципу, что и правки со страницы чтения текста - если автор делает несколько правок из ПБ подряд, они в течение часа объединяются в одну запись.

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

После основного функционала надо будет дописывать полезные мелочи: работу ЧС, доступ к ПБ соавторам/бетам, учёт статистики.

P.S. У меня вертится в голове мысль попытаться встроить образовательный элемент. В форму отправки сообщения об ошибке добавить поле поиска соответствующего правила (подсказали неплохой справочник), соответственно, автор сможет прочитать, в чём именно он ошибся и, возможно, намотать на ус. Указание правила будет не обязательным. Вопрос лишь в том, как реализовать поиск по правилам так, чтобы можно было в пару слов найти нужное...
Свернуть сообщение
Показать полностью
Показать 15 комментариев
ReFeRy
4 ноября 2020
#будни_админа #публичная_бета #внутренности_фанфикса

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

Например, вчера потыкал фикбук палочкой, и у меня ни разу не получилось, чтобы при выделении ошибки на стыке двух абзацев, фикбук смог "найти это место в тексте", всегда выдаёт ошибку.

И это только на "примерное понимание". Сейчас буду пытаться реализовать это в коде. А потом ещё кучу интерфейсов писать, где сложностей уже никаких особо не будет, но объём работы громадный.
Показать 16 комментариев
GlortZ
23 октября 2020
#внутренности_фанфикса
Как же шрифты колбасит при просмотре на планшете в разделенном режиме. Раз два
З.Ы. Android 9, браузер Vivaldi 3.2.1996.30, дисплей 10" 1920х1200
Показать 1 комментарий
ReFeRy
2 октября 2020
#внутренности_фанфикса #будни_админа #исправление_ошибки

Сегодня в 12 сайт затормозил и какое-то время даже был совсем недоступен (504), я как раз оказался на рабочем месте. Быстрый анализ ситуации выявил конкретную причину проблемы, но не предпосылки. Однако и эту вот "причину" стоило устранить. Внезапно затык случился из-за принятого много лет назад неверного решения.

Есть у нас на главной странице блок "Пользователи онлайн". Информация о том, в каком разделе сайта находится пользователь, пишется в БД при каждой загрузке страницы. Нужна эта информация исключительно для вот этого блока, больше она нигде не используется. Блок закеширован, создаётся он раз в пять минут, следующие пять минут он грузится из кэша. Проблема в том, что в БД я поместил прямо текстовое значение: "Зависают в каком-то фандоме" и т.д. При построении блока шел агрегирующий запрос по varchar полю без индекса... по таблице на 630000 строк. И кэш у меня создаётся без проверки на параллельное создание этого же кэша.

Сегодня видимо, что-то подгрузило сервер, в тот же момент закончилось время жизни кэша этого блока, в БД полетело сразу несколько описанных выше запросов, БД стала нажирать оперативку на выполнение этих запросов (создание временных таблиц), оперативка закончилась, новые запросы продолжали поступать, так как кэш всё ещё отсутствовал, новые временные таблицы стали создаваться на диске, БД висела, сервер висел.

Когда я заглянул в список процессов, москаль нажрал уже более 15 Гб оперативки, хотя обычно ему хватает 5. Я убил самые старые запросы и запросы, которые пытались создать временные таблицы на диске, сайт не отвечал, это позволило кэшу создаться, ситуация начала выравниваться. Перезагружать ничего не пришлось.

Чтобы подобного не происходило в будущем переделал хранение информации о том, в каком разделе сайта находится пользователь. Создал массив возможных категорий и отдельно создал функцию, которая на входные параметры выдаёт ключ массива с нужным значением. Тут нюанс в том, что одному значению, например "Работают над новым фандомом", соответствует несколько технических разделов сайта, то есть ключом массива не может служить название раздела. Теперь в таблицу юзеров помещается ключ массива категорий, и на это требуется поле типа tinyint, по которому строится индекс. Агрегирующий запрос всё равно получился относительно тяжелый - с созданием временной таблицы, но скорость его выполнения в десятки раз выше, чем раньше и места он в памяти занимает меньше. Это тоже далеко не идеальное решение, можно сделать гораздо лучше, но данного решения при текущей нагрузке хватит. Сейчас ещё припишу проверку на параллельное создание кэша, и будет вообще хорошо.
Свернуть сообщение
Показать полностью
Показать 6 комментариев
ReFeRy
26 сентября 2020
#внутренности_фанфикса

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

У кого так - какой у вас браузер, стоят ли какие расширения? В обсуждения в блогах переход тоже на начало страницы или к комментариям?

У кого всё работает нормально?
Показать 20 комментариев из 29
ReFeRy
23 сентября 2020
#внутренности_фанфикса #будни_админа

Большое обновление зависло из-за того, что оно большое, там десяток таблиц в БД будет удалено/изменено/добавлено, около 50 скриптов обновлено и т.д. Без косяков точно не обойдётся. Сайт надо останавливать. По всем этим причинам я все выбираю день. Ибо осень что-то напряжная, одни только утренние тренировки три раза в неделю чего стоят. Сейчас вот внезапно сижу у залива, привёз Ксю и клиентов на съёмку, дети по врачам ходят, Волди два раза в неделю на занятия водить, ну а выходные вообще расписаны до зимы...

И дописано обновление уже с неделю. Поэтому, когда выдаётся время на Фанфикс, я начал приписывать вещи, не запланированные ранее. В основном это внутренние изменения и исправления старых косяков. Но вчера вдруг решил приделать на страницу чтения выбор цвета текста и фона. Заодно переделаю хранение настроек текста в куки, а не в БД. Это позволит на каждом устройстве иметь свои настройки - на ПК одно, на телефоне другое.
Показать 2 комментария
ReFeRy
22 сентября 2020
#внутренности_фанфикса #будни_админа

Нашел и решил проблему со сбоями в отображении в "моя статистика" данных по анонимным фанфикам. Выкатить в прод смогу со следующим крупным обновлением.
Показать 1 комментарий
ReFeRy
21 сентября 2020
#внутренности_фанфикса #конкурсы_на_фанфиксе

Пара идей по конкурсам:
- Сделать визуализацию прогресса чтения всего конкурса и/или по номинациям, как вот тут для подборок: https://litrpg.ru/best_books_litrpg
- Сделать такую же визуализацию для комментирования конкурса: "прокомментировано 12 из 88 работ"
- Сделать кнопку "случайный конкурсный фик"
- Сделать возможность выбирать порядок номинаций и работ в номинациях - по алфавиту, по количеству фанфиков/по размеру фанфиков, в случайном порядке...
Показать 7 комментариев
ReFeRy
19 сентября 2020
#будни_админа #внутренности_фанфикса #исправление_ошибки

Оказалось, что на сервере не работает ntp, поэтому были проблемы с точностью времени. Поставил htpdate, работает, синхронизирует. Больше проблем с отставанием времени сервера быть не должно.
Показать 2 комментария
ReFeRy
17 сентября 2020
#внутренности_фанфикса

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

P.S. Это всё ещё не работает на сайте. Ждём новости о большом нововведении.
Показать 10 комментариев
ReFeRy
15 сентября 2020
#внутренности_фанфикса

Нужен ли при написания поста в блог режим предпросмотра?

Публичный опрос, Завершен

Да!
Нет...
Проголосовали 106 человек
Голосовать в опросе и просматривать результаты могут только зарегистрированные пользователи
Показать 17 комментариев
ReFeRy
15 сентября 2020
#внутренности_фанфикса

Чем глубже в код, тем толще проблемы от дополнительных опций...

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

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

И вот. Автор пишет комментарий к своему анонимному фанфику. Скрипт вывода комментариев для каждого комментария должен проверить, не анонимный ли фанфик, а если анонимный, то не автор ли или переводчик именно этого фанфика пишет комментарий.

А теперь представим себе, что автор анонимного фанфика отвечает комментатору, который не подписан на обсуждение. Этому комментатору придёт уведомление о том, что его упомянули в таком-то комментарии к такому-то фанфику. Скрипт страницы уведомлений, мало того, что должен посмотреть, что это за уведомление, вытащить из базы комментарий, так ещё он должен проверить, не к анонимному ли фанфику этот комментарий, а если к анонимну, то не автор ли или переводчик именно этого фанфика пишет комментарий.

Это не так уж сложно, на самом деле. Только кода много. Все подобные случаи надо предусмотреть, все условия описать.

P.S. Все ведь помнят, что имя автора/переводчика анонимного фанфика нельзя никому показывать - вот в этом и сложность.


Существуют разные подходы к написанию скриптов сайта. Есть подход, который сейчас используется в вебе чаще всего, ибо он экономит время разработки. На каждое мелкое действие пишется самодостаточная функция, а потом, если на странице нужно это действие, то просто вызывается эта функция. По аналогии, как дом строится из кирпичиков. То есть, можно было бы написать функцию, которая получала бы на вход id комментария, а внутри проверяла все возможные условия для этого комментария и выводила его для просмотра. Таким образом в любом месте сайта, где понадобилось бы вывести комментарий, достаточно было бы просто вызвать эту функцию. Но этот подход совершенно не экономит машинное время. Представьте себе, что на странице 20 комментариев - для каждого комментария функция, которая его выводит, запросит из базы данных: сам комментарий, информацию о фанфике, информацию об авторах фанфика. Вуаля, 60 запросов к БД. Тогда как можно сделать лишь три запроса: выбрать все 20 комментариев, выбрать все 20 фанфиков, выбрать авторов всех 20 фанфиков, а потом в отдельном скрипте всё это проанализировать и собрать страницу.

В первом подходе, чтобы создать новую страницу, содержащую какие-то комментарии, достаточно создать саму страницу, выбрать из БД, по определённому условию, список id комментариев и для каждого комментария вызвать функцию его вывода. Это быстро для разработки. Но эта страница будет медленно собираться и сильно нагружать базу данных.

Во втором случае надо проанализировать в каком месте скрипта, какие данные можно агрегировать и выбрать из базы наименьшим количеством запросов (не всегда меньше запросов = меньше нагрузки, и это лишь добавляет ещё задач на подумать), а потом надо написать уникальный скрипт, который будет анализировать выбранные данные именно в том порядке и виде, который получится оптимальным для данного скрипта. Это долго по разработке, но позволяет сайту быстрее работать и выдерживать большую посещаемость без удорожания услуг хостинга.

Это всё сильно упрощённо. В общем, я отдохнул от кода, пора возвращаться к работе :)
Свернуть сообщение
Показать полностью
Показать 6 комментариев
Показать более ранние сообщения

ПОИСК
ФАНФИКОВ







Закрыть
Закрыть
Закрыть