- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть мобильное приложение (вернее разрабатывается), мы отправляем на него сообщение, приложение сообщает серверу, что оно прочитано (когда оно прочитается). Нужно на бекенде обработать это обращение от приложения и сохранить в базу.
Приложения сообщают id сообщения и id приложения. На сервере нужно в базе сделать два запроса:
UPDATE messages SET read = read+1 WHERE id = id приложения;
INSERT INTO log (id_mes, id_pril, date) VALUES (id сообщения, id приложения, NOW());
и отдать в ответ условный OK. Приложение ждет ответа 10 секунд в фоновом режиме.
В пиковые моменты может приходить до 10 000 таких вот обращений в секунду (проектируемая нагрузка). Но волнами, т.е. отправили мы, условно, 100 000 сообщений, их начали читать и посыпались оповещения о прочтении на сервер. По идее все приложения ждут ответа в течение 10 секунд, т.е. ответ можно не прям вот срочно отдавать, возможно некое ожидание. Нужно всё это корректно обрабатывать и сохранять.
Как всё это правильно построить? Несколько серверов под обработку, один под базу? Балансировку нагрузки делать? если да, то в какую сторону смотреть? Какие конфиги (оперативка/ядра) оптимальны серверов?
А может вообще пересмотреть сохранение в базе? Т.е. допустим только вставки, а потом какой-нибудь бот обрабатывает отдельно и делает апдейты... Или может что-то облачное есть для этого?
Ну и да, нужен человек, который всё это построит и настроит )
имхо если не нужна мгновенная реакция то все подтверждения о прочтении складывать (где-то накапливать), а потом раскидывать куда надо. И растяните по времени рассылку и не будет 10 тыс. сразу...
Мгновенная реакция не нужна. Главное приложению отдать в ответ статус 200ОК, а не какой-нибудь 502 или 504, чтобы оно не ждало и не пыталось еще раз соединиться и отправить.
А где тогда складывать можно? По сути в очередь какую-то, откуда не спеша нормальным темпом будет в базу все раскладываться. Как такую очередь можно сделать? Какую-то базу, куда тупо инсертить данные? Но опять же - 10 000 за секунду придет в очередь разными запросами, надо как то обработать...
посмотрите в сторону nosql базы. например, redis. 10000 вставок в секунду он сделает легко без всякого распараллеливания и балансировок. При желании их конечно тоже можно будет прикрутить. Очередь тоже можно сделать на redis, но судя по описанию задачи она вам не нужна.
На моем ноутбуке, например:
$ redis-benchmark -t set,lpush -n 100000 -q
SET: 112359.55 requests per second
LPUSH: 115874.86 requests per second
также оценки нагрпузки кажутся завышенными в 100 раз как минимум. У меня была рассылка в 100 тыс. Реакция растягивается на неделю и больше 100 в сек не бывало... Или у вас игроков-юзеров одновременно 100 тыс. онлайн?
на счет тестов - там же будет 10 тыс. блоков данных с разных ip? а не просто переменую из памяти в память...
что-то мне кажется 10 тыс. в сек надо какой-то нехилый сервер.
Как-то давно пробовал 1 тыс. аппаратных прерываний от сетевухи в сек - средний комп виснит. 10 тыс. - х-м-м-м
Отдайте все ваши 200ок, а потом распарсите логи сервера неспеша...
приложениям дайте пул ip много разных, пусть случайно выбирают в случайное время, так и будет балансировка сама собой на стороне клиента.
что-то мне кажется 10 тыс. в сек надо какой-то нехилый сервер.
Как-то давно пробовал 1 тыс. аппаратных прерываний от сетевухи в сек - средний комп виснит. 10 тыс. - х-м-м-м.
Как давно? В 90-х?
https://blog.cloudflare.com/how-to-receive-a-million-packets/
https://mrotaru.wordpress.com/2013/10/10/scaling-to-12-million-concurrent-connections-how-migratorydata-did-it/
цитата из вашей ссылки
For the experiments we will use two physical servers: "receiver" and "sender".
Тут же сендеров будет 10 тыс. (конкуренция, коллизии) Вы 100% уверены что это одно и тоже?
из второй ссылки "24 CPU cores" и какая-то супер навороченная сетевуха с аппаратной балансировкой очередей и аппаратных прерываний по "cores"... как бы тоже не простой ПК (10 тыс. / 24 = меньше 500 на core, что грубо говоря согласуется с моим результатом)
я же пробовал 2х ядерный WIn7
в общем я бы на месте топик стратера решил вопрос растягиванием рассылки и пулом ip + обычный сервер и не парился
головоломками с аппаратной балансировкой на много много "cores" и настройкой матерых сетух.
Советуют довериться сохранению информации о прочитанных сообщениях сторонним облачным сервисам, типа Google Firebase. Есть ли у кого опыт? Насколько там точны данные?
Советуют довериться сохранению информации о прочитанных сообщениях сторонним облачным сервисам, типа Google Firebase. Есть ли у кого опыт? Насколько там точны данные?
Не надо доверять никому.
Если скорость реакции не важна - то все очень просто.
При приходе запроса от пользователя - сохраняется файл с этими данными с название 123.date('').random(10).sql
Следующий 123.date('').random(10).sql . И так далее.
Получается что скорость ответа будет зависеть от скорости записи на диск и от кол-ва возможных одновременных подключений (настраивается в nginx).
Все. Затем каждую секунду 4-5 запросов в бд делать. А файл с данными, которые добавили - удалять.
Если ничего не придумаете, то можно использовать как вариант тот же iron.io с их очередью, куда клиенты будут пушить сообщения, и потом потихоньку забирать из очереди и обрабатывать.
Советуют довериться сохранению информации о прочитанных сообщениях сторонним облачным сервисам, типа Google Firebase. Есть ли у кого опыт? Насколько там точны данные?
Так дорого же.
https://startupsventurecapital.com/firebase-costs-increased-by-7-000-81dc0a27271d
---------- Добавлено 06.09.2017 в 15:29 ----------
For the experiments we will use two physical servers: "receiver" and "sender".
Ну логично, что для чистоты эксперимента она разделили отправителей и получателей. У ТС отправители - это будут телефоны пользователей, так что норм.
Обращу внимание, что по ссылкам идет речь о миллионах соединений, а не тысячах.
Обычный сервер, сейчас все такие делают на intel'ах.
Не очень удачный выбор ОС для подобных экспериментов :)
головоломками с аппаратной балансировкой на много много "cores" и настройкой матерых сетух.
Ему не потребуется балансировка и какая-то особая настройка, кмк. Растянуть и запулить можно в любое время потом. Главное - начать :)