- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет!
Для 1 проекта ищу Managed MYSQL в Хетзнере, строго локация Германия, суммарно имеем порядка 30000 (100 000 в пике) запросов в секунду на чтение, бд весит чисто символически 2 гб, но нужна её высокая доступность внутри Хетзнера.
И да для злых языков сделай сам ты шо криворук и тп, да с MYSQL и такой нагрузкой у меня не вышло, потому мне нужна именно та услуга какая заявлена в топике с Вашей поддержкой.
TO All: Я не ищу услугу в ДЦ Serverius, Голландии, Англии или России, мне нужно только то что заявлено в топике, хостерам кроме однодневок разрешаю предлагать услуги.
30000 (100 000 в пике) запросов в секунду ... MYSQL и такой нагрузкой у меня не вышло
может дело не в самой mysql, а в том что это все именно по сети должно происходить?
что именно не вышло? у вас было два сервера, один mysql, второй его клиент и между ними какой канал был, 100мбит или больше?
если да, то подозреваю дело именно в этом.
взглянем к примеру:
т.е. если взять ваши 100тыс req/s, то даже просто минимальными 1500-байтными пакетами обмениваться - 100мбит канала для этого впритык.
но каждый mysql запрос у вас наверняка куда больше одного pps занимает. даже если предположить 10 пакетов на каждый запрос, то и гигабитного канала маловато будет.
суть в том что даже если данных там у вас передается не особо много, но проблема именно в количестве запросов, которые нужно протолкнуть по сети.
а значит такой mysql сервер должен быть подключен минимум 10г каналом. и кто знает сколько там клиентов и какие каналы у них.
чисто предположение мое... кто знает что там на самом деле не вышло.
может дело не в самой mysql, а в том что это все именно по сети должно происходить?
что именно не вышло? у вас было два сервера, один mysql, второй его клиент и между ними какой канал был, 100мбит или больше?
если да, то подозреваю дело именно в этом.
взглянем к примеру:
т.е. если взять ваши 100тыс req/s, то даже просто минимальными 1500-байтными пакетами обмениваться - 100мбит канала для этого впритык.
но каждый mysql запрос у вас наверняка куда больше одного pps занимает. даже если предположить 10 пакетов на каждый запрос, то и гигабитного канала маловато будет.
суть в том что даже если данных там у вас передается не особо много, но проблема именно в количестве запросов, которые нужно протолкнуть по сети.
а значит такой mysql сервер должен быть подключен минимум 10г каналом. и кто знает сколько там клиентов и какие каналы у них.
чисто предположение мое... кто знает что там на самом деле не вышло.
ограничение может быть на коммутаторах, hetzner никогда не славился highload оборудованием сетевым...
не каждый коммутатор способен пропустить такое кол-во пакетов (учитывая, что там еще пользователи), потом могут быть банально ограничения - узнавали в поддержке ?
Для таких нагрузок нужно брать выделенную инфраструктуру со своим сетевым оборудованием и полным контролем для анализа ситуации...
Сам слабал мастер + PROXYSQL+slave
а галеру не пробовали?
а галеру не пробовали?
Ну так просто не могла начинать зависать БД. Может быть диски не справлялись?
Если БД 2 ГБ, то может быть всё просто в памяти переместить и уже долбить можно практически бесконечность. Ну и какие запросы тоже важно, если только SELECT это одно, если ещё идут UPDATE и INSERT это другое.
30 000 тридцать тысяч(!) запросов в секунду на SELECT?
Проблема не в сервере баз данных или хостере\датацентре.
Проблема в архитектуре. Используйте noSQL движки , как шину между СУБД и ПО.
PS: более 2 млн карточных транзакций в час, более 4 млн транзакций в час по eCommerce. В голову в жизни бы не пришло пихать на прямую в SQL (Oracle).
30 000 тридцать тысяч(!) запросов в секунду на SELECT?
Проблема не в сервере баз данных или хостере\датацентре.
Проблема в архитектуре. Используйте noSQL движки , как шину между СУБД и ПО.
PS: более 2 млн карточных транзакций в час, более 4 млн транзакций в час по eCommerce. В голову в жизни бы не пришло пихать на прямую в SQL (Oracle).
30 000 в секунду это копейки. У любого виртуального хостера крупного и то больше.
https://habr.com/ru/company/pgdayrussia/blog/326204/
Вот речь про миллионы, и всё работает штатно.
30 000 тридцать тысяч(!) запросов в секунду на SELECT?
У меня (судя по логам мунина) на обычном ВПС в Хедзнере, при наплыве ботов бывают 5-30 минутные пики с 5-10.000 селектов в сек. И ВПС за 20 евро нагружен на 50% всего. Так что Мускуль такие нагрузки спокойно переваривает.