Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

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

Особенно сильно ускорили главную страницу. И особенно сильно ускорили сайт для залогиненных пользователей.

Ощущается?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Updated Linode Plan

RAM 48 GB → 64 GB
Storage 768 GB → 1280 GB
vCPUs 12 → 16

А что именно на скриншоте не так?

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

@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/forums
грузились аяксом, теперь страница открывается в среднем в несколько раз быстрее, чем раньше, правда зеленые кружочки мигают при загрузке.

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

Спробував запустити профайлер, видало
311 059 076 function calls (310 849 027 primitive calls) in 760.858 seconds
o_O

Після sudo reboot сервер чомусь почав тормозити в кілька разів менше:
s.dou.ua/storage-files/cpu_.png

Ускорил запрос для списка комментариев на главной:
s.dou.ua/...​-files/index_comments.png

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

Так і є.
Я про тещо сторінка вантажиться 20 секунд.

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

Я хочу допомогти. Покажіть інформацію що показує debug-toolbar.

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

1. ось це

AND content_comment.created >= '2017-10-06 00:00:00'

краще замінити на

AND content_comment.content_id > [тут конкретна id-шка]

2. ось це

AND NOT (events_event.id IS NOT NULL)

краще замінити на

AND events_event.id IS NULL

3. ось це

ORDER BY content_comment.created DESC LIMIT 10

краще замінити на

ORDER BY content_comment.content_id DESC LIMIT 10

4. із цим

AND NOT (forum_topic.ignored = 1 AND forum_topic.ignored IS NOT NULL)

щось треба зробити... невже у вас щось там може бути окрім одиниці?

Тут 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-шаблон, тому він повільний, але я уже почав розбиратись з ним.

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

То без врахування TTFB, на повний рендерінг, коли 3341 коментарів вже готові до роботи, витрачається біля 4 секунд. Щоправда, у мене досить потужна машинка...

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

Але я ж про ідею «перенести рендерінг на клієнт».

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

Кхм, ну я ж приміряю ваші об’єми до своїх сайтів, так би мовити =).

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

Оу, заліковно! Але до 4 секунд, як би було при рендерінгі на клієнті — ще далеко. А коли ще врахувати можливості таких допоміжних інструментів як Service Workers, то ви точно до такої зв’язки не дотягнетесь своїм бекендом.

А оскільки ви й не думаєте переходити на рендерінг на клієнті, то що ж... бажаю дотягнутись до 5 секунд по TTFB. І хоча усі розуміють, що це недосяжний космос для бекенду в даному випадку, але що поробиш, ліміт у 5 секунд, замість 11 — непогано. =)

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

Важко так сходу уявити на що йде стільки часу враховуючи логіку «залогінений чи — ні». На вирахування непрочитаних коментарів + на додавання кнопок керування (додати коментар, проголосувати)?... Сподіваюсь у вас хоч голосування за коментарі не рознесені в окрему таблицю.

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

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

Я спочатку не роздивився, що то 274.9 мс, думав то 2.7 скунди і використовується кеш бекенду.

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

І все ж, повністю готові коментарі стають через 2.6 секунди (це якщо порівнювати з тими 4 секундами рендерінга на клієнті, без кешу, про які я вище писав).

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

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

А, точно. Що ж тоді та тема видалась мені спочатку за 6 сек., а потім швидше? Кількість коментарів не змінилась, начебто...

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

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

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

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

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

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

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

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

Може вам потрібно сортувати коментарі в вьюсі записуючи в тимчасовий атрибут рівень складності, щоб потім генерувати тупим

{% for in %}

?

Чи може проблема в лайках під постами? Можна спробувати їх денормалізувати записуючи не тільки в рядок, а і в array до поста. Тоді ви будете мати можливість за один запит діставати всіх користувачів, за інший всі пости з денормалізованими лайками і потім генерувати html без зайвих запитів.

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

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

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

уже трохи процентів на 40 генерується швидше ніж раніше.

Це чудово

Доречі помітив, що сама текстова сторінка dou.ua/forums/topic/10445 важить 4.5 мегабайт. Це нормально?

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

Коли написав новий коментар, то для автора цього коментаря показується іконка «поскаржитись» (із знаком оклику). Це не логічно, здається раніше такого не було.

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

ORM considered harmful

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

Просто цікаво чи ви розглядали можливість використовувати MongoDB чи якусь подібну БД?

Теоретично, можна обійтись без реляційних БД для коментарів, і мати по одному Mongo-документу для кожної теми на форумі. Для вашого бекенда це означало б, що прийдеться робити вибірку із 22 тисяч записів, а не із 1 млн. 200 тис., причому з мульти-join’ами , як це зараз відбувається.

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

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

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

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

Ви краще поставте перед запитом слово explain, запустіть і покажіть результат, бо оті 30 мс. може бути результатом вибірки з кешу, а не вибірки із реальних таблиць з джоїнами.

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)

Ви такий екплейн Максу показуйте

WHERE `content_comment`.`deleted` IS NULL
  AND `content_comment`.`content_id` = 51064

мені бажано реальний експлейн із запитом для форума з джоїнами =).

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

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

Кхм, ну і в якому разі ви вибираєте по одному коментарю? (Ви показали експлейн саме для такої вибірки).

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

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

`content_comment`.`id`

з

`content_comment`.`content_id`

:)

На скільки я розумію, цей запит використовується у циклі для формування дерева коментарів. Тут використовується одна єдина таблиця і йде зв’язка id = parent_id. Можливо я помиляюсь.

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

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

Ок, просто дивно, що ID теми, вибірку для якої ви показуєте, начебто має бути 22039, але ви кажете що він насправді 51064. Можливо, що я щось не враховую =).

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

Отже, ми приходимо до потреби зв’язуватись з якоюсь іншою таблицею, що тут ще не показана. Тобто, насправді запит буде точно складнішим... Ну добре, це ми сильно вже захопились =)

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

Тестую типографіку — цікаво як воно буде.
-

Можна видаляти. PT Sans sucks.

Как быть с темами с большим количеством сообщений? Свыше 1к? Они долго грузятся. Как варианты:

1. Уменьшить количество div-ов.

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

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

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

5. Увеличить использование оперативной памяти, снизить нагрузку на цп.

6. Сделать возможность пользователям в настройках переключать вид форума отображать тему целиком или постранично и т.д. Отображать в зависимости от выбранного пользователем вида отображения свой список настроек к виду.

Ночью переехали на другой сервер (host) Linode с такими же характеристиками, у предыдущего были какие-то проблемы в производительностью и KVM:
s.dou.ua/storage-files/load.png

А Ви можете зробити щоб браузер не робив запит до кожної аватарки з s.dou.ua ? pix.toile-libre.org/...d/original/1466338562.png

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

The redirect URI in the request, dou.ua/complete/google-oauth2, does not match the ones authorized for the OAuth client.

А письма на cb и support игнорируются?

круто, а что для этого поменять пришлось ?

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

Покращення на DOU в действии

2 недели не работали оповещения по E-mail о новых комментариях
Оповещения заработали, но в оповещениях битые нерабочие ссылки

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

Переехали на новый хостинговый тариф:
i.imgur.com/A2hD0dG.png
(было Linode 16, стало Linode 32).

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

за сутки в будні дні, у вас трафік мабуть десь йде 3-5 тис. хостів, так же ж?

У будні дні у сайту в середньому десь 25-40 тис. унікальних користувачів, 130-200 тис. переглядів сторінок.

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

посмотри статью где Польшу обсирают, там за день тысяч 40 было просмотров

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

Пост про КПІ, наприклад теж був досить популярним, хоча там теж певною мірою про «свалить»
dou.ua/...enta/columns/kpi-no-more

Маски-шоу популярні ще як правило:
dou.ua/lenta/tags/маски-шоу

Трактор нынче самый топовый

Основні користувачі оперативки сьогодні ввечері
memcache
uwsgi
mysql
redis
elasticsearch

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

Думаю через це, основний споживач оперативки — БД.

У БД зараз стоїть налаштування споживання оперативки 6 гігабайт — трохи більше за розмір БД.

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

Как менялась скорость генерации главной страницы за последние 3 года:
s.dou.ua/...es/fp-server-resptime.png

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

А также отключили баннер 240×350 (который был в правой колонке) и систему Google DoubleClick, которая его откручивала.

Было:
www.webpagetest.org/result/151130_ZF_VM7

Стало:
www.webpagetest.org/result/151130_4S_12J9

как-то вроде сейчас хуже стало: www.webpagetest.org/result/151201_SC_ENN
я перезапустил ваш первый тест First Byte Time стал F :(

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

Сделали, чтобы баннеры (такого типа) не прыгали при загрузке.

Для этого пригодился этот прием для создания блока с сохранением пропорций:
alistapart.com/...s-for-video/example2.html
и такой код для определения среднего цвета картинки:
gist.github.com/olooney/1246268

У вас, кстати, баннеры как-то странно работать начали imgur.com/2bhgDqs

Раньше такого не замечал.

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

Кстати да, заметил что с телефона быстрее открывается. С настолки не заметил разницы.

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

Спасибо, а можно на всякий случай скриншот и устройство/браузер?

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

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

Пристрій: Note 2, браузер: Chrome
Зря. Сейчас Серёжа пропишет их у себя и будет отдавать по дефолту кастрированную версию сайта без всех плюшек. Он уже так с BB10 сделал, пришлось менять user agent’а :)

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

когда заходишь за эту линию(скролингом)
s017.radikal.ru/.../1510/81/647a12840868.png
происходит так
s57.radikal.ru/.../1510/88/c69fe9d65944.png

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

С помощью сервиса fontello.com удалось уменьшить размер шрифта WebSymbolsRegular (который в виде base64 засунут в основной CSS-файл) с 10.4КБ до 4.7КБ.

Предлагаю способ уменьшить количество обращений к БД и увеличить скорость рендеринга страниц:

тыц

Если, конечно, это уже не сделали :)

Что-то я не догоняю...

А картинки когда можно будет в сообщения вставлять?

Новые и быстрые соц. кнопки — sapegin.github.io/social-likes

Кнопку «Google +1» пока отключил, она сделана через share.yandex.net
github.com/...l-likes.js#L121
и у меня запрос к нему часто почему-то тормозит.

Включили gzip для CSS и JS.

o_0

а раньше у вас типа без гзипа было ?

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

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

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

Хотя вам по идее пофиг на скорость загрузки

Мне очень даже не пофиг, я постоянно пользуюсь сайтом, и если он тормозит мне не нравится :)

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

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

а чего они вдруг не тормозят ? у меня на сайте кнопки из какогото сервиса стоят типа шерЗис или как то так. Я думаю поменять их на индивидуальные — потому что когда сервис лежит или тормозит — то кнопки не появляются или тормозят. но руки не как не доходят. ну и кнопочка гогл плюса повышает поисковую выдачу сильно. да частенько линкед ин еще кликается

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

и как это сделанно ? заинтересовал

Вот так:
github.com/...social-likes.js

Например, чтобы узнать кол-во твитов страницы
dou.ua/...t-to-get-fired

Нужно открыть или сделать такой запрос:
cdn.api.twitter.com/...red/&callback=

В то время как стандартная кнопка tweet «весит» 146 килобайт.

сложный способ и линкедина нет.

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

Похоже unwrongest.com/...ojects/elastic тормозит при наборе текста в больших топиках:
i.imgur.com/g02AwKb.png

Очень оперативно, спасибо.
Сейчас попробуем.

Сегодня ускорил функцию, которая отвечала за развертывание комментариев и выполнялась более секунды на больших топиках ( i.imgur.com/eQJ1J23.png ), а также отключил (опять) виджеты Facebook и Twitter, теперь страницы топиков, статей и событий должны работать быстрее.

Последние пару дней комментарии по J/K начали пролистываться в порядке от самых свежих к самым старым. На самом деле получается не очень удобно для чтения дискуссий: сначала открывается последний «лист», а чтобы понять, с чего вообще все началось и о чем речь идет, приходится пролистывать все комментарии до самого корня. Нельзя ли это как-то исправить?

Варианты:
— вернуть «старый» алгоритм
— изменить текущий порядок на противоположный — пролистывать от самых старых к самым новым
— вынести варианты выше в настройки пользователя и разрешить пользователям самим решать, как им удобно
— ваш вариант :)

Работает не так со вчерашнего дня. Я немного изменил реализацию.
Сегодня поправлю.

А можно стрелочку «наверх» слева от количества комментариев внутри статьи побольше сделать? Так непросто в эти 5 пикселей попадать...

Увеличил, правда не стрелочку, а размер кликабельной области:
i.imgur.com/nP2iXAb.jpg

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

ДОУ не считает автоматически вот такое ссылкой: http://провэд.рф/analytics/research/5866-analiz-export-import.html

Я когда первый раз увидел «провэд.рф», подумал о каком-то падонкавском сленге :)

Было бы неплохо иметь возможность помечать темы как "не интересно", чтобы в списке тем у себя я их более не видел. Например "Зачем нужны дети в молодом возрасте?" уже достала висеть в топах и забирать моё внимание при просмотре всего списка, если чесн.

Такая возможность есть здесь:
dou.ua/unread
(слева от темы крестик), если его нажать, то тема перестанет отображаться в dou.ua/unread

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

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

На самом деле часто с заглавием темы всё происходит также как и с надписью на заборе. Там совсем не то, что написано :)

Внезапно оказалось, что при загрузке страницы с комментариями каждый из комментариев обрабатывается вот таким образом:
paste.in.ua/9039/raw
и это может работать медленно на 1000+ топиках. Попробую переделать.

После сокращения получилось
paste.in.ua/9046/raw
и 42 вместо 1300 мс.

Кстати...
Небольшой баг.
1. Открываем уже просмотренную тему.
2. Несколько раз нажимаем хоткей J или K (может, и не обязательно нажимать).
3. На любой из новых комментариев отвечаем либо что-то начинаем набирать, но комментарий не отправляем, главное зайти в поле редактирования. Можно потом нажать «не отвечать», без разницы.
4. Хоткеи не работают. Клик по зеленому квадратику J/K работает, а хоткеи нет.

Да :( для этого бага даже отдельный топик уже есть:
dou.ua/...ums/topic/8295

Всем привет!
Ищу программиста из Одессы. Есть кто?

Для поиска программистов воспользуйтесь jobs.dou.ua или djinni.co, искать с помощью таких комментариев как ваш не стоит.

А я не для работы ищу : ))
Я на пиво хочу позвать...
А где такой комментарий оставить можно, не подскажете?
Но чтоб эффективно было : ))

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

Типа, Одесса — это хорошо, или Одесса — это плохо? Чтоб заводить такую тему, надо знать, о чём говоришь. Я в Одессе всего-то несколько месяцев, толком не поняла, нравится мне тут или нет... Сложно будет спорить : ))

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

Хорошая идея! Я попробую. Поможете мне с наполнением темы?

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

Упростил layout трехколоночных страниц для планшетов.

главная было:
i.imgur.com/NTAShlD.png

