Там есть столбец мощности (по https://www.cpubenchmark.net/, но это суммарно на все ядра). Вам, следовательно, надо зайти туда и посмотреть каждый камень на single core benchmark
Действительно, в этом случае кэширование запроса не будет использоваться. Вот, кстати и образовался один совет ТС: избавиться от NOW(), вместо этого определять текущее время в скрипте и передавать его параметром в запрос.
Chukcha: Есть индексы, в том числе и составные product_id + language_id
Слишком большое число индексов - тоже нехорошо, ообенно составных, т.к. оптимизатор MySQL в них начинает путаться и может сделать не очень хороший план запроса. Попробуйте удалить составные индексы, после чего пересобрать статистику командой ANALYZE TABLE.
А те запросы которые медленные - нужно понимать их частоту вызова!
Одинаковые, часто вызываемые запросы должны попадать в кэш запросов MySQL. Проверьте, включен ли он у вас. Покажите план выполнения медленных запросов.
Ну выбирать в любом случае надо из Xeon;ов, вы же не хотите сидеть на десктопном железе. Из приведенных Xeon'ов производительность выше у E3-1245V2.
Pilat, у процессора должна быть аппаратная поддержка (VMX)
Там есть столбец мощности (по https://www.cpubenchmark.net/, но это суммарно на все ядра). Вам, следовательно, надо зайти туда и посмотреть каждый камень на single core benchmark
iman, также, за исключением возможности прямого перехвата пароля злоумышленником при работе "админа" в незащищенной сети.
Это не файл, а unix socket. Он будет удаляться, если соответствующий процесс (php-fpm) завершает работу.
1. столкнулся с проблемой поиска врачей в московских клиниках
2. скачал скрипт
3. получил 1 млн долларов от инвестиционного фонда Aurora Venture Capital
4. ...
5. profit!
https://ru.wikipedia.org/wiki/DocDoc :)
А размер базы какой? Берите оперативки не меньше чем половина размера базы, или придется заниматься оптимизицией :)
Всё правильно
ага при наличии NOW какой кеширование?
Действительно, в этом случае кэширование запроса не будет использоваться. Вот, кстати и образовался один совет ТС: избавиться от NOW(), вместо этого определять текущее время в скрипте и передавать его параметром в запрос.
Есть индексы, в том числе и составные product_id + language_id
Слишком большое число индексов - тоже нехорошо, ообенно составных, т.к. оптимизатор MySQL в них начинает путаться и может сделать не очень хороший план запроса. Попробуйте удалить составные индексы, после чего пересобрать статистику командой ANALYZE TABLE.
Одинаковые, часто вызываемые запросы должны попадать в кэш запросов MySQL. Проверьте, включен ли он у вас. Покажите план выполнения медленных запросов.