Спасибо и автору статьи, и вам за улучшенный скрипт, всё работает.
Разве что можно добавить, если использовать список отдельных IP адресов, то нужно задать hashsize и maxelem
Если речь не про выборку из таблицы по индексу, то нельзя просто взять и выбрать 20 записей. Нужно знать где они находятся. А чтобы это узнать, придеться промотать 400 записей и взять следующие 20.
Если выборка идет по индексу, то расположение нужных ключей с нужным смешением в отсортированном индексе известно и можно было бы сначала выбрать нужные id для таблицы, а потом по этим айди извлечь данные.
Но обычно выбираются данные из 2-3 заджоинниных таблиц (комментарий + пользователь + пост)
И соотвественно сначала выполняются условия их сджоивания, и к этой новой выборке уже применяется WHERE. Естественно тут уже нет точного адреса где смешение 400 находится.
И как раз одно из решений проблемы тормозов, не использовать where условие, а сделать сначала выборку нужных айдишников по индексу, а потом заджойнить их:
SELECT * FROM test_table JOIN (SELECT id FROM test_table ORDER BY id LIMIT 100000, 30) as b ON b.id = test_table.id
Можно немного про это тут почитать, хотя эта старая моя статья не содержит особых подробностей habr.com/post/217521
Для меня самое главное в innodb таблицах наконец-то сохраняется значение максимального авто-инкремента даже при удалении записей или перезагрузках базы
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id из-за чего было много не уловимых багов
И вот 3 разных, но достойных сайта, которые вы готовы поддержать майнингом, статьи на которых вы не дочитали и оставили на потом (или просто забыл закрыть закладку), забирают каждый по 30%, 90% итого. В этот момент вы решаете поиграть в гта 5 и посмотреть видео фоном на втором мониторе, и понимаете, что 5 фпс это как-то мало для комфортной игры, а видео что-то заикается постоянно
Но даже если сайт будет 1, всё равно 30% это много.
Для мобильных устройств это расход батареи, для стационарников это постоянно шумящий и крутящийся куллер, который выйдет из строя достаточно быстро при таком подходе.
А если доберутся до видяхи, то еще и жарковато будет, не говоря про то, что и она выйдет из строя быстрее (помнится у меня просто от регулярных игр накрылась видяха за 15к гдето через 8 месяцев, а там было приличное охлаждение)
А вариант постоянно закрывать браузер или закрывать сайты, которые временно не нужны, и вообще боятся что-то сделать на своем компьютере лишнего, а потом искать (или вспоминать) от куда тормоза — это как-то не вариант
Если нужно просто без копирования передать большой объем данных из воркера в основной поток (или из наоборот), при этом в воркере с этими данными работа закончена, то SharedArrayBuffer тут не нужен.
У postMessage есть 2 параметр, в котором указывается массив объектов типа ArrayBuffer, MessagePort или ImageBitmap, и они становятся доступны моментально в основном потоке без копирования.
1. Да ничего особенного не будет. Будет какой-нибудь эксепшен вида «RangeError: Invalid string length» и nodejs упадет, после этого владелец донастроит его и проблема решена.
2. node сам после истечения keep-alive прибьет этот запрос.
Полноценный сервер на ноде это те 5 строчек кода.
А перед сервером, на который предполагается что будет кто-то заходить извне, как ни крути лучше поставить nginx, который и body запрос ограничит в размере, и от примитивного ддоса защитит и т.д.
По сути ведь что? Не настроенный экспресс точно так же будет доставлять проблемы, да и пытаться все уровни защиты дублировать на ноде — это оверхед, всё равно nginx лучше с этим справится.
Ставить экспресс или что-то такое, это не то же самое что залить 2 файла на сервер и запустить их.
Это не проблема, это просто ваш уникальный опыт со старым HTTP/1.0, который можно не тянуть в текущие реалии.
Если уж HTTP/2.0 почти везде уже давно поддерживается, то HTTP/1.1 тем более
Писал когда-то сервер для подобных вещей, пришлось явно ставить длину в хедере
Если речь про старую версию ios, где было HTTP/1.0, то только так.
Но в любом случае раздавать бинарники через ноду смысла нет, а если вы раздаете через nginx, то он сам для статики посчитает и выставит нужный размер content-length.
Любой современный и не очень монитор с flicker-free
Разве что можно добавить, если использовать список отдельных IP адресов, то нужно задать hashsize и maxelem
ipset create vpn_ipsum_tmp hash:net hashsize 1000000 maxelem 1000000иначе будет «ipset v7.1: Hash is full, cannot add more elements»
Если выборка идет по индексу, то расположение нужных ключей с нужным смешением в отсортированном индексе известно и можно было бы сначала выбрать нужные id для таблицы, а потом по этим айди извлечь данные.
Но обычно выбираются данные из 2-3 заджоинниных таблиц (комментарий + пользователь + пост)
И соотвественно сначала выполняются условия их сджоивания, и к этой новой выборке уже применяется WHERE. Естественно тут уже нет точного адреса где смешение 400 находится.
И как раз одно из решений проблемы тормозов, не использовать where условие, а сделать сначала выборку нужных айдишников по индексу, а потом заджойнить их:
Можно немного про это тут почитать, хотя эта старая моя статья не содержит особых подробностей
habr.com/post/217521
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id из-за чего было много не уловимых багов
Но даже если сайт будет 1, всё равно 30% это много.
Для мобильных устройств это расход батареи, для стационарников это постоянно шумящий и крутящийся куллер, который выйдет из строя достаточно быстро при таком подходе.
А если доберутся до видяхи, то еще и жарковато будет, не говоря про то, что и она выйдет из строя быстрее (помнится у меня просто от регулярных игр накрылась видяха за 15к гдето через 8 месяцев, а там было приличное охлаждение)
А вариант постоянно закрывать браузер или закрывать сайты, которые временно не нужны, и вообще боятся что-то сделать на своем компьютере лишнего, а потом искать (или вспоминать) от куда тормоза — это как-то не вариант
https://habrahabr.ru/post/312172/
У postMessage есть 2 параметр, в котором указывается массив объектов типа ArrayBuffer, MessagePort или ImageBitmap, и они становятся доступны моментально в основном потоке без копирования.
Вот тут Transfer Example — https://developer.mozilla.org/ru/docs/Web/API/Worker/postMessage
2. node сам после истечения keep-alive прибьет этот запрос.
Полноценный сервер на ноде это те 5 строчек кода.
А перед сервером, на который предполагается что будет кто-то заходить извне, как ни крути лучше поставить nginx, который и body запрос ограничит в размере, и от примитивного ддоса защитит и т.д.
По сути ведь что? Не настроенный экспресс точно так же будет доставлять проблемы, да и пытаться все уровни защиты дублировать на ноде — это оверхед, всё равно nginx лучше с этим справится.
Ставить экспресс или что-то такое, это не то же самое что залить 2 файла на сервер и запустить их.
Если уж HTTP/2.0 почти везде уже давно поддерживается, то HTTP/1.1 тем более
Если речь про старую версию ios, где было HTTP/1.0, то только так.
Но в любом случае раздавать бинарники через ноду смысла нет, а если вы раздаете через nginx, то он сам для статики посчитает и выставит нужный размер content-length.