Как уменьшить время ответа сервера centos + VestaCP?

Question

[Артём Пинул]

Добрый день.
Имеется собственный сервер на базе ноутбука..

Характеристики сервера:
- CPU AMD Athlon II P360 AMP360SGR22GM 2.3 GHz
- 120Gb SSD
- 4Gb RAM
- OS --> Windows server 2012 --> Hyper V --> Centos 7.2 (для которого выделено 2 GB RAM и 2 Ядра CPU).

На виртуальной машине на базе CentOS 7.2 + панель управления VestaCP (работающая в связке Nginx + phpfpm) у меня крутится сайт на движке OcStore. Который при тестировании сервисом cy-pr.ком мне выдаёт сообщение о необходимости уменьшения времени ответа сервера.. Нужно не более 0.2 сек, а у мня 1.5 сек..

Как можно здесь уменьшить время ответа сервера до приемлемого? Какие могут быть рекомендации? Заранее спасибо.

Answer 1

[Борис Сёмов]

Выложить сайт на нормальный хостинг.

У вас всё сделано для того, чтобы всё было очень медленно:

• Старый, медленный процессор.
  
• Ноут, где всё рассчитано на понижение энергопотребления, а не на скорость работы.
  
• Виртуализация, которая даёт дополнительные накладные расходы.
  
• Всё это ещё, небось, на домашнем инете, с неизвестным качеством исходящего канала и не прогнозируемыми задержками...
  
• До кучи, небось, никто не настраивал тот же mysql, например. Да и вообще, ничего никто не настраивал - панелька поставлена и ок, а на самом деле, панелька тут вообще не нужна.
  

Comments

[Артём Пинул]

- Критика, тоже хорошо..)
Интерес к собственному серверу был по причине желания в этом самому разбираться).
Понятное дело, что дешевле заплатить и закинуть сайт туда, где для вас уже всё подготовил кто то)
Но справедливости ради, могу сказать, что только что заходил на один НЕплохой Украинский хостинг где размещён сайт на таком же движке, посмотрел время ответа сервера по этому сайту и оно оказалось ни чуть не лучше, чем у меня.
Возможно для большого кол.ва посещений в день нужна большая мощность и производительность, а так же ширина канала.. Но для свежего сайта и планированным посещением не более 5-10к в день ширины канала в 100мегабит , судя по статьям в интернете достаточно.
По поводу оптимизации и настройки, согласен., её почти нет., но именно по этому я сюда и пошел с вопросами)
Купить готовое не интересно)

[Борис Сёмов]

Артём Пинул, Разобраться можно, и полезно даже. Но уж не на продакшен сайте, где надо гоняться за скоростью загрузки, собственно.

100мбит у вас на вход, в лучшем случае, иногда, может быть, но вряд-ли.
На выход наверняка намного меньше, и вообще без каких-либо гарантий полосы... Так работают провайдеры.

Но ширина канала тут и не причём. Чаще всего, сайту не нужно большой полосы, нужны маленькие задержки и стабильность канала, а это вообще не относится к исходящим каналам провайдеров. Ну и я не случайно почти в конце это упомянул это и не самая большая проблема...

Производительность нужна, не только для того, чтобы обслуживать много параллельных запросов, но и для того, чтобы каждый запрос обрабатывался быстро. На таком железе как у вас, это просто невозможно. Старый мобильный проц + медленная память + виртуализация. Хорошо ещё, что там amd-v хоть есть...
Это просто очень медленная платформа. И самое узкое место будет тут, а даже не в настройках.

[Артём Пинул]

Борис Сёмов, ок)
Если всё же есть желание в этом разбираться., посоветуйте норм. на ваш взгляд сервер)
Ну именно под мои нужды (не под игровой сервер). Если долго писать параметры, хоть ссылку на готовое решение где то)

[Борис Сёмов]

Артём Пинул, А зачем вам сервер?
Простейшая виртуалка где-нибудь на Digital ocean, Vultr, Vscale, или на аналогичных локальных сервисах вполне подойдёт для таких экспериментов, если нагрузки нет большой. Ну и масштабироваться можно по необходимости...

[Борис Сёмов]

Артём Пинул, И да, если хочется разобраться, то не надо ставить панельку...

Answer 2

[Владимир Скибин]

Смотреть все тайминги:
1. время запроса к DNS - обычно не более 10мс
2. время самого запроса - не более 50мс
3. время генерации страницы CMS на сервере - вот это время не должно превышать 2с. Оно как раз зависит от процессорных мощностей сервера + возможностей самой CMS + настроенного кэширования в самой CMS
4. время доставки первичного контента до браузера. для стационара это не более 500мс, для моби - не более 1.5с
5. время рендера этого первичного контента (HTML) браузером, время аналогично п4. чем слабее машина с браузером - тем медленнее
6. время запросов и доставки вспомогательных скриптов/картинок - это окончательный рендер/исполнение - не более 5с

Эти тайминги я использую в основном для объяснения "скорости работы" для "менеджеров".
Естественно их все можно уменьшить

Comments

[Артём Пинул]

Я так понимаю, что для меня самым важным сейчас является 3 пункт..
Процессорную мощность можно будет изменить только заменой сервера ибо разгона для апгрейта процессора там особо нет.
Кеширование в CMS вроде настроено (стоит хвалённый многими модуль)., читал, что ещё в самой Centos есть возможность настроить должным образом кеширование, но пока не понял, как это делать.
Пока хочется по максимуму сделать всё на уровне софта, а не железа)

[Владимир Скибин]

Артём Пинул, У Вас за сколько генерируется страница? Именно с момента как пришел запрос, до момента отправки html клиенту?

[Борис Сёмов]

читал, что ещё в самой Centos есть возможность настроить должным образом кеширование

Артём Пинул, На таком уровне понимания работы окружения вашего сайта, вы не сможете настроить нормально это окружение. И ещё очень не скоро сможете.

Хостить сайт дома, на старом ноуте, очень плохой способ экономии... Вы потратите массу времени, которое будет стоить дороже приличного хостинга, и всё равно, не получите хорошего результата, в итоге.

Это может иметь смысл, только если сайт вам совершенно не важен, и очень любопытно разобраться, как оно внутри, разве что...

[Артём Пинул]

Борис Сёмов, разобраться., да., любопытно)
А с моим уровнем., таким способом удобно делать контрольные точки в Hyper-V и в случае, если накосячил где то, то легко назад откаты делать)

[Борис Сёмов]

Артём Пинул, Это удобство довольно дорого стоит в плане производительности, которой и так-то добиться не получится на этом железе.