Как стать автором
Обновить

Комментарии 11

Рассматривался ли вариант использования tmalloc, jmalloc и т.п.? И если да, то почему был отброшен?
Да, рассматривался вариант с tcmalloc. Если посмотреть на скриншоты amplifier, то видно, что tcmalloc как раз и используется (woslab, clodslab и hotslab). С ним ушла фрагментация в большей степени. Но перестроение его внутренних кэшей на таких потоках данных, как у нас, все равно заметно и сильно влияет на время вызова operator new и operator delete.
mimalloc значительно быстрее tcmalloc, пробовали?
К сожалению, нет. Почитал описание на github — стоит поэксперементировать. Тем более, что недорого в плане времени. Спасибо!
пишет свою собственную систему фильтрации трафика и защищает с помощью нее бизнес от DDoS-атак, ботов, парсеров, а также многого другого.

Не понимаю, почему все пытаются защититься от парсинга? Пустая трата ресурсов и времени, информацию всё равно достанут. И чем сложнее её будет достать, тем агрессивнее будут методы её получения.
Лучше бы наоборот старались предоставить самый простейший инструмент для выкачивания информации.
Взять тот же 2gis — как то была статья на хабре, что из 2гис слишком легко доставать инфу и они не пользуются никакими защитами, мол какие нехорошие ребята. А что нехорошего? Это же наоборот прекрасно — если информацию в любом случае можно получить, зачем стараться усложнить способы её получения? Зачем платить за защиты, которые не будут работать (я говорю именно о парсинге). Зачем нагружать специалистов изобретать способы предотвращения парсинга, если это только усложнит обслуживание ресурса.

Есть множество различных причин, по которым может возникать потребность в ограничении к автоматическому доступу к информации:
  1. парсеры нагружают ресурс, и эта нагрузка может составлять до 50% от трафика
  2. информацию можно использовать для получения конкурентных преимуществ, например для поднятия своего предложения в товарном аггрегаторе при сортировке по цене

И так далее. Аргумент про то, что все равно достанут, вечен. Как и противостояние снаряда и брони. Остановить нельзя, можно только продолжать совершенствовать технологии.
А не получилось так, что за счет оптимизации одной части кода (выделение/освобождение памяти) замедлилась другая часть кода (бизнес-логика)? Как-то можно замерить, сколько времени ушло целиком на отработку всех запросов?
Да, конечно, замеры производились с помощью wrk и yandex-tank. Наши сервисы работают в разных режимах и где-то, где бизнес-логика простая, прирост производительности показал те же 50%+, а где сложнее — порядка 30-40%. Но тут зависит от архитектуры вашего приложения. Если вы обрабатываете цепочку <чтение запроса> -> <обработка запроса> -> <запись запроса> -> <чтение ответа> -> <обработка ответа> -> <запись ответа> в одном и том же потоке, то влияние на бизнес-логику может быть минимальным.
Просто вы писали, что заменили одни контейнеры на другие. Тут интересно, повлияло ли это както на производительность
Если об этом, то получилось примерно так:

  1. std::deque либо ограничиваем в размере, либо переводим на std::list (редко), либо оставляем на стандартном аллокаторе (редко, блокеры)
  2. std::vector — смотри 1
  3. std::string либо не используется (работаем с бинарными данными из variti::chunk и variti::streambuf через стандартные алгоритмы), либо оставляем на стандартном аллокаторе (редко, блокеры)
  4. std::unordered_map не используется (размеры наших коллекций небольшие и данные редко меняются после инициализации, а еще надо помнить о том, что вычисление хэш-функции может быть дорогим занятием, поэтому мы храним данные в std::deque, сортируем его через std::sort, а потом ищем в нем с помощью std::lower_boud)

Итого, у нас было не так много подводных камней, как кажется. В производительности мы потеряли больше на репостах в соответствующие io контексты делитеров slab объектов, чем на алгоритмах хранения и обработки данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории