- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Хочешь немного поддосю, проверишь?
ага udp-syn-icmp пакетами))
Processor information AMD EPYC 7763 64-Core Processor, 1 core
Интересно, что за тематика сайта, движок, если не секрет, и это на одном виртуальном процессорном ядре (2,45 GHz – 3.5 GHz), это же VPS?
да, VPS, 1CPU, 2RAM
самопис
там еще бд ~10гб
вся нагрузка на отдачу, почти никаких записей, еще можно логи отключить и получить прирост производительности)
да, VPS, 1CPU, 2RAM
самопис
там еще бд ~10гб
вся нагрузка на отдачу, почти никаких записей, еще можно логи отключить и получить прирост производительности)
Тогда теоретически, если у меня в 4 раза больше ядер, в 4 раза больше памяти, и практически тоже самопис, ну в смысле отдаются уже готовые просто HTML странички из кэша, то в теории 26000 * 4 = 104000 посетителя в сутки :-), а есть какие-то проблемы с открыванием сайта, работой в общем и целом?
в теории это число должно быть равно размер канала / размер отдаваемой странички
допустим на гигабите и при весе странички 50кб, то это будет ~2500 хостов в секунду, больше не получится физически, как-то так)
в теории это число должно быть равно размер канала / размер отдаваемой странички
допустим на гигабите и при весе странички 50кб, то это будет ~2500 хостов в секунду, больше не получится физически, как-то так)
А если с очередями типа Kafka/Rabbit/celery, правильно настроенными I/O операциями с потоками или процессами?
А если с очередями типа Kafka/Rabbit/celery, правильно настроенными I/O операциями с потоками или процессами?
может какие-то квантовые технологии уже придумали чтоб не передавать линейно всю информацию, не знаю, говорю про классику хайлоад стека, и все упирается в ширину канала)
локально ты можешь показать цифры на порядок выше, но на проде не получится протолкнуть объем информации больше чем позволит канал
чтоб не передавать линейно всю информацию, не знаю, говорю про классику хайлоад стека, и все упирается в ширину канала
Не нужно линейно передавать. Ты можешь запросы запихнуть в очереди. Или потоки в threading могут не висеть а засыпать в ожидании ответа, отдавая выполнение другим процессам. В итоге канал, физически обрабатывающи 1000 пользователей сможет работать с 10000.
Не нужно линейно передавать. Ты можешь запросы запихнуть в очереди. Или потоки в threading могут не висеть а засыпать в ожидании ответа, отдавая выполнение другим процессам. В итоге канал, физически обрабатывающи 1000 пользователей сможет работать с 10000.
не понимаю)
если канал отдает контент 1000 пользователям в секунду, то остальные 9000 получат свой контент за 9 секунд, а за эти 9 секунд накопится очередь из еще 90000 пользователей же)
если канал отдает контент 1000 пользователям в секунду, то остальные 9000 будут ждать своей очереди 9 секунд, а за эти 9 секунд накопится очередь из еще 90000 пользователей же)
Мне лень рисовать схему при работе с асинхронными запросами и работе через брокеры очередей, там немного не так примитивно. Запросы пользователей не идут на всю ширину канала, неактивные соединения освобождают опять же канал. Понятно что все это не про Вордпресс, но пайтон + rabbit позволяют держать нагрузку много шире выделенного канала. При этом задержки по времени будут не сильно заметны.