Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Я описывал тут кейс, как со своими кривыми руками я добился 12 тыщ в секунду на одном сервере, insert/update, на InnoDb под мускулом (Percona 5.6), естественно это все через веб входило, nginx принимал данные в виде json запросов.
Сами перконовцы до 16 тыщ разгоняют на одном сервере.
Понятно что миллион в секунду не сделать, и тут нужны другие решения. Но просто для проформы упоминаю что 5 тысяч это не меганагрузка.
Если интересно — то microsoft ходит по ссылкам что вы в скайпе друг-другу отправляете.
Т.е. если я отправил ссылку Васе через скайп, то по ней следом заходит skype с ip адреса майкрософта.
Для «превью», я так понимаю, но с этим бывают очень неприятные казусы — как-то передал я товарищу ссылку на тестирование отправки заказов, без форм, внутреннюю, чтобы проверить SOAP обмен данными.
Так вот — обмен запустился, сам собой, с ip адреса microsoft в ирландии была «ткнута» отправленная ссылка сразу после отправки.
Так что у всех такие «косяки» есть, просто мы о них не задумываемся.
зызы: заказ сформировался, ушел клиенту, реально ушел, мы уже задним счетом «разматывали» цепочку, как так ушел заказ который клиент не делал. Оказалось превьюха скайпа оформила заказ )
InnoDb
Про max_request я выше отвечал — было 500 пока боролись. Потом стало 0.
Лимиты файлов — подрезал, а то излишне раздул. И не везде уменьшил, это есть немного, да.
Без опкэша пока что работает. Это следующий шаг. Там вебморда на симфони, код пока пилили, разработчик попросил ни каких опкэшей не использовать, чтобы для начала все хорошо отладить.
Не совсем. Клиент перед отправкой данных сначала запрашивает версию API на сервера, это ему nginx отдает, затем запрашивает контрольную сумму клиента на сервере, это ему так же nginx отдает.
Если что-то не совпало — автообновляется. А если совпало — то идет передача данных. Так что разница реальная по отношению к SQL запросам где-то меньше процентов на 20-30%.
Спасибо, очень интересно! У нас есть идея разделить данные на те что надо дообрабатывать, всмысле сделать рассчеты по ним, и те что не надо, возможно это решение будет в тему для тех данных что нужно просто залить и сохранить.
Вкратце — таблица пользователей, с их данными.
Вторая таблица, в которую идут основные инсерты — ИД юзера, плюс ИД записи данных этого юзера, и 20 полей данных этой записи.
У каждого юзера в среднем 18-20 записей данных.
Плюс вспомогательные таблицы для расчета некоторых полей, часть полей приходит от клиента, часть — калькулируется и затем вставляется в БД в виде записи окончательно.
домру у меня, и в Нск завезли новое оборудование
видимо они его включили
Видимо что-то подкрутил РКН, ещё сегодня утром всё работало, а теперь перестало.
И ютубчик, и инста, и rutor - всё, не арбайтен с этим решением
Я описывал тут кейс, как со своими кривыми руками я добился 12 тыщ в секунду на одном сервере, insert/update, на InnoDb под мускулом (Percona 5.6), естественно это все через веб входило, nginx принимал данные в виде json запросов.
Сами перконовцы до 16 тыщ разгоняют на одном сервере.
Понятно что миллион в секунду не сделать, и тут нужны другие решения. Но просто для проформы упоминаю что 5 тысяч это не меганагрузка.
Т.е. если я отправил ссылку Васе через скайп, то по ней следом заходит skype с ip адреса майкрософта.
Для «превью», я так понимаю, но с этим бывают очень неприятные казусы — как-то передал я товарищу ссылку на тестирование отправки заказов, без форм, внутреннюю, чтобы проверить SOAP обмен данными.
Так вот — обмен запустился, сам собой, с ip адреса microsoft в ирландии была «ткнута» отправленная ссылка сразу после отправки.
Так что у всех такие «косяки» есть, просто мы о них не задумываемся.
зызы: заказ сформировался, ушел клиенту, реально ушел, мы уже задним счетом «разматывали» цепочку, как так ушел заказ который клиент не делал. Оказалось превьюха скайпа оформила заказ )
Про max_request я выше отвечал — было 500 пока боролись. Потом стало 0.
Лимиты файлов — подрезал, а то излишне раздул. И не везде уменьшил, это есть немного, да.
Если что-то не совпало — автообновляется. А если совпало — то идет передача данных. Так что разница реальная по отношению к SQL запросам где-то меньше процентов на 20-30%.
Будем смотреть!
Вторая таблица, в которую идут основные инсерты — ИД юзера, плюс ИД записи данных этого юзера, и 20 полей данных этой записи.
У каждого юзера в среднем 18-20 записей данных.
Плюс вспомогательные таблицы для расчета некоторых полей, часть полей приходит от клиента, часть — калькулируется и затем вставляется в БД в виде записи окончательно.