главная стало:
i.imgur.com/WK4VvoM.png

форум было:
i.imgur.com/MwD24fR.png

форум стало:
i.imgur.com/nEOlYen.png

Я уже просил, а можно отключить поддержку мобильных версий, ибо у меня нет колонки последних комментариев?

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

Я так понял на серверсайде делается вставка стилей, чтобы сделать магию?
Чем медия квари не угодили?

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

Само изменение для приведенного было-стало довольно простое: i.imgur.com/pHpipzp.png
так что наверное не страшно, что используется такой подход.

Ээээ, ну да. Квари, стоит использовать только для того чтобы поменять лайоут и скрыть пару тройку элементов дизайна.
Если блок с линками просто опустить под комментарии, то проще использовать квари.
А если менять страницу, для разных устройств, кардинально, то еще надо прописать

<link rel="canonical" ...

googlewebmastercentral.blogspot.com/...-canonical.html

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

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

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

Интересно, а в чем причина вашего желания быть двухбуквенной?

(в чем баг точно не знаю пока).

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

Ну тогда наверное более лучшая стратегия — завести ящик типа aksjdh@gmail.com и регистрироваться на ДОУ через этот google-аккаунт.

Спасибо, бот на доу у меня уже есть. :-)

upd
кстати, сразу хотела быть анонимом, просто не ожидала, что в профиль на доу засосет все данные с фейсбука вместе с фоткой, и ссылка на сам профиль тоже будет доступна.

На страницах вакансий отключил кнопки социалок:
i.imgur.com/0FyGWB6.png

Как вариант, можно включать всю социальщину внизу страницы, через document.write xD

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

Сегодня, примерно после 20 часов по Киеву, попробовал зайти на доу в ie10, под виндой 7, 64. Все сломалось, и съехало, не смог отправить комментарий

Это случайно не тогда, когда вы незалогиненным начали добавлять комментарий и после нажатия кнопки «Добавить комментарий» появилось окно входа на сайт, а после него — такое окно: i.imgur.com/YErM5C1.jpg

Дропбокс пишет 404 :( Может проще на cb@dou.ua выслать.

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

Хммм, теперь есть кнопки J и K. Теперь у ДОУ два режима: в одном пищит, в другом — все портит )))

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

Архиплохо!
hl для движения по новым
jk для движения по всем
:qw!

Сегодня прочитал новый (для себя) термин RESS: REsponsive Web design + Server Side components,
тут: gorkamolero.com/...formance-2.html

оказалось, на ДОУ он уже частично используется. Еще сделал, чтобы для mobile на главной не грузилась правая колонка, которая раньше только пряталась.

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

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

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

баг в парсинге нелатинских урлов
например xn-----clcksaplxf6byd3cyb.xn—p1ai/
пиши-код-блять.рф

Это наверное нескоро, так как сейчас даже с парсингом нормальных урлов все плохо, например глючит конструкция урл + «)».

Это наверное нескоро, так как сейчас даже с парсингом нормальных урлов все плохо, например глючит конструкция урл + «)».
daringfireball.net/...jects/markdown
www.methods.co.nz/asciidoc
ИТшный сайт все-таки!

Я markdown в начале 2009-го как-то прикручивал к странице редактирования профиля :)

Сейчас распознаванием ссылок занимается кажется github.com/jsocol/bleach, но не всегда удачно. Еще везде есть типограф, который тоже добавляет запутанности и сложности процессу.

ИТшный сайт все-таки!

Пару недель назад кое-как удалось наладить вставку кода :)

Сейчас распознаванием ссылок занимается кажется github.com/jsocol/bleach, но не всегда удачно. Еще везде есть типограф, который тоже добавляет запутанности и сложности процессу.
Все нафик и оставить один макрдаун. Думаю ИТшнеги за пару месяцев привыкнут. Зато не будет проблем (даже со вставкой кода), а штука, которая пытается угадывать чего хочет пользователь, всегда будет глючить.

Нет. md склеивает строки в абзац, если между ними нет пустой — это делает из текста разряженную простыню.
rst — такой фигни не делает.

А кто-то еще использует 32 (а не 64) bit Linux/MySQL на продакшн?

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

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

Пытаюсь упростить шаблоны не изменяя внешний вид сайта:
i.imgur.com/ZWdcnaw.png

Увеличили memcached-у параметр maxbytes c 64М до 256M.

А какой кеш-хит был и стал?
И почему увеличили?

Пока что сильно глубоко не копали, увеличили на всякий случай.

Заметили, что некоторые большие объекты (например блок комментариев топика с 1000+ комментариями) не попадают в кеш даже после изменения default maximum object size, который по дефолту 1М. Осталось выяснить почему это так и что там неправильно реализованно.

А кеш-хит как лучше измерять? :)

Пока что сильно глубоко не копали, увеличили на всякий случай.
От это очень плохая практика. В лучше случае у вас будут лишние затраты ресурсов (про которые все забудут и они повиснут), в худшем может быть серьезное падение производительности.
А кеш-хит как лучше измерять? :)
Посчитать тех кто попал и тех кто нет, а потом разделить тех кто попал на сумму. Ваш К.О. :)
А если серьезно, то хорошо бы сбрасывать счетчики через некоторое время. И замерять другие параметры, например количество активных пользователей, время и тд. Но это уже такое что надо смотреть на месте.
Заметили, что некоторые большие объекты (например блок комментариев топика с 1000+ комментариями)
У мемкеша, вроде, есть сетка и больших ячеек очень мало. Но даже если и не так, лучше не класть в кеш большие объекты (если есть возможность этого избежать).
UPD.
От так говорит сам Атэц stackoverflow.com/a/9143912 (но это может быть загон ГАЕ)

У нас пока сегодня из «приборов» появился только code.google.com/...p/memcache-top
он показывает такое:
i.imgur.com/x2CwPPv.png
вот еще cumulative за пару минут:
i.imgur.com/y55dW8w.png

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

Другие «приборы» показывают, что Memcached жрет память, а процессор не жрет:
i.imgur.com/w6NgOcg.png

Пока что тикет не закрыт, так что забыть сложно.

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

Еще там вроде есть какая-то компрессия, ее пока не трогали

i.imgur.com/x2CwPPv.png
есть даже HIT — 86.6%
По картинке вроде неплохо.
Но я бы попытался посмотреть срезы по размерам объектов, пусть даже банальными счетчиками в приложении.

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

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

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

{% cache 3600*24 modelcache('comments:{0}'.format(topic.id), attrs=[request.user.id]) %}

Сократил размер основного JS-файла с 169 до 135 КБ (minified).

Применил 2 подхода:
— вместо того, чтобы делать один большой JS файл на всех страницах,
сделал один основной JS файл, общий для всех страниц, и опциональный второй, индивидуальный для некоторых страниц, например, страниц редактирования профиля или добавления топика.

— обнаружил несколько килобайт кода (как в виде отдельных файлов, так и в виде функций или блоков) который или совсем не использовался, или использовался частично (например, использовалось 4 из 198 строк самописной библиотеки).

обнаружил несколько килобайт кода

а как обнаружил не используемый код?

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

Ну я еще попутно форматировал некрасиво отформатировнный код и даже пытался что-то оптимизировать, например, заменил:

$('.parent-link').bind('click',function() {

на

$("#commentsList").on('click', '.parent-link', function() {

хотя не уверен, что это что-то существенно изменило.

Экономия на спичках, но для улучшения стиля — гуд.

Я «bind» еще не люблю из-за того, что есть такой кусок кода:

Function.prototype.bind = function() {
	if (arguments.length < 1 && typeof arguments[0] != "undefined") return this;
	var __method = this, args = [];
	for(var i=0;i<arguments.length;i++){ args.push(arguments[i]);}

	var object = args.shift();
	return function() {
		var args_to_apply = [];

		for(var i=0;i<args.length;i++){ args_to_apply.push(args[i]);}
		for(var i=0;i<arguments.length;i++){ args_to_apply.push(arguments[i]);}
		return __method.apply(object, args_to_apply);
	}
};

Теперь мне будут сниться кошмары xD

Переделал свертывание комментариев, теперь если в посте/топике меньше 100 комментариев, то они вообще не свертываются, а если больше, то свертываются, но лучше, чем было, без таких глюков, когда не в тему вываливался один комментарий из свертка:
trello-attachments.s3.amazonaws.com/...4d351b/bug2.png

В рамках покращення для планшетов случайно не была отнята возможность редактировать комментарии?

Сегодня получается исключительно так —
www.dropbox.com/...12 12.28.09.png
Или дублирование комментария при попытке редактировать.

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

Сегодня еще переделал страницы поста и топика для планшетов, стало так:
i.imgur.com/B4m55gX.png

А как отписаться от уведомлений? 99+ очень долго сбрасывать. И отметить как прочитанными все. А то тыцкать 30 раз кнопочку не весело...

Уведомления показывают что бы вам такого почитать, если вы отметите все прочитанными за 1 клик, то они не смогут вам ничего посоветовать и утратят смысл. Это же не email inbox где все должно быть сразу прочитанным.

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

Тут dou.ua/unread внизу появился чекбокс «все материалы», попробуйте его включить и затем нажать кнопку «Отметить прочитанными».

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

Ipad4, browser id Safari ipad.
Просмотр и особенно редактирование в темах с более чем 50-70 сообщениями,- слайдшоу а-ля ад и Израиль, как запуск кризиса на целероне.
Можно ли отпокращить взад?

отпокращить

Вроде ничего не ломали специально в последнее время. Также у меня нет iPad-а (в т.ч. 4-го) и Safari :(

Попробовал на Nexus 7 в Chrome топик на 900 постов — тормозит сильно, на 178 — тормозит несильно.

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

открыл форум на 1280×1024
это ужос.

Ужас там где большая вложенность комментариев?
Где небольшая вроде не ужас: i.imgur.com/bTxszjx.png

а вот эта область, справа, с ней ничего сделать нельзя ?

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

ну на 1920 ее «не заметно» а на 1280 — чуть меньше трети экрана
ну вообще ладно. реклама все дела. донастрою новый комп и подключу второй монитор

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

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

Мне вот такое пришло:

лександр Труш ответил на комментарий к " Ускорили сайт ДОУ"

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

dou.ua/...ef=email#344224

т.е. твой комент был вырезан

Заменил в одном из джанго-шаблонов пробелы на табы, размер HTML топика Невесты из Филиппин уменьшился на 500 КБ :)

Заменил в одном из джанго-шаблонов пробелы на табы, размер HTML топика Невесты из Филиппин уменьшился на 500 КБ :)
Размер gzip-воного или чистого (286 KB/2.3 MB). Есть подозрение что таки чистого. Если да, то как изменился размер пожатого?
Момент № 2. Вы тайминги смотрели? Ожидание 4.09 секунды, передача 0.499. Может что-то не то оптимизировали?

GZip, к сожалению не тестил, сохранил 2 HTML, и попробовал сжать 7-Zip-ом (zip/fast). Было 296, стало 277 КБ.

Оптимизировал в основном читабельность шаблонов, плюс немножечко мобильную версию, 500КБ несжатого хтмл стали побочным эффектом.

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

Оу, вы на jinja2? Хотя тут наверно мне это уже говорили...

И на этой странице сжатие не работает.

//придирки
Присмотритесь к meta тегам — там повылазили переносы строк, так быть не должно.
Кроме того это html тег, так что >, а не /> - это относится ко всем непарным блокам input, link, img ...;)

:g/\/>/>

Есть еще лишние \r в темплейтах около js кода

Ну и инпуты расколбасило на три строки

Инлайн стили по-убирать бы

Есть пустые атрибуты for=""

Вырезать html коменты

Для картинок стоит width="40″ height="40″

pycharm почти сдох на оптимизации страницы xD

-Ссылки для углубленного чтения-
Няшные графики
analytics.blogspot.com/...site-speed.html
support.google.com/...r/1205784?hl=en
support.google.com/...f_topic=1282106

Няшные графики

Графиками пользуемся :)
dou.ua/...ic/6172/#301367

Сейчас наверное основная проблема в том, что на сайт целых 220 html файлов шаблонов и в них творится бардак, нужно как-то получше все переделать (есть сложные шаблоны которые никто не понимает как работают).

Нууу, если бы их покрыть тестами, то можно и нырнуть вглубь ;D

pycharm почти сдох на оптимизации страницы xD

Меня еще бесит, что хром (и другие браузеры) почти сдыхают когде делать view source страниц типа dou.ua/...ums/topic/6591 :(

Хехе и у вас там бага в парсере коментов завелась. Отредактируй мой комент выше

docs.djangoproject.com/...tins/#spaceless
может пригодиться и можно не думать про пробелы в html, поставив в базовый темплэйт данный тег.

Обнаружил в Хроме интересное поведение, простите если это повтор(боян). Захоим в любую тему с непрочитанным комментариями, нажимаем на любую ссылку в теме, ждем перехода, нажимаем к хроме «назад» — вуаля, теперь все комменты помечены как прочитанные, не смотря на то что я ничего не читал :(

Да, сейчас нет проверки на то, действительно ли вы прочитали все комменты, поведение с непрочитанными приблизительно такое же как на Хабре, например.

У меня претензий нет, я использую этот багофич что бы не клацать на «99» и помечать темы как прочитанные

такое же как на Хабре
у меня к этому ресурсу патологическое отвращение, не уверен что стоит на него равнятся

Зря. Там до 11 года вполне себе спецы тусовались

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

Оригинального контента очень мало, если только от русских компаний

Или украинских, например:
habrahabr.ru/...ou/blog/184648

^^
Achievement unlocked: SEO-masta

Много оттуда приходит народу?

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

ОМГ, вы там так давно, как компания?
Топик ссылка была же очень давно упразднена.

Хорошо, если боятся. Значит все прекрасно у проекта.

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

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

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

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

@фичреквест: в многоярусных комментария сложно понять, что вообще творится.
Я видел два варианта для решения такой проблемы:
— возможность прочесть выделенную ветку — так на хабре
— сброс левого отступа с графическим указанием — пикабу pikabu.ru/...rgeroya_1329759 искать по тексту Раскрыть эту ветвь

То что сейчас все комменты третьего уровня _каким-то фигом_ группируются не юзабельно.

В ведроидном браузере не выделяется для клика блок с раскрытием комментариев, тот который «Еще Х комментариев». Я так понял, для этого надо его сделать якорем-ссылкой.

Как-то так

В ведроидном браузере не выделяется для клика блок с раскрытием комментариев, тот который «Еще Х комментариев». Я так понял, для этого надо его сделать якорем-ссылкой.

Сделал тегом a вместо span (правда поленился запускать ведроид).

Хехе, теперь жмакается, но не раскрывается.
:/
Но это такое, минорное, коменты в плоском виде — это то еще развлечение

@фичреквест: под строкой поиска есть «Быстрый переход», было бы логичнее если бы клик по нему переносил в раздел вместе с поисковым запросом
И вообще, сделать возможность поиска по быстрому переходу.
Или объяснить юзкейс такого поиска.

Переехали из Sphinx на Elasticsearch (используется для поиска в разделе Работа).

django-sphinx не поддерживается уже 2 года, плюс мы постоянно в день получали около 50 ошибок от него, надеюсь с django-haystack такого не будет.

«что дало» будет известно как минимум через неделю. из плюсов, в отличии от сфинкса можно разделять поиск по синонимам так, что если вы ищете пхп, то вам выдаст вакансии по друпалу, а наоборот не выдаст (в сфинксе, если вы ищете друпал, то вам выдаст и php вакансии).

:/ с толстостями поиска не знаком

Жду репорта :)
issue бы на гитхаб джанго-сфинкса

В первый же день столкнулись с проблемой экранирования спец. символов pastebin.com/eCFPZFzb

может это python feature? pastebin.com/j8j3vhWQ

Скорее даже это особенность консоли питона

In [3]: re.escape(’/’)
Out[3]: ’\\/’
In [4]: print re.escape(’/’)
\/
In [6]: ’/’.replace(’/’, ’\/’)
Out[6]: ’\\/’
In [7]: print ’/’.replace(’/’, ’\/’)
\/
то что принтом возвращается, это то что реально есть внутри строки, а оутпут все экранирует
stackoverflow.com/...2179518/1346222

<eof> мне тут не нравится и судя по xenforo.com/...xception.45214 дело может быть не в запросе, а дело в индексе ну или таки вы правы и надо проэкранировать слеши в запросе согласно «багу» github.com/...rch/issues/2980

Думал простую инъекцию можно сделать :/

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

У нас был Sphinx с синонимами, но хотелось «древовидных» (или каскадных) синонимов, например, раньше были синонимы:
«PHP, Drupal, Wordpress, Magento»
и получалось, что поиск по Magento выдавал все PHP вакансии,
а хотелось, чтобы поиск по PHP выдавал Magento-вакансии, а поиск по Magento выдавал только Magento вакансии.

Может, конечно, так и в Sphinx можно сделать.

Натравили PngOut на аватарчики:
i.imgur.com/Lv60bFj.png

К ссылкам надо добавить target="_blank" rel="nofollow", а по феншую, вообще делать редирект на свою страницу, с уже которой пользователь будет уходить на сторонний ресурс (тут есть тонкости, правда, чтобы дырку не сделать у себя).

Это для SEO или для юзабилити?)

Заметил из-за того, что по линку не открылась новая страница, хотя я привык, что открывается = юзабилити.
Потом уже seo.

Хотя можете оставить, я pr-tic своим подниму xD

За последнюю неделю удалось сократить время генерации топика Невесты из Филиппин с 11.4 до 6.5 с.

Если не секрет — как удалось добиться?

Сначала подумали, что тормозит вычисление онлайн-индикаторов (такие зеленые кружочки возле аватаров):
i.imgur.com/FHfYYHC.png
и начали их вычислять не при запросе, было так

`auth_user`.`last_login` > (NOW() - INTERVAL 15 MINUTE) as `is_online`

стали отмечать online-юзеров по крону, стало:

`user_profile`.`user_online` as `is_online`

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

i.imgur.com/FHfYYHC.png
и начали их вычислять не при запросе, было так
`auth_user`.`last_login` > (NOW() - INTERVAL 15 MINUTE) as `is_online`
стали отмечать online-юзеров по крону, стало:
`user_profile`.`user_online` as `is_online`
А почему нельзя использовать просто мапу в памяти (которую очищать раз в какое-то время)? Мапа лонг-булеан не должна жрать много памяти, та и я как не гляну, а на сайте одновременно в пределах 2 «страниц» пользователей ( dou.ua/users/online ).
К слову:
добавили индексы по нескольким полям, какое-то кеширование
с 11.4 до 6.5 с.
Такие странные числа наводят на мысль, шо проблема больше в архитектуре, и можно задуматься не являются ли индексы и кеши просто затычкой.
Такие странные числа наводят на мысль, шо проблема больше в архитектуре, и можно задуматься не являются ли индексы и кеши просто затычкой.

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

Дараги таварищи!
За эти заслуги, награждаем команду, Орденом Ленина.

А дерево, через mptt сделано?

А дерево, через mptt сделано?

Вроде нет:
Searching 717 files for “mptt”
0 matches across 0 files

pypi.python.org/...ypi/django-mptt

дисклеймер: сам с этим работал только на маленькой выборке — быстродействие на больших выборках мне не известно. Хотя по этому поводу уже есть мысли

удалось сократить время генерации
От только кнопку раскрыть комменты забыли перенести i.imgur.com/m3zLsLD.jpg
Если прокрутить еще немного вниз, то совсем непонятно на что был ответ.

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

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

И совсем уже идиотская просьба — сделай под окошком коментов список «допустимые теги» — кнопками. То есть чтобы при нажатии на strong — выделенный фрагмент обрамлялся стронгом, на создание ссылки — диалог... Обычный джентельменский набор.

И по дизайну дерева коментов в свой черед есть чего подумать:
Выравнивание пустотой — некрасиво для большой вложенности. Я бы начная от тертьего уровня отрисовывал дерево — это бы повысило количество прочтённых коментов на одного читателя.

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

Я бы предложил делать коменты и темы — двумя разными блоками. Независимыми. Ещё лучше — оптимизацию исключительно тех тем которые содержат тысячи коментов. Явно ренедерить их скриптом: сначала выдать общим массивом (дабы их хорошо поисковик кушал), а уже потом дерево отрисовывать.

Не знаю, баг это или фича, но если после ссылки поставить знак вопроса, он теряется.
Например: dou.ua? (здесь я хотел поставить знак вопроса, а не добавить его в URL).

Скорее всего баг, часто если скобку — «)» поставить после ссылки будет такой же эффект

