Ускорили сайт ДОУ

За шрифты на ДОУ отвечает код типа

@import url('https://fonts.googleapis.com/css?family=PT+Sans+Narrow:700|PT+Sans:400,400italic,700&subset=latin,cyrillic');

он грузит шрифт PT Sans из Google-шрифтов, пока не знаю, в чем может быть проблема с этим, попробую потестировать еще.

Как workaround можно попробовать установить локально шрифт
www.paratype.ru/uni/public/PTSans.zip

И аналогично сделал для главной (dou.ua), там раньше часть зеленых кружочков грузились аяксом, а часть нет, теперь все аяксом.

Якщо маються на увазі запити, які (failed) і червоним кольором, то таке враження, що вони failed через якийсь блокувальник реклами чи щось подібне.

З такими сторінками (коментарів) ще не розібрався. Останні 7 днів я займався оптимізацією різних інших сторінок і функцій на DOU, в цілому сайт по ідеї повинен почати працювати дещо швидше, деякі запити чи сторінки — набагато швидше, ніж раніше, але з конкретно сторінками коментарів поки що стало не набагато краще.

Дякую, поки що, на жаль, нічого такого немає, щоб показати, я напишу, як знайду.

Тут s.dou.ua/...​-files/index_comments.png в обох випадках SQL генерується через ORM, так що його дость складно модифікувати.

А нова версія вийшла в тисячі раз швидшою за стару, тому немає особливого сенсу її ще більше оптимізувати.

А нельзя ли поправить баг с чтением комментов по J/K? Если вернуться по K назад, то по J отсчет продолжается с этого места, в итоге доходит до 0 раньше времени и нельзя прочитать все непрочитанные комментарии

Пока, к сожалению, не разобрался, разбирался с медленными запросами, а то Load Average было больше 15 :(

Как альтернативу (плохую, но вроде рабочую), можно пока попробовать использовать кнопку браузера «Назад» (или соотв. hotkey типа Alt+Left Arrow) для предыдущих комментариев.

Вчора її уже запустив, це ж для блоку коментарів на головній, він оновлюється раз на 10 хвилин приблизно:
i.imgur.com/rzMHPIj.png

Насправді подібний підхід я застосував ще в одному місці — там де генерується RSS,
тут мені сподобалось, що зовсім проста зміна в коді дала відразу відчутне прискорення.

Сьогодні частково переписав код шаблон для коментарів (в топіках), час генерації (TTFB) топіка з 3341 коментарем скоротився приблизно з 11 до 8 секунд.

В топіках з великою кількістю коментарів найбільше часу на сервері витрачається на генерацію html-дерева коментарів. Там складний Jinja-шаблон, тому він повільний, але я уже почав розбиратись з ним.

У сервера DOU теж досить потужна машинка :)

Я не планую переносити рендеринг на клієнт.

Сьогодні вдалось встановити новий рекорд швидкості — 6.51с:
i.imgur.com/u8ykAoP.png

А ось швидкість для незалогіненого користувача:
i.imgur.com/H2JRfVS.png

Насправді для незалогінених видається готове дерево коментарів з кеша :)

У memcached еще есть по умолчанию лимит 1 мегабайт, но для больших списков комментариев его мало, потому на DOU лимит 10 мегабайт.

А вже друге завантаження, справді, використовує кеш браузера і відбувається за 200 мс.

Ні, це не кеш браузера, а кеш з сервера, див.
i.imgur.com/WXHUtbx.png

Тому що різний кеш для різних мов інтерфейсу.

Оу, заліковно! Але до 4 секунд, як би було при рендерінгі на клієнті — ще далеко.

Уже недалеко:
i.imgur.com/lJiRmV1.png

Тестів мабуть немає, але навряд чи такі зміни в коді як я робив в коментарях потребують тестів, у всякому випадку мені не здається, що вони тут би пригодились.

Сьогодні, до речі, новий рекорд — 3.82с:
i.imgur.com/NX3UJxI.png

UPD, сьогодні новий рекорд 6с, на 0.5с менше попереднього:
i.imgur.com/kBNxTjy.png

Рівень складності і заплутаності поступово зменшую, уже трохи процентів на 40 генерується швидше ніж раніше.

Ще була проблема з хостингом, теж почали вирішувати.

