Настройка сервера ищу исполнителя

[pawana]

Здравствуйте.

 

Имеется сервер, на котором нужно выполнить следующие работы:

1. сейчас сервер работает под апачем. Насколько я понимаю, nginx работает быстрее и лучше. Если это так то нужно заменить апач на nginx.

2. настроить rewrite

3. настроить memcached или другое кеширование. Подскажите, пожалуйста, если есть лучше вариант.

4. поднять и настроить почтовый сервер: нужно отправлять и получать письма под своими адресами (имя@мойсайт.com)

 

П.С. на сервере находятся рабочие сайты и глюки, соответственно клюки и падение сервера очень не желательны. Предложения, пожалуйста, отправляйте в личку.

 

Спасибо.

[sitecreator]

nginx+php-fpm - именно в этой связке получается наивысшая производительность при прочих равных условиях.

В случае Опенкарт сам апаче был бы пятым колесом.

 

Но если у вас масса других сайтов на различных движках, то иногда прощу использовать связку nginx+php-fpm + апаче. Точнее, это дешевле для вас, т. к. не нужно в ручную под каждый сайт переписывать конфиги (менять .htaccess на соответствующие записи в конфиге nginx).  А по хорошему нужно, конечно, писать под каждый сайт свой конфиг чтобы можно было обойтись вовсе без апаче.

 

Правда, непонятно как можно делать настройки на сервере с уже существующими глюками и нести ответственность за сервер.  Вы ведь в любой момент можете сказать "вы сломали сервер" и указать на старый глюк, о котором исполнитель может быть не в курсе.

 

Сервер и nginx+php-fpm могу настроить.  По поводу кеширования и прочих моментов, способствующих ускорению - тут нужно уже смотреть конкретно, что будет эффективно в вашей ситуации.

[Blade]

Если товаров меньше 15000-20000

Забейте

Мой вам совет

Настраивали сервер мне,  и очень грамотно.  Если надо напишите http://forum.opencart.pro/profile/3815-savage4pro/ или http://forum.opencart.pro/profile/185-yoda/

И я бы в общем оставил его,  там причина другая была

Но ускорение было в пределах 2 и 3 цифры после запятой в сравнении с моим ими же настроенным сервером,  там у меня апач+ nginx

Если сервер нормальный,  все в порядке с процессором,  памятью

Посмотрите что и как у вас кеширует php/апач/nginx,  поставьте Турбо,  оптимизируйте базу если надо

И будет вам счастье

Если количество в пределах того что я написал,  никакой или почти никакой разницы от перехода вы не заметите

если это хотелка из разряда "мне надо,  хочу" тогда делайте 

Змінено 11 червня 2017 користувачем Blade

[sitecreator]

2 часа назад, Blade сказал:

Если товаров меньше 15000-20000

Забейте

 

забивать не стоит. в приоритете, конечно, должна быть быстрая работа БД. Но если с БД порядок, то почему бы не получить дополнительную производительность?

 

на этом количестве товаров очень даже эффективно использование nginx.  А на еще бОльшем количестве тем более.

 

 

 

2 часа назад, Blade сказал:

Но ускорение было в пределах 2 и 3 цифры после запятой в сравнении с моим ими же настроенным сервером

 

когда БД уже настроена, то можно получить еще выигрыш, например с 250 мс добиться 100 мс загрузки страницы.

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

 

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

 

Цитата

там у меня апач+ nginx

 

апач - это лишнее звено в вашем случае.  В такой связке всех преимуществ вы не получите от nginx.

 

2 часа назад, Blade сказал:

поставьте Турбо

 

Это далеко не всегда выход. Иногда только вред если бездумно ставить в слепой надежде, что все ускорится.  Особенно на нестандартных темах с кучей нестандартных модулей.  особенно на 1.5-й ветке.  В ряде случаев полезно или частично полезно, все от конкретной ситуации зависит.

 

И вы, думаю, не знаете на практике, что такое кеширование средствами nginx.  Никакие турбаторы в сравнение не идут.  Ваша главная может грузиться при этом за 5...10 мс против ваших сегодняшних 150...250 мс (хоть это само по себе быстро).  Да и гуру многие не знают, ибо не любят  nginx.

 

2 часа назад, Blade сказал:

Если количество в пределах того что я написал,  никакой или почти никакой разницы от перехода вы не заметите

 

100 мс будет выигрыш на не очень мощном сервере вроде 2Гига 2Х2.5ГГц.