Переделал jobs.dou.ua из Stylus на LESS.

Раньше DOU был на LESS а JOBS.DOU — на Stylus (в LESS-стиле), теперь будет один движок стилей и будет проще обновлять и сопровождать сайт.

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

Переубеждать не буду, тем более что вы используете нотацию в именовании классов из БЭМ :3

Для фронтендера, неплохо иметь под рукой подобный инструмент, для прототипирования, а с учетом, того что функционал написан на node.js, и для продакшена. (Лихо завернул)

Переубеждать не буду, тем более что вы используете нотацию в именовании классов из БЭМ :3

Она используется очень частично и не всегда правильно.

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

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

Угу и перепишете все на стильный и молодежный рор xD

Подскажите, насколько правильно/распространено хранить MySQL-конфиг в системе контроля версий?

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

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

А зачем? Там же только хост, логин и пароль, которые наоборот нужно исключать из VCS.
А уже скрипты для деплоя должны копировать конфиг-образец и заменять в нем %плейсхолдеры% на реальные логины/пароли.

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

Блин, я почему-то подумал, что речь шла о питоновском конфиге, в котором хранятся параметры доступа к БД.
А насчет my.cnf, то его спокойно можно добавлять.

я храню все что менял (обычно ж не более 5 конфигов выходит)

Перешли на jQuery 2.0 (пока без jobs.dou.ua), для IE8 осталась 1.9.1.

Уважаемая администрация, два вопроса:
1. В какой теме задавать вам вопросы :) ? что бы удобно и без спама(может запретить комменты от не админов..)
2. Будет ли кнопка «пометить все как прочитанное» ?

Спасибо

1. В какой теме задавать вам вопросы :) ? что бы удобно и без спама(может запретить комменты от не админов..)

Самый надежны вариант (в смысле отсутствия комментов не от админов — написать на cb@dou.ua), можно также добавлять топики в dou.ua/...forums/support (там все могут комментировать но не факт, что будут) или комментарии в похожие топики там же.

2. Будет ли кнопка «пометить все как прочитанное» ?

Скорее всего, когда-то будет. Как бы вы хотели чтобы она работала?

Как бы вы хотели чтобы она работала?
Предпологаю, что все зеленые счетчики сбрасываются в черные во всех топиках для пользователя
Примерно так работает ’mark all as read’ в идущем ко дну google reader, если это нормальный пример

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

Вот тут есть интересные мысли на эту тему:
artgorbunov.ru/...oviet/20130115

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

Да, похоже в процессе внедрения нового кода для горячих клавиш (J/K), они, кстати, работают и уменьшают цифру.

UPD 21:09
Уже исправлено.

Кстати. В мобильной верстке лента комментов plain, без отступов. Читается на ура.

userscripts или вы не программист? xD

Прикольно, сразу заметил что интернет стал быстрее))))

График скорости загрузки главной ДОУ:
i.imgur.com/EmX9e5M.png

Что 7 что 4 секунды на загрузку страницы, это помоему какой то ...ный стыд. На что уходит время?

Думаю в основном на веб-шрифты и баннеры, вот тут еще можно картинкой глянуть:
www.webpagetest.org/...130321_8B_144H

Если смотреть загрузку в Хроме, получается быстрее:
i.imgur.com/2eeSA9h.png
— пишет 720 ms, у меня правда шрифты установлены в системе и не грузятся с google fonts.

i.imgur.com/2eeSA9h.png
— пишет 720 ms, у меня правда шрифты установлены в системе и не грузятся с google fonts.
И кеш прогретый :) Там все «from cache».

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

Да, но у постоянных читателей тоже прогретый скорее всего.
А они часто на главную заходят? У меня просто ссылка на форум в закладках.

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

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

Думаю в основном на веб-шрифты и баннеры, вот тут еще можно картинкой глянуть
Все по типу этого s.dou.ua/...nnounces/420×230_42_6.jpg можно грузить после загрузки страницы, каким-то аджаксом (может получится) (Надо А/Б тестирование, скорее будет хуже по кликам)
Можете попробовать убрать аватары ( s.dou.ua/...g/avatars/25×25_54753.jpg ), так как они часто меняются. Но тут надо уже какое-то А/Б-тестировани, бо можете ударить по посещаемости, но мне думаетсо что нет :)
Логотипы компаний. Тут самое время вспомнить про карты изображений :)
--------------------
Ну и «dou.ua Does Not Support SPDY» spdycheck.org/#dou.ua
Ну и «dou.ua Does Not Support SPDY» spdycheck.org/#dou.ua

Несколько раз встречались посты типа
www.guypo.com/...t-as-spdy-as-you-thought
которые пишут, что не так уж это и хорошо.

Можете попробовать убрать аватары, так как они часто меняются. Но тут надо уже какое-то А/Б-тестировани, бо можете ударить по посещаемости, но мне думаетсо что нет :)

Там проблема в основном в том, что они немного по дибильному сжаты, аватарка 25×25 может получиться как 1Кб так и 42 (!!!111) КБ, пруф.:
s.dou.ua/...g/avatars/25×25_13482.png

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

Логотипы компаний. Тут самое время вспомнить про карты изображений :)

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

Все по типу этого можно грузить после загрузки страницы, каким-то аджаксом (может получится) (Надо А/Б тестирование, скорее будет хуже по кликам)

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

Аватары я тут i.imgur.com/tmglzjb.png недавно убрал, там все равно половина было анонимных :)

аватарка 25×25 может получиться как 1Кб так и 42 (!!!111) КБ
1Кб — это так же не очень хорошо, по факту это пустые затраты на соединение. По идее SPDY должен решать данную проблему, но тут я больше теоретик, поэтому убеждать не буду.
о сам блок периодически меняется...может быть неудобна более оптимальная реализация.
Я не вижу большой проблемы. Скрипт который генерит спрайт и карту. Как бы время потратить прийдется, но если блок меняется редко (реже чем раз в неделю например), то плюсы очевидны (можно еще и декларативно его задавать, а не менять разметку), та и задача в общем интересная.
там все равно половина было анонимных :)
Так фишка в том что они часто меняются. Там список может меняться несколько раз в день. Если страницей таки часто пользуются, то может дать прирост (любой УРЛ, даже если из кеша, это оверхед)

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

Насколько я знаю, если из кеша то все быстро и даже никакого запроса на сервер не происходит.
Если агрессивно кешировать (так как ДОУ), то да.
Но есть такие моменты i.imgur.com/BqGEXTn.jpg связанны как с самим кешом, так и с тем что хоть и нет запроса по сети, но процедура запроса внешнего ресурса запущена.
ДОУ больше нацелен на тех, кто не просто раз в полгода заходит, а читает сайт регулярно
Я не знаю вашей бизнес-цели, посему буду основываться на своем удобстве.
Если читать тему с большим количеством комментов, например dou.ua/...ums/topic/7130 , то там основное время как раз на сервере и тратится на формирование всего ХТМЛ (даже тех комментов которые скрыты). Поэтому дешево может помочь подгрузка всех комментов после загрузки темы (тут должно быть совсем мало делать, но результат может не обрадовать). Или подгрузка темы и первого уровня, а остальное аджаксом.

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

Сами комментарии на ДОУ пока что большая проблема — там очень большие и запутанные шаблоны, скрипты (недавно удалось сократить JS комментов с 40 Кб (о_О) до 28 Кб) и стили. Для мобильных недавно сделали немного альтернативную версию, она без аватаров и с более удобными кнопками. Просто добавить более сложную логику и код к тому что есть не хочется, потому что может получиться как обычно.

Мммм, вообще жирно, молодцы.

Теперь только очередь уменьшить на входе. Добавьте кеширование страницы (HTTP ETag например)- не думаю, что она у вас уж так часто обновляется.

:/ ну и гугл шрифты я бы убрал — так нервирует, когда текст появляется не мгновенно на странице

Скоро должен выйти nginx.org/...pdy_module.html

:/ ну и гугл шрифты я бы убрал — так нервирует, когда текст появляется не мгновенно на странице

Установите PT Sans себе на компьютер:
www.paratype.ru/public
(мне помогло)

Теперь только очередь уменьшить на входе. Добавьте кеширование страницы (HTTP ETag например)- не думаю, что она у вас уж так часто обновляется.

Почти все популярные страницы обновляются часто, в основном за счет комментариев.

xD если доконает, то лучше пользовательские стили сделаю. Мне этот шрифт ни к чему.

Почти все популярные страницы обновляются часто, в основном за счет комментариев.

А вот их лучше ajax’ом подбирать, можно даже риалтайм попытаться сделать ( на erlang (на правах шутки )) .

xD если доконает, то лучше пользовательские стили сделаю. Мне этот шрифт ни к чему.

Тоже вариант.

А вот их лучше ajax’ом подбирать, можно даже риалтайм попытаться сделать ( на erlang (на правах шутки )) .

Мне не нравится, как грузится, например главная страница Facebook, на ДОУ нет такого хайлоада и наверное проще сделать, чтобы оно так как есть быстро работало, чем добавлять обходные пути, которые только усложнят сам проект.

Я просто оставлю это здесь:
Faster Websites: Crash Course on Web Performance — igvita.com bit.ly/15mFhGm

Недавно еще такое появилось:
browserdiet.com
(я правда пока не читал делатьно, похоже на очередной сборник советов).