Зараз лайки записуються в кеш, плюс беруться з redis, так що не повинні сильно тормозити.

Не дуже нормально, але треба враховувати що в вона передається в gzip і розмір виходить 900Кб

Виправив.

в обох випадках SQL генерується через ORM, так що його дость складно модифікувати.

ORM considered harmful

В Django можно делать raw sql queries (и на ДОУ в нескольких местах это используется), но полностью отказываться от ORM наверное неоправдано в большинстве случаев.

Поки що таку можливість не розглядали. Зараз на сайті і так досить велика БД з великою кількістю таблиць (> 100), використовувати дві БД замість однієї мабуть невиправдано. А ще зараз використовується Redis, з ним і MongoDB було б три БД.

За останній тиждень у десь двох десятках місць на сайті вдалось або прискорити запити, або зменшити їх кількість без особливих змін в коді (і взагалі не чіпаючи структуру БД (і при цьому вдалось нічого не зламати)), поки що спробую таке продовжити, а потім уже думати, що потрібно робити далі і чи потрібно.

Запустив в MySQL з цікавості основний SQL-запит для вибору коментарів цього топіка, видало таке:
3341 rows in set (0.03 sec)

Але я ще не розбирався з коментарями і їх генерацією.

mysql> explain SELECT `content_comment`.`id`, `content_comment`.`content_id`, `content_comment`.`author_id`, `content_comment`.`typotext`, `content_comment`.`created`, `content_comment`.`depth`, `content_comment`.`parent_id`, `comment_parent`.author_id as parent_user_id FROM `content_comment` FORCE INDEX (deleted) LEFT OUTER JOIN content_comment comment_parent ON comment_parent.id = content_comment.parent_id WHERE `content_comment`.`deleted` IS NULL AND `content_comment`.`content_id` = 51064 ORDER BY `content_comment`.`tree_id` DESC, `content_comment`.`lft` ASC;
+----+-------------+-----------------+------------+--------+---------------+---------+---------+------------------------------------------+------+----------+---------------------------------------+
| id | select_type | table           | partitions | type   | possible_keys | key     | key_len | ref                                      | rows | filtered | Extra                                 |
+----+-------------+-----------------+------------+--------+---------------+---------+---------+------------------------------------------+------+----------+---------------------------------------+
|  1 | SIMPLE      | content_comment | NULL       | ref    | deleted       | deleted | 6       | const,const                              | 3341 |   100.00 | Using index condition; Using filesort |
|  1 | SIMPLE      | comment_parent  | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | dou_production.content_comment.parent_id |    1 |   100.00 | NULL                                  |
+----+-------------+-----------------+------------+--------+---------------+---------+---------+------------------------------------------+------+----------+---------------------------------------+
2 rows in set, 1 warning (0.00 sec)

Це до чого було? Наскільки я розумію, я показав реальний запит.

51064 це ID поста «Ищу парня», якщо про це іде мова.

Ні, це експлейн вибірки всіх коментарів поста у якого id=51064,

Важливо не плутати

`content_comment`.`id`

з

`content_comment`.`content_id`

:)

Для вибірки коментарів конкретної теми використовується саме цей запит, інших важливих (які вибирають всі коментаррі теми) запитів немає (якщо не брати до уваги запити для блоку «Схожі топіки» чи «Популярні коментарі»). Скоріше за все причина повільності не в SQL-запитах (які виконуються, коли відкрити топік), а в чомусь іншому, якщо я розберусь, то напишу.

22039 це «ID топіка», а коментарі прив’язані до «ID контенту», цим «контентом» можуть бути і топіки, і статті, і події календаря.

Ну там 1 запит, який вибирає інформацію про топік по ID топіка, повертає 1 рядок і виконується менше кількох мілісекунд, нічого цікавого :)

Спасибо, починили

Здається 304 виводиться, якщо натиснути F5, а якщо просто так відкрити сторінку — не виводиться.

Пришлось обновить nginx до последней версии и перейти на https.

media.giphy.com/...5xy5TiWFQxQFUME/giphy.gif

Можете, попробовать открыть ссылки, которые не работали, они уже начали работать или все еще не работают?

Мені найбільше не вистачало оперативної пам’яті.

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

У dou.ua/...rticles/dont-move-abroad 13 січня було 57 тис. переглядів,
у dou.ua/forums/topic/14191 13 січня (дата популярності співпала з датою популярності статті /dont-move-abroad/) було 20 тис. переглядів. А всього 13 січня було 265 тис. переглядів, тобто інші сторінки теж дивились :)

У memcache 12 гігабайт зараз :)

Там насправді теж є певні покращення:
i.imgur.com/tupGeHE.png

Думаю, Front-End часть сайта ускорилась, а Back-End осталась по старому — когда больше пользователей может больше тормозить и т.п.

Некоторые рекламодатели ставят вместе с баннерами счетчики (однопиксельные картинки) adriver, думаю, у Вас как раз этот случай.

drive.google.com/...NlU/view?usp=docslist_api Вибачте, що так «швидко» відповідаю, універ разом із курсами займають увесь час. Пристрій: Note 2, браузер: Chrome

Дякую, буду розбиратись.

Я хотіла як краще :*(

О, це воно. В мене така ж трабла

Да, скорее всего довольно много месяцев до этого было без гзипа для CSS и JS.

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

Они не тормозят из-за того, что сделанны по другому. Обычные кнопки грузят сотни килобайт JS/CSS/HTML с Facebook/Twitter/Vkontakte, а эти занимают килобайт 20, которые грузятся из сервера сайта, а из Facebook/Twitter/Vkontakte грузится только циферка с количеством лайков или твитов.

Вроде помогло:
i.imgur.com/Pvc97VK.png

Поправил?

О, спасибо! Так намного удобнее.

спасибо, но это не совсем то. На вкладке "форум" тема всё равно же висит.

Она висит, но кружочек с комментариями уже не становится зелёным.

Внезапно.

В этом топике наверное:
dou.ua/...ums/topic/7891

Чтобы было эффективно надо завести холиварную тему про Одессу и тогда сразу набегут)

Достоверность информации не важна, ну или если очень хочется можно написать что-то нейтрально-вопросительное вроде «Перспективы айтишника в Одессе?».

Я сам хоть и не из Одессы, но пофлудить поддержать беседу всегда рад :)

Пока что считается, что для последних комментариев лучше подходит:
dou.ua/...orums/comments

Вот еще такое исследование:
timkadlec.com/...oading-results

canonical вроде больше для похожих страниц с разными урлами, а не для разных страниц в зависимости от устройства с одним урлом.

Добавил еще mediaquery теперь на Nexus 7 в вертикальном положении сайт выглядит не так отстойно (надеюсь).

Не хочу быть легковыгугливаемой. Я и на фейсбуке зарегилась только из-за требования доу.

Ну тогда наверное более лучшая стратегия — завести ящик типа [email protected] и регистрироваться на ДОУ через этот google-аккаунт.

У меня цель была больше не ускорить страницу, а упростить интерфейс,
было — 5 кнопок а под ней кнопка Откликнуться, стало — одна кнопка Откликнуться.

НеB7%D1%8B%D0%BC%8F

Дропбокс пишет 404 :( Может проще на [email protected] выслать.

www.dropbox.com/.../Безымянный.png

Посмотрите, пожалуйста какой в IE стоит режим браузера (кнопка F12). Скорее всего там IE 7 вместо IE 10:
i.imgur.com/bIfTxKZ.png

Да, ваша правда, так и было

ДОУ пока намного менее респонсив, чем, например, www.agromat.ua :)

docs.google.com/...it?usp=drivesdk

Пару дней назад еще работало хорошо :(

А какой там максимум RAM может использоваться MySQL-процессом? (Я находил, что пишут как 2 так и 3 ГБ)?

2 Гб.

Ясно, а у нас 32-битные, но www.mysqlcalculator.com показывает, что теоретически MySQL может потребовать до 3 Гб :(

Починил.

Да, будем еще разбираться, вообще на ДОУ очень много (возможно, слишком много) разных кешей, некоторые даже, например, индивидуальные для отдельных пользователей. Но сегодня внезапно оказалось, что непонятно как они все работают и работают ли вообще :)

Читал код,
также нажимал Ctrl+Shift+F в Sublime и искал по всему проекту, например, имена функций, если не встречается нигде, значит, похоже на неиспользуемый код.

Но если их 99+ и нет возможности их сбросить — ими невозможно пользоваться. Я их никогда не вычитаю. Если я бы мог их обнулить — то стал бы следить за новостями с завтра. А сейчас или все вычитывать или не пользоваться.

Появилась возможность:
dou.ua/...ic/6172/#368656

О! Теперь будем пользоваться :-)

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