А дальше сами считайте: разница это или "никакая разница".

Но тут нужно понимать, что этот выигрыш хорошо можно почувствовать если более приоритетные вещи (например, работа с БД) уже сделаны.  Т. е. это один из факторов, влияющих на ускорение.

 

 

Змінено 11 червня 2017 користувачем sitecreator

[Blade]

Прошу ТС сделать скрин с 5-6 сервисов с полными замерами и консоли конечно

После того как sitecreator сделает вам переход на Nginx еще раз покажите пжл все теже самые  сервисы и консоль с новыми скринами

 

зы простое любопытство

Змінено 11 червня 2017 користувачем Blade

[snastik]

7 часов назад, sitecreator сказал:

выигрыш

 

7 часов назад, sitecreator сказал:

 

забивать не стоит. в приоритете, конечно, должна быть быстрая работа БД. Но если с БД порядок, то почему бы не получить дополнительную производительность?

 

на этом количестве товаров очень даже эффективно использование nginx.  А на еще бОльшем количестве тем более.

 

 

 

 

когда БД уже настроена, то можно получить еще выигрыш, например с 250 мс добиться 100 мс загрузки страницы.

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

 

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

 

 

апач - это лишнее звено в вашем случае.  В такой связке всех преимуществ вы не получите от nginx.

 

 

Это далеко не всегда выход. Иногда только вред если бездумно ставить в слепой надежде, что все ускорится.  Особенно на нестандартных темах с кучей нестандартных модулей.  особенно на 1.5-й ветке.  В ряде случаев полезно или частично полезно, все от конкретной ситуации зависит.

 

И вы, думаю, не знаете на практике, что такое кеширование средствами nginx.  Никакие турбаторы в сравнение не идут.  Ваша главная может грузиться при этом за 5...10 мс против ваших сегодняшних 150...250 мс (хоть это само по себе быстро).  Да и гуру многие не знают, ибо не любят  nginx.

 

 

100 мс будет выигрыш на не очень мощном сервере вроде 2Гига 2Х2.5ГГц.

А дальше сами считайте: разница это или "никакая разница".

Но тут нужно понимать, что этот выигрыш хорошо можно почувствовать если более приоритетные вещи (например, работа с БД) уже сделаны.  Т. е. это один из факторов, влияющих на ускорение.

 

 

бред сивой кобылы.

[ocdev_pro]

У моих клиентов сервер аптайм уже 240 дней без перезагрузки.. VPS на Digital Ocean за 10 баксов, Debian 8.5 + apache 2.4 + percona 5.7 
небольшая настройка доп.модулей апача, автобекапы в bitbucket ничего особенного, никаких редисов или мемкешей нету
1300 товаров и посещаемость до 300-400 в день...  тестировалось и при 3й нагрузке никаких ощутимых изменений не было.
Свой почтовый сервер не поднимали, привязали почту для домена от Google (GSuit) и красота, рассылки через MailChimp

Поэтому если у Вас магазин не на 50к товаров и с посещалкой не в 3-5к в день, то смысл платить больше? мемкеши, nginx итд - все эти вещи нужно делать когда в них есть потребность и целесообразность, а не потому-что слышал что вроде работает быстрее итд..

[snastik]

4 минуты назад, Waha сказал:

У моих клиентов сервер аптайм уже 240 дней без перезагрузки.. VPS на Digital Ocean за 10 баксов, Debian 8.5 + apache 2.4 + percona 5.7 
небольшая настройка доп.модулей апача, автобекапы в bitbucket ничего особенного, никаких редисов или мемкешей нету
1300 товаров и посещаемость до 300-400 в день...  тестировалось и при 3й нагрузке никаких ощутимых изменений не было.
Свой почтовый сервер не поднимали, привязали почту для домена от Google (GSuit) и красота, рассылки через MailChimp

Поэтому если у Вас магазин не на 50к товаров и с посещалкой не в 3-5к в день, то смысл платить больше? мемкеши, nginx итд - все эти вещи нужно делать когда в них есть потребность и целесообразность, а не потому-что слышал что вроде работает быстрее итд..

Вот!!! Хоть у кого-то голова на месте.

 

На самом деле надо начинать с вопроса - каким образом nginx+php-fpm  могут уменьшить 1.5 - 2к пусть быстрых но запросов на страницу в базу.
А заканчивать вопросом, - если все таки и настроен подобный огород, то любой шаг вправо - шаг влево - это занесите настройщику еще.

Sitecreator либо сознательно, либо по своей непроходимой глупости подсаживает людей на иглу имени себя..
Если что я вам потом крутить этот NGINX дальше всегда за немалую денежку буду.

ОГА ОГА.

А запустить тесты и понять что отдача html клиенту, собственно чем и занимаеться apache или nginx - по времени отличаться будет в 2мс, а также нет разницы какой из демонов запускает интерпретатор PHP....

[sitecreator]

5 часов назад, nikifalex сказал:

а можно хоть пару слов про зависимость между nginx и количеством товаров.

 

я не говорил про такую зависимость. при любом количестве товаров есть преимущество.

 

snastik,

Что без хамства никак не можете? Или аргументы закончились?

 

 

4 часа назад, snastik сказал:

А запустить тесты

 

все на тестах и основано.

 

Я брал, к примеру, сервер после вашей настройки.  апаче + php (cgi).  Далее переводил в режим nginx+php-fpm.  Версия php сохранялась 5.6.

 

Реальный выигрыш во времени генерации страницы был: 50...100 мс.  только благодаря этому переходу.  Клиент же не идиот, он видит отличие.

Делалось многократное тестирование. Есть сервис Яндекса для измерения отклика, если по какой-то причине не достаточно инструментов браузера.

Тестирование делалось не для сферы в вакууме, а на реальном проекте с просмотрами более 100000 в день.

 

 

Для невнимательных повторю: переход на nginx+php-fpm.

 

 

4 часа назад, snastik сказал:

Если что я вам потом крутить этот NGINX дальше всегда за немалую денежку буду.

 

И что там нужно крутить на настроенном магазине? Тем более "всегда".

Примеры страшилок можно?

 

5 часов назад, snastik сказал:

каким образом nginx+php-fpm  могут уменьшить 1.5 - 2к пусть быстрых но запросов на страницу в базу.

 

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

 

 

 

Повторюсь, что nginx+php-fpm - это не панацея и не дает существенного прироста в запущенных случаях.  Если у вас страница грузится за 1000 мс, а будет грузиться за 950 или 900мс,  то разница незаметна.

И тут нужны в первую очередь другие меры оптимизации. Но снижение со 150 до 100 - это уже результат.  Опять же это имеет смысл в случае если посетителей много и большая нагрузка на сервер. Или если просто хочется.

 

 

[sitecreator]

5 часов назад, snastik сказал:

нет разницы какой из демонов запускает интерпретатор PHP

 

в каком режиме работает php - это тоже без разницы?  Что cgi, что php-fpm - это без разницы?

А апаче умеет работать с php-fpm?

 

 

[snastik]

16 минут назад, sitecreator сказал:

 

в каком режиме работает php - это тоже без разницы?  Что cgi, что php-fpm - это без разницы?

А апаче умеет работать с php-fpm?

 

 

 

Сходите кроликов поразводите...

15 или 10 мс экономии..
 

Утомляете своим бредом.

[Shureg]

"апаче"... хм.. Лучше пишите "apache", а то глаз режет

26 минут назад, sitecreator сказал:

 

А апаче умеет работать с php-fpm?

 

Умеет, если можно так сказать. Потому как это не к нему, а к php относится

Змінено 11 червня 2017 користувачем Shureg

[sitecreator]

16 минут назад, Shureg сказал:

Умеет, если можно так сказать. Потому как это не к нему, а к php относится

 

согласен. не корректно выразился.

Тут больше вопрос в удобстве и скорости настройки.  Тот же ISPmanager предлагает в автоматическом режиме настроить mginx+php-fpm. Это, конечно, не значит, что руками не нужно совсем править конфиги.   Но не предлагает панель управления apache +php-fpm,   тут только руками править конфиги.

 

Но почему то php-fpm не слишком то спешат использовать,  все больше встречаю в режиме CGI.

[snastik]

12 минут назад, sitecreator сказал:

 

согласен. не корректно выразился.

Тут больше вопрос в удобстве и скорости настройки.  Тот же ISPmanager предлагает в автоматическом режиме настроить mginx+php-fpm. Это, конечно, не значит, что руками не нужно совсем править конфиги.   Но не предлагает панель управления apache +php-fpm,   тут только руками править конфиги.

 

Но почему то php-fpm не слишком то спешат использовать,  все больше встречаю в режиме CGI.

 

Как бы вам по русски обьяснить, я уже даже не знаю.

Давайте вот представим мейнстрим. Нормальную жизнь. Мужчины любят женщин, так принято и всем нравиться.
Но есть стайка особо одаренных мужчин, которым начинают вместо женщин нравиться мужчины.
Они оправдывают это тем, что массаж простаты - это очень приятные ощущения, а женщины в массе истеричные создания.

 

Так вот...

Так как 99% пользователей не хотят, чтобы им показывали как приятно массаж простаты, читай php-fpm + nginx.
Они стараются придерживаться классических стандартов. И не искать счастья в ***пе. Которого там еще и не найдешь к тому же.

А найдешь исключительно проблемы.

Де-факто. Опенкарт и его пользователи заточены, привыкли и им удобно работать с Apache, так как управлять серверными директивами через .htaccess  в корне - нанмого проще и понятней, чем через какой-то неведомо где конфиг.

 

Мало того, я понимаю вас, вы увидели ISP и увидели удобный редактор конфига.
Но вы даже LAMP в жизни с 0  не подняли.
Пусти вас сейчас в пустой линукс - вы будете судорожно гуглить в поисках простых ответов из  сериии "МА, А ДЭ ПА".... как в том анекдоте.

 

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

 

И для таких людей необходимо доносить, что не в версии php и в конфигурации интерпретатора дело.
А в тупой базе, в превышенных таймингах, в зависших процессах, в кривых модулях, в диких ботах, незакрытых в роботс.

А версия и тип обработчика php - это САМОЕ ПОСЛЕДНЕЕ БАЛОВСТВО!

[HyperLabTeam]

1 час назад, Shureg сказал:

"апаче"... хм.. Лучше пишите "apache", а то глаз режет

индеец!

я его так называю))

[Shureg]

Ну, я бы не был так категоричен, как snastik. Nginx вполне себе рабочий и актуальный вариант сервера для опенкарта, преимущества известны. Но это не панацея от "тормозов".

Вспоминая, с чего началось обсуждение: если ТС заговорил об ускорении, то, скорее всего, у него проблем с обработкой запросов БД. Или кривые модули... Или убогий (физически) тормозной сервер... Простой установкой nginx этого не решить.

Разница между апачем и энжинксом видна только "по приборам", на глаз заметить дельту в скорости загрузки страницы между 0.25c и 0.1c затруднительно. И значение это имеет  для ублажения гугла и/или при большом количестве посетителей.

[snastik]

2 часа назад, Shureg сказал:

Ну, я бы не был так категоричен, как snastik. Nginx вполне себе рабочий и актуальный вариант сервера для опенкарта, преимущества известны. Но это не панацея от "тормозов".

Вспоминая, с чего началось обсуждение: если ТС заговорил об ускорении, то, скорее всего, у него проблем с обработкой запросов БД. Или кривые модули... Или убогий (физически) тормозной сервер... Простой установкой nginx этого не решить.

Разница между апачем и энжинксом видна только "по приборам", на глаз заметить дельту в скорости загрузки страницы между 0.25c и 0.1c затруднительно. И значение это имеет  для ублажения гугла и/или при большом количестве посетителей.

 

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

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

Я же нигде не написал что это плохо. Я говорю о том что это не нужно в 99% случаев!!!
И без внутренней оптимизации системы в целом, вы хоть стойку сервером ставьте - ничего не взлетит.

 

Чтобы было совсем понятно, я сегодня разворачивал проект, у которого 35 поддоменов, на которы через панель были выданы 35 let's encrypt сертификатов, все виртуалхосты были направлены в один хомяк, и заняло это у меня час времени. А на выходе получилась понятная утилитарная масштабируемая структура, которую дальше расширять можно будет в три клика.

 

Допустим если бы мне моча в голову стукнула заплииться в nginx+php-fpm  - это дикое количество головной боли, пока это все заведется. И еще большее количество головной боли, пока это все завелось, задружило с сертификатами и поняло все редиректы  и исключения.

Ну ок, допустим я бы убил полдня, и все это реализовал. Цена вопроса для заказчика была бы в 3-4 раза дороже непонятно за что. И потом, любое масштабирование, только через мой труп.

 

И скажите РАДИ ЧЕГО ????

Чтобы татуировку себе сделать где нибудь, у меня 45см NGINXа ?

 

[sitecreator]

2 часа назад, Shureg сказал:

Простой установкой nginx этого не решить.

 

так про это изначально было сказано.

 

2 часа назад, Shureg сказал:

Разница между апачем и энжинксом видна только "по приборам", на глаз заметить дельту в скорости загрузки страницы между 0.25c и 0.1c

 

так про то и речь.  Это скорее из разряда "хочется" когда уже заняться больше нечем. 

 

Речь была про тесты. 

Дефолтный ocstore. 

VDS 1Гиг 2.2 Ггц  Место локации сервера: Москва

без внешней нагрузки.  делались несколько десятков замеров. главная страница.

 

вариант 1)  apache+php(cgi) 5.6  90...150мс

 

вариант 2)  nginx+php-fpm 5.6  60...100мс

 

разница небольшая,  но все же не 2 мс.

Нужна ли заказчику эта разница и такое ускорение?  Это решать ему.

 

Желающим могу предоставить доступ к серверу чтобы могли убедиться в реальных его настройках и смогли попробовать оба режима.

 

прямо сейчас (в адресной строке):

убедитесь сами какое время генерации страницы (в данный момент под apache). 

 

Может быть эксперимент некорректный?

 

 

Это под apache+php (cgi)

 

 

 

 

 

 

 

 

это под nginx+php-fpm

 

 

 

Змінено 11 червня 2017 користувачем sitecreator

[Shureg]

36 минут назад, snastik сказал:

 

Ну ок, допустим я бы убил полдня, и все это реализовал. Цена вопроса для заказчика была бы в 3-4 раза дороже непонятно за что. И потом, любое масштабирование, только через мой труп.
 

И скажите РАДИ ЧЕГО ????

Чтобы татуировку себе сделать где нибудь, у меня 45см NGINXа ?

 

Ну, вы еще про шаред-хостинги вспомните.

Я писал для случая, когда у человека свой ВПС и достаточная квалификация(не такая уж и сверхвысокая) для настройки сервера. Не всем надо 35 поддоменов.

И головная боль от nginx - это ваша личная особенность. У меня он ничего подобного не вызывает

Тот факт, что nginx делает ненужными ваши услуги по настройке кэширования файлов - еще не повод говорить, что он отстой

[chukcha]

10 минут назад, Shureg сказал:

делает ненужными ваши услуги по настройке кэширования файлов

Здесь вы не правы. Вы путает серверное кеширвание, и кеширование отрендированногь контента(это модуль от снастика)

 

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

но зачем на вдс/впс иметь прокладку я не вижу смысла.

и.. если 100 хостов в день, то 50 или 100 мс не имеет значения. А если за 1000 в час.. ?

[Shureg]

13 минут назад, chukcha сказал:

Здесь вы не правы. Вы путает серверное кеширвание, и кеширование отрендированногь контента(это модуль от снастика)

 

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

но зачем на вдс/впс иметь прокладку я не вижу смысла.

и.. если 100 хостов в день, то 50 или 100 мс не имеет значения. А если за 1000 в час.. ?

Шаред-хостинги используют сревер apche + прокси nginx. А на впс все прекрасно работает без апача: сервер nginx.

По-поводу кэширования. И какой же тогда контент кэширует "серверное кэширование"? "Недорендеренный"? Что вообще можно рендерить на сервере?

[sitecreator]

Вообще, если поверить, что для опенкарт под nginx может случиться что-то в будущем "страшное"  (хоть ни одного примера такого так и не было, кроме эмоциональных всплесков),  то вы всегда в течение минут 5-ти сможете вернуться к apache.  Если уж так захочется.

 

Это по поводу страхов остаться один на один со "страшным" nginx.  Даже если вы самостоятельно не сможете поставить галочки в ISPmanager, то уж специалистов по apache, которые вам это легко сделают, существует много, согласно гипотезе, высказанной выше.

 

Разве это не так?  Возражения принимаются, но "аргументы" вроде "бред" желательно оставить для другого места.

 

Нет смысла удалять .htacees, которые видит только apache.  Достаточно их закрыть от чтения.  nginx их не использует.  А поэтому никакой проблемы с возвратом к apache в таком случае не должно возникать.  Делается это лишь за счет галочек в панели управления.  Даже правки конфигов, как правило, не нужно.

 

Я специально неоднократно ради тестов переключал проекты заказчиков туда-обратно, никаких проблем при этом не возникало.  ISPmanager либо автоматом заново создает конфиги для сайта/ов при переходе назад к apache,  либо просто восстанавливает ваши прежние рабочие (под apache) из копии (не backup, он для этого не нужен)  если эти конфиги были раньше и не удалены.

 

Чтобы исключить всякие инсинуации,  скажу, что я за настройку nginx+php-fpm не требую дополнительного поощрения.  Мне без разницы, что apache, что nginx настроить.  Также бесплатно переведу назад к apache если вдруг возникнет желание.

 

nginx+php-fpm установлю и настрою конфиги под опенкарт желающим бесплатно (при наличии у меня времени).

Впрочем, вы это и самостоятельно можете сделать даже при небольшом навыке работы с ISPmanager.  Рабочие универсальные конфиги на форуме уже приводились.  В этих конфигах в том числе учитывается и автоматическая аутентификация (нужно для всяких 1С-обменов).

[pawana]

Ну мужики вы даете...

Во-первых вы так всех клиентов распугаете :), причем и своих и чужих :).

Во-вторых - у каждого сервера есть плюсы и минусы, нужно подбирать под конкретную ситуацию. Особенно когда клиент сам не знает что ему нужно. Это ж ваша святая обязанность разбираться в нюансах обеих систем, а не хаять ту, что меньше по душе или ту, под которую ваши модули заточены.

 

Но! Спасибо обеим сторонам, я почитал про nginx и apache - хоть идейную разницу понял :). Вот если бы вы еще столько всего написали про почтовые сервера, я бы может понял как со своим разобраться :).

[sitecreator]

Еще момент.

Помнится, что местные гуру утверждали, что быстрые сайты больше любят поисковики.  Т. е. чем быстрее загружается страница, тем больше за раз (день и т. д.) поисковик проглотит страниц и тем чаще будет посещать ваш сайт.  Тем самым быстрее происходит индексация сайта,  что приводит к более быстрому его продвижению.  Приводились и еще другие аргументы в пользу версии "чем быстрее сайт, тем быстрее его движение в ТОП".  Я верно передал смысл?

 

 

Второй момент.  Поисковики, порой, особенно если товаров много десятков тысяч,  могут буквально "заDDOS-ить" сайт.  Впервые об этом узнал от уважаемых специалистов,  потом и сам с этим столкнулся.

 

Теперь вопрос.  Будет ли польза (учитывая 1-й и 2-й моменты)  если любая страница будет отдана поисковику не за 150 мс, к примеру, а за 5мс...10мс?

 

Nginx умеет отдавать  поисковику кешированную страницу за 5...10 мс. Не важно, главная это или страница со списком товаров или другая.  Умеет ли это делать apache?

И может ли похвастаться хотя бы близкой скоростью отдачи другой вариант кеширования а ля модули (бустеры, турбаторы и т. п.)? 

 

Прошу понять правильно, кеширование средствами Nginx не делает бесполезными другие типы кеширования  вроде кеширование запросов в БД средствами сервера БД.

 

Для того чтобы включить эту возможность, править код вашего магазина не нужно,  делается только настройками Nginx.  Или  с некоторыми правками кода, особенно если хочется чтобы с такой же скоростью отдавалась закешированная страница любому пользователю (и не было проблем с сессионными куками, корзиной и т. п.)

 

Почему в ответ только "бред бред бред"?  Как можно писать "бред" и при этом не попробовав на практике возможности кеширования, которые предоставляет Nginx?

 

Ответьте честно, господа эксперты,  вы пробовали такой режим кеширования?  Если нет, то грош цена вашим заявлениям про "вредность" Nginx.  А если пробовали и вам такая возможность не понравилась, то, пожалуйста, аргументируйте свою точку зрения.

 

Я делал самые разные сборки Nginx.  В том числе и с модулем pagespeed (от Гугл).  И знаю особенности работы этого "ускорителя" от Гугла.  Не скажу, что он мне понравился, но я четко и по пунктам могу разложить почему именно так.  Все познается только в сравнении и практических экспериментах. 

 

 

Я задаюсь вопросом:  почему бы не использовать данную замечательную возможность кеширования средствами Nginx?

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

 

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

 

Неужели задавшийся данным вопросом человек непременно должен попасть в категорию "непроходимых глупцов"  в глазах местных светил?

 

Откуда у вас такой снобизм, господа?  Вы, ведь, даже не пробовали эти возможности?

[ocdev_pro]

sitecreator, между прочим, гуглу ответ сервера нужен до 0,3с, а оптимальное время загрузки страницы в районе 0,8-1с дальше ускорять нету смысла.