Pull to refresh
30
0
Send message
Просто чтобы внести некоторую ясность.
Обычная БД вроде 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%.
Спасибо, очень интересно! У нас есть идея разделить данные на те что надо дообрабатывать, всмысле сделать рассчеты по ним, и те что не надо, возможно это решение будет в тему для тех данных что нужно просто залить и сохранить.
Удаляем данные, делаем alter — оно дефрагментирует, так как InnoDb.
5-ть индексов, 3 по одному полю, один по двум полям, один по трем полям.
Нет, данные идут из клиентов, сразу POST запрос в json формате по нужному урлу.
В мускул. Но они все приходят через веб. Так что можно уровнять я думаю.
Если сильно сильно не повезет — потеряем пару секунд транзакций, для нас это не критично — данные от клиента прийдут заново очень быстро.
Пока не придумали как применить. Хотя слова эти витают в воздухе постоянно )
Вкратце — таблица пользователей, с их данными.
Вторая таблица, в которую идут основные инсерты — ИД юзера, плюс ИД записи данных этого юзера, и 20 полей данных этой записи.
У каждого юзера в среднем 18-20 записей данных.
Плюс вспомогательные таблицы для расчета некоторых полей, часть полей приходит от клиента, часть — калькулируется и затем вставляется в БД в виде записи окончательно.
Полностью уйти на приеме данных.
Веб-морда для пользователей остаётся, она вообще не symfony сделана.
Была идея по типу демона авторизации, что на java сделан, сделать и обработку входящих данных так же.
Но пока всё это под вопросом.
Ага, спасибо. Я давно отошел от админства, со времен freebsd 3-й мало что админил из юниксов. Пришлось вспоминать, изучать методом тыка.
По таймауту процессы и убиваются — сейчас у меня 30 секунд стоит.
Про max_request выше писал, прогнал, — было в конфиге 500 когда боролись с утечками. Как победили — стало 0, держит стабильно, память не исчезает в никуда.
1

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity