если не знаешь, лучше молчи и подумай о своей компетентности
Стоило написать "если не знаешь, лучше спроси на habr.com" 😀
https://qna.habr.com/q/923045
Beget фишит данные своих клиентов. 😀
Время идет, а антивирусы все такие же, хотелось бы посмотреть на сигнатуру Avast, провоцирующую такое срабатывание.
Интерпретируются.
В 8 потоков с pbzip2, тогда будет и PHP-скрипт точно уж попадет в очередь 👍 Хотя, хватит даже 4, если 4 физических ядра, а остальное HT.
Вы тут доказываете, что нагрузка процессора влияет на выполнение PHP?! Серьёзно?
Тут вообще какая-то дикость происходит 😀
Про загрузку проца, вроде ничего не говорил. Посыл больше к этому:
Но в "экспериментах", вы просто грузите систему (процессор, диск, память) с одной стороны... и с другой запускаете скрипт, которому не предоставили ресурсы максимально быстро (как если бы это было при минимальной нагрузке).
А где они должны вводиться?
На стороне шлюза платежной системы, ну либо как делает ivi.ru - iframe платежной системы payture.com
Такое дело, при оплате счетов у одного из хостеров есть оплата картой, но все данные для оплаты вводятся в биллинге, насколько это вообще безопасно? Как я понимаю, если биллинг похекают, то все данные могут перехватить?
Небезопасно, читайте о PCI DSS, чего у хостера с вероятностью 99.999% нет..
https://ru.wikipedia.org/wiki/PCI_DSS
Описание вашей ситуации больше похоже на кардинг. С какой целью вы вводите реквизиты карты в биллинге? Для использования безакцептного списания или для разовой оплаты? Через какой шлюз в конечном итоге проходит платеж? :)
Я считаю, что OpenSUSE отличная альтернатива для администраторов CentOS. Этакий кусочек слакварного.
Кто еще не сделал свой выбор, советую присмотреться к данной операционной системе.
Такой апдейт без записи - да, ибо в памяти это изменение не особо пишет. Как только в диск пишет сразу 75000 наносекунд превратятся в мили, а то и просто секунды.
Если произвести запись с AUTOCOMMIT (175 тысяч транзакций InnoDB), то будет уже 110000 наносекунд при innodb_flush_log_at_trx_commit 2 на SSD :)
Я понимаю, что результаты будут у всех разные. Единственное, что я хотел сказать, что предлагать ТСу перейти на VPS-хостинг, опираясь только на количество запросов, выглядит довольно безосновательно. Это как если бы ТС сказал: "У меня 5000 уников в день на сайт заходят", а кто-нибудь ему посоветовал перейти на VPS. При этом нет никакой информации о скриптах, оптимизации, никакой конкретики, может там вообще сайт на html (просто для примера, к реальному ТСу отношения не имеет).
Один запрос с кучей JOIN'ов к большим таблицам без индексов может натворить дел похуже, чем большое количество апдейтов за час.
Все это нужно смотреть индивидуально, если от клиента поступает реальная нагрузка. Вот ТС-у даже не писали с хостинга о нагрузке, его просто автоматические ограничения защемили.
Вам уже не шаред искать надо, а минимум виртуальный сервер, с таким кол-вом запросов к БД, причём с не менее пары ядер CPU и 4 Гб. ОЗУ.
Может объясните мне с какой поры количество запросов стало показателем нагрузки?
Один запрос UPDATE, делающий SET +1, с выборкой по ID (рандомное значение), в таблице из 650 тысяч записей выполняется за 0.075 ms (зависит от настроек сервера и процессора).Да, 75000 наносекунд. Вам жалко что ли? У меня пинг от компьютера до роутера с патчкордом в 5 раз больше. Эти 175 тысяч запросов UPDATE залетают со свистом за 13 секунд, из них затрачено конкретно на работу CPU еще меньше.
А теперь представьте, что у клиента именно такие небольшие запросы. Нафига ему VPS? 😀
Вспомним теперь, что ограничение 175 тысяч запросов за ЧАС, и если представить что 13 секунд это чисто затраченное CPU время и разбить на 60 минут, то 13/60 = 0.216 секунды CPU-времени в минуту. Сами PHP скрипты съедают процессора, как правило, в несколько раз больше.
Пусть сразу дата-центр свой строит, чего уж там.
Все ограничения MySQL кроме одновременных соединений не нужны. Нет ничего плохого, чтобы сделать миллион UPDATE-запросов в час. Если запросы и таблицы оптимизированы, запросы будут выполняться быстро и не будут грузить MySQL-сервер.
Ищите хостинг в РФ без ограничений на количество соединений/запросов к MySQL в час. Лимитировать количество одновременных соединений - норма.