Недавно еще такое появилось:
browserdiet.com
Бегло просмотрел. Там в основном старые трюки, которые известны уже лет 5, наверное.

Добрый вечер. Подскажите, пожалуйста, как долго модерируют статьи? Я свою ещё вчера отправила( Спасибо

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

А тот другой интернет по чуть-чуть загибается уже некоторое время.

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

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

Возможно вам действительно стоит опубликовать ее в разделе
dou.ua/...orums/startups
на форуме, там вы можете не только самостоятельно опубликовать статью, но и потом в процессе вносить правки, а еще на форуме могут комментировать анонимные пользователи.

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

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

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

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

сделайте же наконец то target="_blank" на ссылках
От че на 1+ год низя привыкнуть нажимать контрол/комманд или колесико???

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

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

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

Если имеются пропавшие ввиду блоки на странице jobs.dou.ua над списком вакансий, то скоро вернем, там что-то со сфинксом случилось.

Вернули, помогло обновление Сфинкса.

В воскресенье утром (27.01.2012) — плановый upgrade Ubuntu.

27.01.2012
А машина времени у вас — на каком фреймворке? :)

Последние несколько недель плотно занимаюсь оптимизацией клиентской части ДОУ, также в планах переход с MySQL 5.1 на MySQL 5.5, этим уже занимается наша киевская команда.

я не настаиваю, но посмотрите на percona, там есть много плюшек

Смотреть будем (особенно если апгрейд мускула не будеть чувствоваться), сейчас хочется для начала перейти с Ubuntu 10.10 на 12.04.

Новая версия Убунты поддерживает новые версии программ, например более всежий Python или MySQL там проще поставить, чем в 10.10.

В интернете пишут, что MySQL 5.5 лучше чем 5.1.

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

в планах переход с MySQL 5.1 на MySQL 5.5,
И какой ожидается результат? И на основании чего? В моем мире, особой разницы до 4-8 процов бить не должно (да и не думаю что ДОУ уж на столько нагружен что должна быть разница от такой «оптимизации»).
этим уже занимается наша киевская команда.
От вспомнилась контора со швейцарской командой и штабом в полтавской области (вроде как) :)
И какой ожидается результат? И на основании чего? В моем мире, особой разницы до 4-8 процов бить не должно (да и не думаю что ДОУ уж на столько нагружен что должна быть разница от такой «оптимизации»).
Мне кажется проще попробовать, чем угадывать какой ожидается результат. MySQL сейчас (последние пару лет) объективно тормозит, имеет смысл что-то с ним делать, мне кажется лучше сначала обновить, а потом оптимизировать, чем наоборот.
От вспомнилась контора со швейцарской командой и штабом в полтавской области (вроде как) :)
Без комментариев.

если MySQL тормозит, то проблема в архитектуре, а не в обновлении ПО. Тем более на объемах ДОУ. Не хайлоад же.

Ну хуже от обновления не стало :) Архитектуру менять сложнее наверное.

Пока что меня настораживает высокий Disk IO rate (в основном от MySQL)
i.imgur.com/rTi5pnM.png
i.imgur.com/4NRWesS.png
Поставили innodb_buffer_pool_size = 1500M
но как-то оно ничего особо не поменяло.
Хотя может этот IO и не высокий а обычный.

В MySql можно компрессировать таблицы, если вы включите компрессию и уменьшите буферы иннодб то больше поместите в память в буферах ФС ОС.

Вот такая табличка была (6 дней назад, правда)
paste.in.ua/8229/raw

Логи и мускуль вижу. Откуда столько записей у мускуля на фс?

Откуда столько записей у мускуля на фс?

Никто не знает :( А как это обычно узнают или дебажат?

show full processlist и смотрим что и куда пишется так активно.

Попробовал несколько раз — в основном сейчас выдается или пустая табличка или иногда select-запрос.

Прямо сейчас вроде не сильно пишет:
paste.in.ua/8243/raw
(не уверен, что угадал с командой)
Хотя newrelic говорит, что 25 writes/sec.

(Уже есть плюс оптимизации — я немгого разобрался с консолью, еще не привык, но уже выучил команду clear, например)

естественно, смотреть надо в час пик.

Ну у меня теперь будет на вооружении эта команда и я научился ее запускать — буду смотреть когда захочу (раньше просил программистов) и когда будет много посетителей.

Все равно она вряд ли поможет, она показывает какой юзер пишет, что наверняка не очень полезно.

Еще есть параметр swappiness, наверное стоит попробовать вместо 60 как сейчас 25.

Мне кажется что самый прямой путь — определить что вы так интенсивно пишете в базу и пофиксить это. Но так же как я уже написал компрессия тоже может помочь — она позволит сильно сократить трафик на диск.

Вот это еще насторожило:

mysql> show global status;
...
| Created_tmp_disk_tables | 1138891 |
| Created_tmp_files | 19 |
| Created_tmp_tables | 2609595 |
...

Возможно это вы много тяжелых джойнов делаете. Теоретически они должны тормозить и наблюдаться в slow query log.

Там действительно много джойнов, от которых стараемся избавляться и заменять их отдельными запросами, но это не всегда помогает по производительности.

Это означает что ваши джойны не помещаются в памяти мускула и он их дампит на диск каждый раз что бы закончить операцию.
Нужно либо оптимизировать джойны что бы они джойнили куски данных поменьше, или увеличить tmp_table_size or max_heap_table_size (dev.mysql.com/...tmp_disk_tables)

Это не обязательно должны быть джойны.

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

Теоретически они должны тормозить и наблюдаться в slow query log.

У нас сейчас насколько я понял как по дефолту:
long_query_time | 10.000000
и потому похоже в slow query log не все медленные запросы записываются.

да, записываются только те, что длинее 10 с выполняются. Это жесть, если такие вообще есть.

Но так же как я уже написал компрессия тоже может помочь — она позволит сильно сократить трафик на диск.
Я кстати на досуге посмотрел, и оказалось что убогий mysql не поддерживает правильную snappy, поэтому компрессию не нужно, наоборот тормозить может начать.

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

Специально вроде не настраивали, а по дефолту такие настройки вряд ли стоят.

Вот такое написал (у нас правда MySQLTuner 1.0.1):
paste.in.ua/8248/raw

Вчера увеличили tmp_table_size & max_heap_table_size с 16 до 32 Мб.

Variables to adjust:
query_cache_size (> 16M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 32M)

В общем-то индексов правильных не хватает, оттуда много записей на винт.

>[!!] InnoDB is enabled but isn’t being used

lolwut? БД на myisam

Я попробовал сделать как тут
stackoverflow.com/...-specific-table

и выдалось, что из 146 таблиц у MyISAM только у трех, остальные на InnoDB.

а чем вас смущает MyISAM ? Он достаточно быстр и для такого сайт как этот — очень даже подходит.

Сегодня уже на ДОУ нет MyISAM таблиц, там были 3 старые и ненужные, теперь все InnoDB.

Так я вот и спрашиваю — зачем? Что есть такого в InnoDB, что вы используете, чего нет в MyISAM, что ради этого стоит жертвовать скоростью?

Так исторически сложилось, не уверен, что там основной удар по скорости или основная функциональность есть. Пока хочется просто навести порядок в проекте и это часто само по себе работает, недавно помогло, например, отключение ненужной таблицы (по кол-ву строк и размеру она была больше всей остальной БД), в которую Celery часто и много писала лог, и проблема была больше в ненужности таблицы, чем в ее формате.

что вы используете, чего нет в MyISAM, что ради этого стоит жертвовать скоростью?
Он не гарантирует целостность данных? Ну и то что myisam быстрее это какой то урбан миф.

Да нет, не миф. Целостности не гарантирует, но никто не мешает ее соблюдать.

Да нет, не миф
Есть свежие бенчмарки на эту тему?
Целостности не гарантирует, но никто не мешает ее соблюдать.
Мешает, если компутер внезапно выключится, то окажется что пост в топик добавлен а счетчик не накручен, потому что нету транзакций.
Мешает, если компутер внезапно выключится, то окажется что пост в топик добавлен а счетчик не накручен, потому что нету транзакций.
Зато есть отличный полукостыль на эти случаи, если уж нужно несколько запросов в один проход осуществлять.

RTFM -> dev.mysql.com/...ansactions.html

Есть свежие бенчмарки на эту тему?
Вы будете спорить, что SELECT в MyISAM быстрее SELECT в InnoDB ? Для этого вам нужен бенчмарк?

А именно селекты и составляют 90 (если не 98%) процентов запросов к мускулю у такого сайта, как DOU.

Зато есть отличный полукостыль на эти случаи, если уж нужно несколько запросов в один проход осуществлять.
RTFM -> dev.mysql.com/...ansactions.html
Этот костыль(тупо лочить всю таблицу) работает против паралельных апдейтов а не против выключения электричества, так что РТФМ сам пожалуйста.
Вы будете спорить, что SELECT в MyISAM быстрее SELECT в InnoDB ? Для этого вам нужен бенчмарк?
Да, буду, а то есть например такое: www.mysqlperformanceblog.com/...chmarks-part-1 innodb кроет myisam как бык овцу.

Спорить лень, спокойной ночи.

stackoverflow.com/...6796566/1346222
Также смущает фраза

для такого сайт как этот

Я, допустим, совсем не понимаю какой доу внутри, тк у меня нет его бд и исходников.

Последние несколько недель плотно занимаюсь оптимизацией клиентской части ДОУ
Из «трюков» (очевидных, но полезных):

— можно небольшие шрифты (например, с иконками) засунуть в CSS как base64, подсмотрел тут: www.artgorbunov.ru/...oviet/20121129

— www.webpagetest.org — хороший и бесплатный инструмент для тестирования и анализа скорости загрузки сайта

— если вас раздражает загрузка веб шрифтов (например, PT Sans), во время которой текст мерцает, можете установть этот шрифт с систему и он не будет мерцать (если в CSS написано «src: local(’PT Sans’)»)

— картинки можно переводить в base64 формат с помощью сервисов типа www.base64-image.de но лучше сначала их оптимизировать чем-то типа PNGOUT.

Еще заметил, что CSS препроцессоры могут генерировать довольно неэффективный CSS типа

.page-forums .b-forum-articles article .article-head .info a.author span

или

.page-forums-messages .items .item .comment a.comment-link:hover span

Наверное их нужно использовать осторожно, пока мне неясно насколько они влияют на производительность страниц большин кол-вом тегов, также есть презентация от гитхабберов на эту тему:

speakerdeck.com/...css-performance

Да, и еще отдельное спасибо за мобильную версию

DOU несколько лет назад, насколько я помню, был переписан на python. Интересно какой фреймвокр используете, и на чем раньше был написан сайт?

Да, кстати очень интересный вопрос. расскажите о технической стороне ДОУ:) Как вы масштабируетесь, как идет рабочий процесс, и т.д.

А стоить ли говорить о какой-либо масштабируемости если миллион хитов не в день, а в месяц?

Сайт хостится на Linode, там используется Ubuntu (кажется 10.10).

Количество серверных разработчиков — 1 ( dou.ua/users/vw )
Клиентских — 1 ( dou.ua/users/jerico )

В качестве «Track-а» используется Trello (до него использовался Pivotal Tracker) и другие системы.

Используется офис на Лукьяновке:
www.facebook.com/...403447979721258

SCRUM как-то не прижился, потому уже не используется.

Используется Sublime text и ноутбук Dell c Убунтой для программирования на Питоне.

Во вторник одна часть команды работала над best.dou.ua и jobs.dou.ua/ratings
а другая (я и Виталий Волков) — работали над самим сайтом — закрыли 8 тикетов разной величины и важности, из заметных пользователям — сабжевое ускорение сайта и рендеринг ссылок в хроме (было так i.imgur.com/fXy8I.png )

Рабочий процесс у нас с Виталием выглядел так:
— собираемся 1 раз в неделю (вт)
— к этому времени я готовлю набор тикетов, которые будем делать

— 2 часа работаем, потом час обедаем, потому еще 2 часа работаем и расходимся

прикольно хороший рабочий график:)

Ну за эти 4 часа довольно много сделали и довольно сильно устали :)

Плюс мне 2.5 часа ехать в офис и столько же обратно.

Еще из технического
— используется git и github (старый ДОУ был на Mercurial)
— используется Less для стилей

— используется google.com/dfp для баннеров (раньше использовался OpenX)

Раньше сайт состоял из двух wordpress-ов (один для блога, второй для компаний) и pyhon-а (pylons кажется). Теперь используется django.

Молодцы, хороший сайт. Django рулит)))

Программисты ДОУ освоили мемкешед, индексы и преперед стейтментс? :)

... и кнопку DELETE
Шота я не даганяю юмор.

И все-таки, вы бы писали что именно сделано для ускорения.

Раньше непрочитанные комментарии выбирались одним запросом (наверное вместе с прочитанными), а теперь выбираются отдельными запросами. Оказалось, что второй вариант быстрее работает, как и почему я не знаю, так как я ненастоящий сварщик.

Блок социалок на главной просто удалили, с ним более-менее ясно — много скриптов, много картинок, много запросов на разные сервера.

К примеру, Follow button
twitter.com/...sources/buttons

— это 2 картинки, 2 json-файла, html-файл, и js файл общим размером 145 кб.

Очень часто лучше 2 быстрых и мелких запроса, чем один большой и толстый.

В таком случае более эффективно чаще всего используются индексы.

Только у меня главная стала поломана? img855.imageshack.us/.../6649/bugxb.png

Да, разница заметна.

Темы про Мишу Собина, Игнайт и прочую нечисть тоже грузятся быстро.

А я-то подумал, что тот мега-баннер удалили с хоумпейджа :)

Ан-нет!

у мегабаннеров же есть кнопка закрыть

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

Еще AdBlock спасает, т.к. на ноуте с 14″ довольно много месте съедается

Ощущается, молодцы действительно стало лучше

Ощущается?

Нет.

А что то сделали?

3.7X speedup from removing a call to sleep

Client gives me a Help Desk Ticket. User claims batch job use to run in 5 minutes but now runs for hours. The logs confirm this. The commit logs show that an offshore programmer forgot to remove a 10 second sleep command from inside an iteration (for debugging I presume) before promoting to production. I removed it and got a 100X improvement in throughput.

My client said that now his user loves him; what did I do to fix it so fast?

When I told him that I removed the Sleep, he said, “No! No! No! Change it to a 5 second Sleep so I have something to give him the next time he complains!”
3.7X speedup from removing a call to sleep
Так это только для пользователей вебкита :)

Я еще подожду отчетов о скорости сайта из Google Analytics и Google Webmasters tools.

И особенно сильно ускорили сайт для залогиненных пользователей.

А для анонимусов и непроверенных аккаунтов стоит что-то типо sleep(rand(0, 5)); ?

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

Еще удалили такой блок
i.imgur.com/KE7wQ.png
он состоит из большого количества картинок и скриптов.

Можно для анонимов- в хидден поле мегабайт 20 текста добавлять =)

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

Подписаться на комментарии