- 1
Бесконечный оффтоп имени Борманда #5-
Куча / Говнокод #27625
0
#1: https://govnokod.ru/25864 https://govnokod.xyz/_25864
#2: https://govnokod.ru/25921 https://govnokod.xyz/_25921
#3: https://govnokod.ru/26544 https://govnokod.xyz/_26544
#4: https://govnokod.ru/26838 https://govnokod.xyz/_26838Запостил:
nepeKamHblu_nemyx,
29 Августа 2021
Follow us!
Этот оффтоп сгенерирован автоматически.
Индекс оффтопов: https://index.gcode.space/.
Зеркала Говнокода и полезные ресурсы:
* https://govnokod.xyz/ (альтернативный Говнокод)
* https://gcode.space/ (read-only зеркало Говнокода)
* https://t.me/GovnokodBot (Говнокод-бот в «Telegram»)
* https://t.me/GovnokodChannel (Тематический канал в «Telegram»)
* https://vorec.space/ (глоссарий Говнокода)
* https://app.element.io/#/room/#govnokod:matrix.org (резервный чат)
Примечание: автоматические перекаты в настоящее время осуществляются только с аккаунта nepeKamHblu_nemyx.
Остерегайтесь подделок. Берегите себя и своих близких. Кок!
А ещё мне тут кто-то буквально пару-тройку месяцев назад доказывал прогрессивность электронных трудовых книжек.... Ну чо... удачки вам... лемминги!!!!
А смысл? Это же, насколько я понимаю, не согласие на ведение электронной (она один хер будет вестись и это не обсуждается), а отказ от ведения бумажной. Т.е. подписав эту хуйню я просто потеряю репликацию на бумагу.
А лольку это вообще не касается т.к. у ньюфагов, которые только начинают работать, уже никогда не будет бумажной.
Или я ошибаюсь?
Ахаха.
Самые большие луддиты — это люди в профессии.
Как-то так, да. Причём пенсионный фонд эту статистику один хер уже давным-давно ведёт. Видимо вся реализация заключается в том, что ты можешь распечатать эту табличку через госуслуги.
Дрочить на аккуратные записи, сделанные каллиграфическим почерком чернильной ручкой (если работал в какой-то древней госструктуре).
Там на копипасту ответ. Ему, думаю, вообще похуй.
https://youtu.be/YTnFwSyNgfc
Вот что аниме-девочки животворящие делают!
они послушают вореции, надиктованные металлическим робоголосом, так ещё и оглохнут
Говнокод
Для чего нужен говнокод?
Любой человек хоть раз в жизни задавался вопросом: "что такое говнокод?"?
В этой статье мы рассмотрим это понятие -- говнокод
Для начала давайте разберемся, что же такое говнокод
А что, если выводить десяток инпутов/текстареа со случайными названиями, только один из них делать видимым, а если бот заполнил невидимые поля, то отвергать ввод.
Ну типа:
Допустим, в данный момент средствами CSS видимым делается только четвёртое поле, именно из него и принимается текст комментария, а все остальные должны оставаться незаполненными. Не каждый бот будет проверять реальную видимость текстовых полей.
Интересно, пофиксили? Кто-нибудь знает?
https://itc.ua/blogs/amerikanskiy-bank-testiruet-kartyi-s-dinamicheskim-cvv2-kodom/
Ещё гуглится по сокращению «iCVV».
Какой багор )))
> если код менять каждый час, карта проработает около четырех лет
> литий-ионный аккумулятор
Интересно, если на такую карту попытаются сесть или захотят её разрезать*, сильно будет печь? У кого-нибудь пригорит?
_______
* не знаю, как сейчас, но раньше в Америке протухшие/нелегальные кредитки должен был разрезать бдительный продавец
Такими темпами следующий век мы будем встречать «угу»-ками и каменными топорами.
Телефон зарядил, наушники зарядил, зарядку для наушников зарядил, зажигалку зарядил, фонарик зарядил, пауэрбанк зарядил.
Как минимум, одна ненужная абстракция. Можно взять модель, где ни пердолиться с проводами не надо, ни использовать наушники как два клиента зарядки.
Как по мне, наушники удобнее положить в карман/сумку/на стол, если слушать надоело. А в коробочку - только на зиму/на лето.
Если надо зарядить, в наушники можно просто вставить кабель питания! Не обязательно прерывать прослушивание питушни и складывать их куда-нибудь. Иначе какой-то пердолинг: чтобы послушать питушню, надо наушники убрать в коробочку и ждать неопределённое время. Зачем? Зачем?
Ну мы же про маленькие вкладыши?
А в больших наушниках у меня и аудио кабель можно воткнуть если они рязрядились или хочется нулевую задержку.
И я плавно подвожу к тому, что Яббл-подобные питушни - это какой-то культ извращённого пердолинга. Сначала ты платишь за них, потом они играют неполный день (не то что время бодрствования, даже на стандартный рабочий день не хватит) и не могут заряжаться в процессе прослушивания. Потом оказывается, что заряжать надо в коробке, а чтобы не потерять, нужно докупить шнурок.
Но на рынке есть либо наушники побольше, либо уже соединённые шнурком-аккумулятором маленькие вкладыши с автономностью получше.
Часы, которые нужно заряжать пару раз в день.
Какой багор )))
У меня копеечный браслет работает в районе месяца без подзарядки...
И вот теперь прогресс пошёл в обратную сторону, а пользователи техники компании «Apple» и рады.
Кварцушня на батарейке - годы
Фитнушня резиновая - недели.
Телефон - дни.
Механические часы - день-другой.
Ололо часы - несколько часов.
Кто меньше? Надо попотеть, чтобы заслужить возможность проверять время.
Если же "вечные" с самозаводом.
– нормальную механику вроде заводить надо пару раз в жизни. плюс есть модели, которые автоподводятся при движении рук
но тут надо понимать, что среди ценителей нормальные часы начинаются от $3K
Вроде же кварцушня с батарейкой гораздо точнее, если не переплачивать на три порядка дороже.
А тут ты и платишь, и постоянно корректируешь, и заводишь, если автушни нет.
надо смотреть на механизм и т.п.
я в этом деле не Копенгаген, слишком много умных слов типа турбийона
Чтобы не лезть за мобилой. А то бывает, что хочу время посмотреть, а в итоге залипаю на ГК.
Да там вообще гомосятина, в обе стороны работает.
https://govnokod.ru/27625#comment665864
такую карту можно от зарядки не убирать
правда, не проще ли завести виртуальную карту для таких целей, её "потерять" можно только при повышенном уровне долбоебизма
с другой стороны, с такой картой может быть багор в какой-нибудь Бриташке, где в кассе при выдаче купленных в интернете билетов могут попросить показать карту, которой ты их оплачивал
Подтверждаю, очень удобная штука. На неё ещё и лимиты можно поставить, и если админ сайта best-programming-socks.com.tk решит спиздить данные карты — по финансам это не особо ударит.
в Бриташке есть приложение для покупки билетов на поезд (забыл как называется, давно дело было)
там можно купить билет, НО потом его нужно забрать в автомате, а, чтобы это сделать, нужно засунуть в него карту, которой ты этот билет оплачивал
у меня был сука багор, когда я не смог с первого раза сделать это своей старой карточкой с магнитной полосой, которую там почти никто не принимал, и уже охуел, а потом оказалось, что я её не той стороной тупо втыкал
но поможет ли тут пейпал я не знаю
А что делать тем, у кого дисковода на передней панели уже нету? Наличку то некуда засунуть.
А точно ионный, а не обычная одноразовая литиевая батарейка?
Скажем, при вводе данных карты надо ввести фамильимя, дату, шестнадцатипитузный номерок и трёхпитузный номерок. При бронировании отеля - пару строк адреса, фамилию, имя, что там ещё, ту же карту.
А так начал вводить, браузер подсказал, всё вставил - и отлично.
И да, он умеет много хранить. Адрес, телефон, данные карты - точно хранит.
А чтобы не отключали. Забавно, что в ютубе история поиска осталась. Видимо они сами где-то хранят.
очень долго ютуб не показывал список старых поисковых запросов (но честно всё сохранял, это было видно по мобильному клиенту)
а потом вдруг опять начал
хуй знает, что там у этого гугла происходит. но лучше надеть три презерватива
1. Проверка на ваниш оффтопов проводится раз в 24 часа (было 3).
2. Интервал между загрузками оффтопов во время проверки на ваниш увеличен до 60 секунд (было 15).
Дополнительно выношу на обсуждение прогрессивной общественности предложение об уменьшении лимита комментариев в оффтопе до 350.
Голосую против. Накрутка перекатов какая-то.
Ну, с учётом того, что все и так срут в соседнем треде на семь сотен комментов — погоды это не сделает. Предложение снято.
Можно еще нанять программиста, который сделает движок независимым от количества коментаниев
То есть чтобы скорость работы сайта была на O(N*N) (где N -- количество комментариев) а O(1)
Но тогда придется язык сменить скорее всего
Быстрее O(logN) не получится, но это занудство.
Почему, кстати, не получится?
Он зайдет по FTP, и исправит в Wordpressе нужный php файло чтобы не тормозило
https://github.com/wiistriker/govnokod.ru/blob/master/src/Govnokod/RatingsBundle/GovnokodRatingsBundle.php
Присоединяйся
Потому что всё равно нужно делать «select * from comments where comments.post_id = 27625», а для этого базе придётся искать во всех комментах.
В принципе, возможно, можно взять не btree, а как-то прикрутить хэш (хотя в постгре он, кажется, строится только по уникальным значениям), но тогда константа просядет очень сильно, хотя, по идее, будет амортизированное O(1).
Ну собссно деревья для того ведь и нужны что бы совместиить быстрый поиск с отношением порядка
Так логично построить и hash индекс, и посмотреть как будет себя вести оптимизатор
Если странички с "горячими" тредами попадут в оперативку, то вероятно будет не очень плохо рабоать
Рекомендую великолепный цикл про индексы в «Постгре»: https://habr.com/ru/company/postgrespro/blog/349224/, там в подробностях объясняют, как оно всё работает изнутри.
Работает.
Таким запросом мы всё равно должны выбрать все комментарии из поста post_id, потому что «limit 20» нам вернёт случайные комментарии из этого поста.
Хэш для такого запроса не подходит.
И, в итоге, O(logN) всё равно остаётся пределом.
А какую вы пытаетесь решить задачу?
Хранить весь тред как значение в хешмапе и отдавать as is клиенту. Быстрее ты вряд ли что-то придумаешь.
Нас спасёт толко пагинация.
Можно просто в фоновом режиме генерировать статический HTML с комментами, и отдавать его nginxом через ``sendfile`` с хешем и датой изменения (чтобы работал кеш)
Будет збс
То есть нормализованная СУБД тоже нужна (как источник данных, ultimate source) но отдавать юзеру нужно сгенеренный документ
У нас просто будут не сразу появляться комменты
Современные СУБД (не всякие зумерские «NoSQL» говноподелия, конечно) оптимизированы настолько, что могут уместить в одной транзакции целую банку сгущёнки.
По сравнению с отработкой серверной логики, грамотно написанные запросы в грамотно спроектированную БД — это такие копейки, что о них даже говорить нет смысла.
Конечно, когда у тебя появляются стабильные сотни RPS — тогда можно думать и о кэшировании, но не в файлик на ФС, а с использованием предназначенных для этого инструментов (см. «memcached», например).
А уж если эта статика по дороге на CDN закешируется..
PS: разумеется, статика должна быть УЖЕ зажата: не надо её жать на лету
>memcached
memcached нужен если у тебя несколько фронтов же, а если один, то буфер перед файловой системой -- вот твой memcached
Экономить 287 микросекунд (прошу обратить внимание: это доли от миллисекунды, а не от секунды) при сетевом пинге в ~50000 микросекунд — совершенно бессмысленно.
Вот кэшировать сами запросы, чтобы планировщик не тратил аж 5374 микросекунды — можно попробовать.
Сделал analyze и выполнил запрос пару раз:
479 микросекунд на весь запрос.
> Execution Time: 0.124 ms
> rows=629651 width=502
Not bad.
Такое ощущение что DB в памяти закешировала как минимум индексы (comments_comment_ids, users_user_ids). Никакого IO нет вообще.
А что будет, когда их станет 200, и они все попадут в разных юзеров?
> пинге в ~50000 микросекунд —
ну
> А что будет, когда их станет 200, и они все попадут в разных юзеров?
Я же говорю: когда у тебя будет стабильная сотня RPS — тогда уже нужно будет подумывать о кэшировании. И даже в этом случае достаточно будет навесить примитивный «memcached».
Но стабильная сотня RPS на API — это или дудос, или у тебя аудитория эдак в миллион петухов. Авторам мелких бложиков волноваться о таких вещах бесполезно.
UPD: если ещё проще, то, при условии, что БД проектировал не долбоёб, твой сервер, даже раздающий статику, умрёт под нагрузкой гораздо раньше, чем база.
зачем, если у тебя один веб сервер? что в нем хранить?
>сервер, даже раздающий статику, умрёт под нагрузкой гораздо раньше, чем база.
Это спорное заявление.
Можешь пожалуйста рассказать, как ты к нему пришел?
Какая разница, сколько у тебя серверов?
> что в нем хранить?
Очевидно же: кэши. Запросы, страницы, ответы — что угодно.
> Можешь пожалуйста рассказать, как ты к нему пришел?
Я выше приводил тайминги. Обработка одного HTTP-запроса (вместе с поддержкой TCP-соединения) будет длится гораздо дольше, чем половина миллисекунды, проведённых в БД.
memcache __обычно__ нужен чтобы хранить данные в памяти и шарить их между несколькими машинами
Если у меня одна машина, то почему я не могу хранить кеш прямо в куче своего сервера приложений?
>Очевидно же: кэши. Запросы, страницы, ответы — что угодно.
Не очень пока понятно, что такое "запросы", и чем ответы отличаются от страниц.
Статическая страница, находящаяся в буфере операционки, отдается быстрее, чем какие-то данные, которые нужно скопировать из memcache в адресное пространство твоего сервера приложений, обработать их там (напомню, что у cpython нет JIT) а затем передать их nginxу еще раз скопировав, не?
>Я выше приводил тайминги.
Ты приводил время на обработку одного SQL запроса, да и скорее всего закешированного.
Чтобы утверждать, что "отдача статики загнется раньше", нужно доказать, что нагрузка на CPU при отдаче статики выше, чем при обработке запроса к СУБД и передаче его в ORM в питоне.
Предполагаю, что бОльшая часть времени на обработку запроса связана с ожиданим сети, а не с ожиданием CPU, то есть одновременный заход на сайт даже пятидести человек в случае статики окажется выгоднее, чем обработка пятидести _разных_ запросов, и даже получение их из memcached.
Если конечно сеть не является твоим узким местом: при очень низком bandwidth или высоком latency действительно не важно с какой скоростью ты подготовил данные
Надо еще сказать, что тайминги у GCode.space специфические.
Вот этот скрипт отдается мне за 15ms, судя по developer toolbar
https://yastatic.net/jquery/1.8.3/jquery.min.js
А вот этот за 48ms
https://gcode.space/angular.min.js?v=1.8.2
Если статический файл отдается почти 50ms, то решение с ним выглядит уже не таким привлекательным
Но проблема тут скорее всего не в CPU, а в ио (узнать это можно через vmstat, наверное)
А что если контекст «PHP» хранить в System V shared memory https://www.php.net/manual/en/function.shm-attach.php ?
Вообще говоря контекст не обязан сбрасываться, ведь современные PHP работают внутри сервера приложений
Но сброс контекста видимо идет с тех пор, когда PHP запускали как CGI (запуская процесс с ноля) или как модуль первого апача.
Первый апач форкал потомков, и переодически их грохал
https://govnokod.ru/23448#comment392573
Можно отключить лимит времени исполнения скрипта и принимать входящие соединения через socket_accept. Но тогда мы потеряем возможность использовать пэхапэшную питушню вроде $_GET, $_POST, нам придётся разбирать запросы и формировать ответы самим.
Тогда еще возможнно придется использовать "GC"
так-то оно всё удаляется, но кажется если не закрыть файл, то он так и останется открытым пока процесс не помрет (речь о mod_php в apache)
Но вы и дальше будете за всё, что угодно, кроме PHP.
Получается единая точка отказа.
memcache позволяет запускать несколько машин с «PHP».
«PHP» не хранит состояние, по этой причине он идеально масштабируется, имеет высокую отказоустойчивость.
Именно поэтому я за «PHP».
«PHP» отличный выбор для больших проектов.
Ничто, впрочем, не мешает мне отказаться от стейта и в питоне и даже в джаве
Потому что тогда тебе придётся делать велосипед и решать целую кучу нетривиальных проблем: персистентности (особенно актуально для «PHP»), потокобезопасности (заебёшься, ух как заебёшься делать мутабельный потокобезопасный кэш, который не тормозит), инвалидации-очистки (иначе будешь регулярно падать в OOM), надёжности, производительности и ещё кучки, которых я так с ходу не придумаю.
Нахуй оно надо, когда есть удобные, надёжные и быстрые «заводские» решения?
> Ты приводил время на обработку одного SQL запроса, да и скорее всего закешированного.
Я зря писал про долбоёбов? У меня в «NGK» практически все запросы к API выдают один запрос к БД. Разумеется, если бездумно тыкать в «ORM» и генерировать по сотне запросов в базу — производительности не будет никакой.
> Чтобы утверждать, что "отдача статики загнется раньше", нужно доказать, что нагрузка на CPU при отдаче статики выше, чем при обработке запроса к СУБД и передаче его в ORM в питоне.
Нагрузка на CPU не столь важна, как загрузка сети. Тысяча петухов, подключившихся к твоему серверу одновременно, будут очень долго и вдумчиво разъёбывать твой сетевой стек: гораздо дольше, чем база обработает все их запросы — просто из-за сетевых задержек. Тот же приведённый тобой angularjs, например, загружался по моей сети 22 миллисекунды.
> Но проблема тут скорее всего не в CPU, а в ио (узнать это можно через vmstat, наверное)
Проблема в пинге и работе TCP.
Зачем, если есть готовые решения?
https://docs.djangoproject.com/en/3.2/topics/cache/#local-memory-caching
Живет в памяти, и делает LRU.
>Нагрузка на CPU не столь важна, как загрузка сети.
Что такое "нагрузка сети"? Ширина канала?
А какой у тебя канал?
>разъёбывать твой сетевой стек:
Что ты имеешь ввиду?
Сервер может начать медленно отвечать на запросы по причине
* Загрузки CPU
* Недоступности IO
* Исчерпания ширины канала
(есть еще питушня с RAM, но она тут не важна)
К какой категории относятся проблемы сетевого стека?
Это просто вопрос выбора готовых решений.
И да, джанговский «LMC» для продакшена сосёт, в чём они честно признаются сами:
>> Note that each process will have its own private cache instance, which means no cross-process caching is possible.
>> This also means the local memory cache isn’t particularly memory-efficient, so it’s probably not a good choice for production environments.
> К какой категории относятся проблемы сетевого стека?
Ко всем трём. От большого количества соединений начинает умирать сетевой драйвер (не успевают обрабатываться прерывания), разбухает nf_conntrack, начинает тормозить epoll(). См. C10k.
Логично, что локальная память процесса не доступна другому процессу, но сколько у тебя тех процессов?
Совершенно не очевидно, что внешний процесс лучше, чем локальный кеш каждого процесса (пусть и дублированный)
>От большого количества соединений начинает умирать сетевой драйвер (не успевают обрабатываться прерывания)
Это проблемы ширины канала (и совместимости с ним NIC и драйвера), но мне трудно представить себе приложение, где на каждый заход делается SQL запрос, и при этом боттлнек расположен именно в количестве прерываний сетевой карты, если конечно это не карта в 10 мегабит
> разбухает nf_conntrack, начинает тормозить epoll()
десять лет назад люди тюнили 500К
https://news.ycombinator.com/item?id=1740823
>C10k
Проблема C10k появилась на FTP сервере. Запросов к SQL там всё таки не было, ну и описывает она проблему обработки 10k сокетов
Если к каждому такому подключению добавить SQL запросец, то вероятно 10k случилось бы раньше
Сейчас шесть: по три на дев и основную версию «NGK».
«GIL» делает модель с одним процессом абсолютно недееспособной (если у тебя больше полутора питухов в сутки заходят).
> Совершенно не очевидно, что внешний процесс лучше, чем локальный кеш каждого процесса (пусть и дублированный)
1. Память: если ты можешь дублировать весь свой кэш десяток раз (GIL!) и не сильно просесть по оперативе — у тебя явно не те объёмы, чтобы заморачиваться кэшами.
2. Производительность: каждая копия кэша требует своего наполнения и поддержания. Если твои данные меняются часто — на каждое обновление их будет запрашивать каждая копия кэша, что делает всю затею с кэшем весьма сомнительной.
Так что это весьма очевидно.
> Это проблемы ширины канала
Это проблемы процессора.
> Проблема C10k появилась на FTP сервере. Запросов к SQL там всё таки не было
И что?
Ещё раз: то, что тебе понадобится кэширование, когда у тебя будет постоянно толпиться целая стая петухов — это самоочевидно и не требует обсуждения. Я же говорю об обратной ситуации: когда у тебя посетителей мало (не больше десятков RPS без пиков — тык в небо) — волноваться о кэшировании именно запросов к базе абсолютно бессмысленно, потому что это не принесёт никакого видимого профита в скорости.
GIL не позволяет потокам работать одновременно, но позволяет им работать, пока другой поток спит на IO, верно?
Так что если GIL тормозит твое приложение при заходе нескольких петухов, значит на обработку одного питуха тратится достаточно CPU, и это тоже повод использовать статику
>Память
Даже на дешевых VPS сейчас пара гигов памяти, кажется это не должно быть проблемой, пока к тебе не придет куча петухов
>Если твои данные меняются часто
Да, если данные меняются часто, то ни генерация статики, ни локальный кеш тебе не помогут
>Это проблемы процессора.
Тогда уже сетевой карты, потому что профессиональные карты умеют TCP offloading (или аналогичные приёмы, чтобы не грузить им CPU)
>И что?
А с чего всё началось?:)
Есть две системы. Одна на каждый заход пользователя делает SQL запрос, получает ответ, превращает его в какие-то структуры в питоне, генерирует страничку шаблонизатором, и отдает пользователю
Другая считывает с диска (вероятно уже из буфера) несколько страниц, и отдает их пользователю по HTTP
Ты утверждаешь, что все действия первой системы (посылка SQL запроса, обработка его базой, обработка результата в питоне, генерация страниц итд) ничтожны по сравнению с обработкой TCP, прерываний NIC, итд.
Мне кажется, что это не так.
В качестве примера ты приводить c10k, но c10k не сравнивает эти два подхода
c10k демонстрирует, что старый подход (наплодить потоков или процессов с блокирующими сокетами) работает плохо. Я и не спорю.
>волноваться о кэшировании именно запросов к базе абсолютно бессмысленно
Я волнуюсь не только о базе (хотя и о ней тоже, потому что мы всё еще не знаем что будет, если туда хотя бы 50 запросов пошлют одновременно) но о всём стеке целиком.
Ладно...
Берём test.sql:
Берём pgbench:
: джва потока, 80 одновременных клиентов (больше ставить не могу, надо конфиги править), 100 транзакций (выполнений запроса) на клиента. Результат:
Таким образом, безо всякого тюнинга, с дефолтными настройками, база на «NGK» может обрабатывать больше джвух тысяч транзакций в секунду. На этом фоне обозначенные мной выше 100 RPS (которые являются приличной нагрузкой для нетюнингованного питоньего сервера) — это просто пшик.
И они все улетают в спам как unusual behavior.
Источник комментов загнётся намного раньше...
Солидно. Вы приняты.
А я реально хуею, когда сраные CMS для бложиков на КАЖДЫЙ заход пользователя делают по десять запросов в какой-то mysql.
Особенно смешно, когда автор блога пишет раз в пол года
Нет.
Просто забавное решение уровня ГК: скилльное и упоротое одновременно.
Ну лучше O(N) где N — количество комментов в посте не получится.
Даже если хранить одним блобом/жсоном, всё-равно N влияет на размер ответа.
Ответить => https://govnokod.ru/comments/27558/post?replyTo=667130
Редактировать => https://govnokod.ru/comments/667130/edit
Они же просто отображают текстовое окошко, и не грузят весь тред.
И ещё порядок комментов развернуть в обратную сторону как здесь.
Чтобы новые внизу, а старые вверху.
> И ещё порядок комментов развернуть в обратную сторону как здесь. Чтобы новые внизу, а старые вверху.
Такая идея была, но непонятно, как тогда добавлять свежие комментарии.
Ну если сложная питушня — она не нужна.
Я за простые решения.
> выходных передадим в инженерный отдел
Выходные чтобы отдыхать.
Для начала можно просто поставить href. Чтобы для ответа пользователь не грузил с базы весь тред, а просто получал окошко для ответа.
> Такая идея была, но непонятно, как тогда добавлять свежие комментарии.
Хранить в сторедже последнее место где мы читали, и показывать комменты оттуда.
И кнопка для перемещения в самый низ, к самым свежим. Не настаиваю, просто фантазирую.
Кстати, я даже со своей формочки умудрялась отправить текст с ngk на gk... Правда потом второй клик на самом gk из-за ошибки csrf нужен. Зато можно нормальный редактор привернуть, забекапить коммент в локалсторедж и т.п.
Но смотрится это как пиздецовый костыль, конечно ;(
Но у меня открыта страница где этого комментария ещё нет.
И мне ради ответа нужно подгружать весь тред с комментами (или вручную формировать ссылку с текстовым окошком).
> Зато можно нормальный редактор привернуть, забекапить коммент в локалсторедж и т.п.
Всё можно. Но мне нравится стратегия low hanging fruits.
Сделать копеешную доработку, которая решит 80% проблемы.
Посмотреть помогло ли, и по итогам думать что делать дальше.
Можно начать с ручного закрытия фрейма.
"Hash index cannot be used to create indexes on multiple columns"?
И есть по сути выбор:
* Многоколоночный, но btree
* Отдельный hash для выбора комментов и затем выбор поста по примари ключу
так?
Можно денормальизовать таблу, и хранить спец таблицу
* POST ID
* COMMEND ID
* COMMENT AUTHOR
* COMMENT TEXT
и генерить ее в фоне и по ней показывать всё
будет оч быстро
Нам же не нужно выбрать просто 20 комментов, нам надо получить 20 самых свежих комментов (иначе пагинация работать не будет).
С этой задачей справляется мультиколоночный btree по (post_id, id) (ну или вместо id — create_time, не суть).
Фокус в том, что мультиколоночный b-tree индекс — это, по сути, многоуровневое дерево: в листе с фиксированным post_id находится ещё одно бинарное дерево поиска, построенное по id для всех комментов с этим post_id.
Запрос «from comments where post_id = 50 order by id desc limit 20;» с ним работает, условно говоря, так: сначала бинарным поиском находится поддерево с post_id=50, а потом это поддерево обходится в обратном порядке, в результате чего получаются записи, упорядоченные по «id desc» — вуаля, получили 20 комментов за O(logN).
Я думаю там всё проще, и это одно дерево, лексикографически отсортированное по туплу из ключей.
а, теперь я всё понял.
Действительно, хешем можно выбрать только все комменты
И как только нам нужно "самые первые N" или "все больше N", то нам нужно дерево, а оно логарифм
Давно на него не заходил.
Кстати, движок сайта заколдованный: на всех, кто брался за его разработку, потом нападала тоска. После меня вообще ни одного желающего не осталось за него браться.
Самая популярная тема — про мудаков:
http://holywars.ru/comments/8734
http://holywars.ru/comments/12273
Темы про мудаков даже несколько раз перекатывали, правда, вручную. До перекатного петуха там никто не додумался.
Всё-таки «Гост» — гений.
Спойлер: узкое место точно не в двойных кавычках.
DDoS'ит кто-то?
Нормально.
Мне нужное всякое говнецо потестить, а возможности отображать сток с оперделённого коммента нет.
И мотать джве недели до набега питузков с баграми далековато.
P.S. Для сложного тестирования может быть проще развернуть локальную базу; полные дампы выкладываются ежедневно в https://gcode.space/db_dumps/.
Там же ничего сложного: в SearchController для $scope.result применить isSpam.
Идея такая: если скрыльник не white list и срёт слишком часто, тогда нахуй.
А похуй. Подожду следующих каникул.
Боюсь проблем с бесконечным троллингом. Он там очень кривой (квадратноколёсный велосипед), может сломаться.
В этом проблема?
Предложение (в девтулзе на вкладке с «NGK»):
В res будет 10*20 последних комментов в формате стока, можно проверять на них фильтр. Если нужны старые — в строке после «else» поставь дату в формате «2021-09-01T19:50:58Z».
Спасибо.
Однако уже решил проблему перебанив весь white list.
Тогда сразу идут питузы.
Лол, гостя8 уже давно нет, а коммент остался. А, это вообще от оригинального гостя ещё.
То есть пользы особой от этого массива нет.
Имея только один, первый коммент уёбка, мы не можем понять что это уёбок.
Только впоследствии, но после этого итератор уже не заходит в этот коммент.
return true для скрыльника уже не сделаешь.
Из-за этого на каждом коллбеке нужно пересканивать все предыдущие комментарии на предмет спама, т.к. появляются дополнительные данные.
Внутри нужно обходить пары циклом. Получается тот же O(n³) что и был раньше.
Ну ладно, сделал 2 прохода вроде уменьшил до O(n²) что тоже хуйня, но не такая лютая.
Как скрывать пока не придумал: comments.splice херит накопленную инфу.
Потому просто делаю vanished cmt.text = "";
Кому интересно: можете поиграться.
> проще это сделать на уровне БД
Это мой личный юзер-фильтр, зачем его навязывать?
А вдруг кому-то интересно как у Артура Артурбековича прошли дела в Лондоне?
В одном кирилическое "о", а в другом латинское "o"?
Пирназар Самолюбовер удалил «LinuxGovno» и «WindowsGovno» совсем. Не забанил, а вытер из базы. Потом зарегистрировали новых юзеров с теми же именами. У них новые цифровые айдишники.
У «ISO» на сервере есть говна из вебархива и новые говна. Поисковик не знает, какое говно искать (архивное или новое), когда в поиск вводят «LinuxGovno» или «WindowsGovno».
WindowsGovno: архивный 2566, новый 67968.
LinuxGovno: архивный 3774, новый 25697.
https://govnokod.ru/27549#comment669087
Некоторые не архивные, а действующие юзернеймы неуникальны, как оказалось.
Что-то мне нямекает, что мне и остальным тоже...
Самые популярные почтовые домены в том списке:
1. rainmail.biz — домен продаётся (цену не объявляют, сволочи), поэтому пароли сменить нельзя.
2. gmail.com.
3. mail.ru.
4. yandex.ru.
5. mailinator.com — на этих сменить пароль можно, но, как я понял, это в основном учётки «Стертора», поэтому смысла нет.
6. lackmail.ru — этот сервис не работает, поэтому сменить пароль нельзя.
7. bk.ru.
8. rambler.ru.
9. list.ru.
10. ya.ru.
11. inbox.ru.
12. ukr.net.
В общем, у большинства учёток можно дёрнуть настоящего владельца (если он не уняк, конечно же), чтобы он сменил пароль.
Хотя, в принципе, как-нибудь можно запилить и реальный список скомпроментированных учёток, но это надо чтоб кому-нибудь было не лень.
Ататака index pollution/poisoning
Какой патентный тралинг )))
https://govnokod.ru/27736
https://govnokod.xyz/_27736/