Можно, но она на 1920 и на 1024 выглядит почти одинаково:
i.imgur.com/9f5ck1t.png

Посетителей с 1280 и меньше около 20% всего:
i.imgur.com/5FRGoam.png

Потом мы еще включили trim_blocks and lstrip_blocks:
jinja.pocoo.org/...tespace-control

так где 11 год а где текущий? Сейчас там преобладают копипастеры-переводчики, которым если сказать что забыли дать линк на исходники, заминусуют до неприличия. Оригинального контента очень мало, если только от русских компаний

Не очень, когда был тип топика «пост-ссылка», было в несколько раз больше.

Три месяца, уже закончился пакет:
maxua.com/...ost/54984359864

А вы хотите реализовать «естественный» декремент счетчика прочитанных комментариев?

А как это?

Я, наверное, опозорился=) Я имел ввиду реализовать логику, которая однозначно говорит, что пользователь прочитал конкретный новый комментарий или нет.

Проверку на то, попал ли комментарий в видимую область экрана,
на то, кликнул ли для каждого из комментариев зеленый кружок,
контрольные вопросы:
— кто написал комментарий?
— когда?
— о чем комментарий?

в Sphinx тоже есть синонимы, AFAIK

дерево сделано на github.com/...jango-treebeard

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

> Ну этот баг уже настолько давно,
Та вроде неделю назад все было ок.
Баг № 2:
Если коммент приезжает после отправки коммента, то из него нельзя вставить цитату.
Воспроизведение:
— оставить коммент пользователем1, не уходить со страницы
— ответить на этот коммент пользователем2
— ответить на еще 1 коммент пользователем1. Приехал коммент от пользователя 2, цитирование из него не работает.

Мне БЭМ и Яндекс немного напоминают:
enterprise-html.com
enterprise-css.com

SASS?

Пока были проблемы больше не в возможностях пропроцессоров, а в том, как это все было организовано и написано, например использовать любой один проепроцессор лучше чем 2 разных одновременно. Еще осталось довольно много лишнего кода, дублирования и т. п. Сейчас осталось порядка 18 тыс. строк less/css кода, что все еще многовато и например переход на SASS был бы из-за этого сложен и не настолько эффективен как просто улучшение того что есть.

В январе в репозитории было 27 тыс. строк LESS и 14 тыс. строк Styl, также в репозитории вперемешку хранились CSS файлы, которые генерились из пропроцессоров и просто CSS файлы, из-за этого всех стилей было 79 тыс. строк :)

А как это?

А как смотреть и хранить историю изменений продайшн-конфига?

Я посмотрел my.cnf, там 134 строки, в основном настройки, много комментариев, а пароля нет.

Вот такую начали делать страницу со списками непрочитанных комментариев:
dou.ua/unread

Поломали счётчик сообщений, он не декрементируется.

Да, но у постоянных читателей тоже прогретый скорее всего.

Главная — довольно популярный раздел сайта, у нее просмотров всего в 2 раза меньше, чем у всего форума.

Форум тоже стал работать немного быстрее чем год назад:
i.imgur.com/E2H9bFr.png

Насколько я знаю, если из кеша то все быстро и даже никакого запроса на сервер не происходит. ДОУ больше нацелен на тех, кто не просто раз в полгода заходит, а читает сайт регулярно — раз в пару дней или пару раз в месяц хотя бы, пока он заходит, нужные картинки (аватары (разных и тех что попадают на главную на самом деле не супер много, в комментариях больше, правда чем на главной), логотипы) попадают в кеш и потом уже всегда оттуда достаются.

Спасибо за предложение :) Хотелось что-то свое написать и посмотреть реакцию участников.

Спасибо за ответ. А можно и там и там?) Я здесь совсем недавно и мне очень нравиться сайт и очень интересны мнения ребят!

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

Большое спасибо за ответ — пошла на форум) В дальнейшем, когда возникнут интересные темы лучше тоже писать на форуме?

У вас теперь будет своя тема, для начала нужно использовать ее по максимуму, лучше одна хорошая большая полезная тема (с полезным текстом, вопросами и ответами на них) чем много маленьких.