Обычная БД вроде 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 записей данных.
Плюс вспомогательные таблицы для расчета некоторых полей, часть полей приходит от клиента, часть — калькулируется и затем вставляется в БД в виде записи окончательно.
Полностью уйти на приеме данных.
Веб-морда для пользователей остаётся, она вообще не symfony сделана.
Была идея по типу демона авторизации, что на java сделан, сделать и обработку входящих данных так же.
Но пока всё это под вопросом.
Ага, спасибо. Я давно отошел от админства, со времен freebsd 3-й мало что админил из юниксов. Пришлось вспоминать, изучать методом тыка.
По таймауту процессы и убиваются — сейчас у меня 30 секунд стоит.
Про max_request выше писал, прогнал, — было в конфиге 500 когда боролись с утечками. Как победили — стало 0, держит стабильно, память не исчезает в никуда.
Я описывал тут кейс, как со своими кривыми руками я добился 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 записей данных.
Плюс вспомогательные таблицы для расчета некоторых полей, часть полей приходит от клиента, часть — калькулируется и затем вставляется в БД в виде записи окончательно.
Веб-морда для пользователей остаётся, она вообще не symfony сделана.
Была идея по типу демона авторизации, что на java сделан, сделать и обработку входящих данных так же.
Но пока всё это под вопросом.
По таймауту процессы и убиваются — сейчас у меня 30 секунд стоит.
Про max_request выше писал, прогнал, — было в конфиге 500 когда боролись с утечками. Как победили — стало 0, держит стабильно, память не исчезает в никуда.