sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"я боюсь что mysql 5.1 из денвера может не подойти
Проверить что? Что тестируемый код запускается и как-то работает?
наперед убеждаясь что качество кода будет достаточным.Ну и в случае бэктестов что он удовлетворяет требованиям системы.
Unit-тесты, например - исключительно разработка.Не все что пишут программисты - разработка. Оно по тому и называется тесты, что несет в себе цель не реализовать, а проверить. В TDD просто ставят телегу впереди лошади (в хорошем смысле), наперед убеждаясь что качество кода будет достаточным.
angluar, react, vue .... с учётом того, что они реализуют и серверную часть - это же уже бекенд, разве нет? Разве я могу их отнести только к фронтенду?они не реализуют серверную часть, ИНОГДА их используют как замену рендера на стороне клиента при написании аппликаций с их использованием, но это суть прокси браузер, полноценным бэкендом это сложно назвать, так как по сути он просто отдает рендеренный вывод для noJS клиентов, таких как боты поисковиков и иже с ними, а не используются на постоянной основе.
А разработка через тестирование - это же процесс?Процесс, однозначно, только скорее TDD моделирование прототипов, я бы больше отнес это к проектированию, хотя это спорный вопрос. Другое дело что тесты не являются отличительной чертой веб разработки, и используются в любом типе разработки.
Скрипт делает один запрос, но не понимаю какая разница сколько он делает, все равно это же один коннект, так ведь ?В теории - да, как на самом деле хз, при условии наличия кода закрытия соединения не известно где "стреляет палка". Скорее всего соединение одно, это несложно проверить тупо вставив дебаги при создании соединения, при запросе и при закрытии.
Что есть я допустим сделаю чтобы сообщения чтобы дергались вообще раз в 30 секунд, итого 500*2 = 1000 в минуту. 1000 / 60 = 16 rps.Че думать, трясти надо (с), поставь и проверь )
это происходит автоматически после завершения скрипта. И данный код в принципе можно убрать.Именно так.
У меня есть файл get-message.php на который каждый в аккаунте каждые 10 секунд идут запросы через таймер.ну давайте считать. 500 пользователей, кроме работы со страницами (которые сами по себе создают некоторый объем запросов, типично 10-20 на страницу), у вас каждый юзер создает 6 соединений в минуту, то есть 500*6 = 3000 в минуту. 3000/60 = 50 рпс (это если скрипт только 1 запрос дергает). Плюс они накладываются друг на друга местами, 3 наложения - как раз ваши 150 рпс.
Очень интересное предложение от куратора.Что конкретно вас смущает? Использование внутренней функции mail() действительно плохая идея. А использование хорошо написанного модуля - хорошая.
Может лучше сначала объяснить как это сделатьВопрос на самом деле должен отправиться в мусор, так как нарушает правила ресурса, то есть легко ищется поисковиком, не говоря уже о том что на тостере есть минимум десяток подобных тем.
Вон, фреймфорк Phalcon полностью написан на CСправедливости ради - не весь, а только пару компонент. И по секрету - с выходом 7 пыха серьезного прироста относительно чистого пыха удается достичь только в крайне узких специфических задачах, можно сказать он протух. Кроме того, для установки фалкона на сервер понадобится поставить еще кучу дополнительных библиотек, ну и сами фалконовые модули. Добавляет "удобства" и то, что методы захардкоренных объектов напрямую из проекта не посмотришь. Короче удовольствие работы с ним ниже среднего (плинтуса).