Ну и почему TTFB .95 sec?

Как так получается, что из коробки сразу вылез баг? Вроде хороший сайт.. и тут нате здрасте :\ Можно как то делать сайты без этих ваших глюков? В чем причина и как исправить? Как можно подробнее, пожалуйста. Видимо с этим сталкивается каждый пользователь сего чуда. Причем ладно бы jq догружал, так нет, это TTFB такой большой.. ужас просто.

 

И нате здрасте, опять кто то приехал с понтами... добро пожаловать о господин.

 

подпишусь, узнаю что так пригорело на кухне

 

Я впервые вообще столкнулся с e-comm движком, это нормально 1 сек?

 

Не все зависит от движка, есть еще десяток факторов. Если уж провели анализ, то проведите так же и с другими движками. У всех есть демоверсия. Да и всегда можно сказать "Вам же бесплатно дали, чего хотели?" или про коня пословица. В общем все в ваших руках.

 

https://demo3.slasoft.kharkov.ua/ru/catalog/zapchasti-elektrotehnika
444

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

На вопрос, а нельзя ли это сделать сразу?
Нет, нельзя - на каждого не напасешься настроек

 

У меня база на втором сервере отнимает .1 (из за TCP/IP). Ваши 450 это, в принципе, приемлемо. Вы видимо сделали async, по этому стало быстрее..

Я просто не ожидал что будет такой TTFB по определению, даже с ajax это в раене .5 сек. Ну конечно если кеш крутить, тогда да, получаем практически мгновенный резолв.

p.s. в принципе, кеш на таких проектах это вообще обезаловка..

 

память сейчас дешевая, а лишняя выборка из базы не к чему (нагрузка на ЦП, зачем*)
я не великий спец по кешу, но по моим наблюдениям за правильный код, APCu +OP должен выдать примерно .2-.5 сек. на unix(для такого проекта), если учесть что мемкеш снизит лишние запросы к базе, с ним получится не более .15-.2 сек. в итоге.

Но не .9-1.0 как сейчас по дефолту или 3-5 сек., как я видел у некоторых.. Или я мечтатель?) По факту, спасибо и за это, на шару же. Дареному коню в зубы не смотрят Просто высказал свое субъективное. Думал есть простое решение..

 

какой async - я таких слов для бекенда не знаю

 

причем тут бэкенд, он выполняет задачи по запросу AJAX
лучше разбить запросы через JQ, а на бэкенде контроллер отвечает на эти запросы
он что так отвечает на них, что так. так уж лучше через JS это делать

 

причем здесь аякс?
444 - до применения аякс - т.е. TTFB
Все остальное - уже после загрузки

 

В чем тогда прикол? Почему у меня дефолтный сайт выдает 920?
Существует ли какая-нибудь общая система рекомендаций для развертывания?
Требования к ОС, БД, ПХП, ВебСерверу?

 

Или просто надо кому то задонатить?) Тогда просто скажите сколько и куда

 

обыкновенный шаред
сборка разворачивалась на сервере
Никаких супернастроек не производилось

 

shop.opencart-russia.ru
вот я про это, про то что кеш уводит на 200 мс

 

а 500 мс я не понимаю, в принципе. При 900 вообще невозможно молчать)))

 

расскажите о принципах?
У вас 1000 категорий и все выведены в меню (до 3-уровня)

Сколько вы получите запросв, что получить имя категорий, их ЧПУ?

не менее 1000
маленьких, но много

 

ничего не понял из вами сказанного! Вы модель пытаетесь описать какую-то или что это? 1000 категорий, с условием что они имеют 3й уровень вложенности, или что? Откройте код ядра PHPBB и посмотрите как люди это пишут. Мне уже начинает казаться что проще его адаптировать под магазин, чем тут просить помощи выкрутить нормальный TTFB!

 

На такие случаи есть балансировщики нагрузки на уровне системной архитектуры по уровню распределительные системы, REST архитектура, микросервисы. Я к тому что сейчас не подымают такие сложные вещи на одном сервере. Точнее физически он конечно может быть один. Однако в смысле реализации высоконагруженных систем он скорее всего будет разделен на несколько ВМ. Речь не об этом. Я спрашивал о том почему на сайте shop.opencart-russia.ru 200-250 мс., а в паблике 900? Это типа такой коммерческий ход, я не пойму. Можно на паблик релизе без танцев с бубном достичь хотя бы 250-350? Все что я хочу узнать.. просто ткните пальцев в модуль, который позволит это сделать? Есть такой модуль? Нету, тема закрыта!

 

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

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

Я всегда всем советую... начните ёпрст работать, а не заниматься фетишем сеошмео гуглспид итд..