быстрый веб

А точно быстро? Пользуюсь их приложениями, вообще небыстро.

- вместо php

go или свои форки php

- вместо mariadb

какой-нибудь redis, но не вместо а вместе

- вместо nginx

что с ним не так?

- вместо jquery

да этих js фреймфорков как ***** сейчас

ну и микросервисы, k8s, распределение нагрузки, динамические контейнеры и все вот это

Next.js с рендером всего что можно в статику?

Ну либо микрофронтенды/островная архитектура на разных стэках, но судя по опыту github соблюсти консистентность данных на странице потом слишком сложно.

Что используют монстры

спа+джоракул

А ты неспешный.

Для магазина все перечисленное подходит, там все равно нагрузка не миллионами клиентов.

у сбера позорный фронт личного кабинета, особо после недавного перехода на спа ради гейфонщиков

вк тормозит дико

озон тормозит

я хз о чем ты вообще

свои форки php

8.1+ c opcache и jit и так достаточно быстр, зачем заниматься форками, оптимизацией, ресурсы для большего количества процессов дешевле ))

Эээ, что мешает посмотреть их стэк в их вакансиях?

что заюзать в небольшом магазине:

Для такого случая ты больше потратишь на изучение и внедрение этого «чего-то нового и быстрого». И не факт, что станет быстрей.

Используй готовый движок и не парься.

вместо jquery

Чистый JS.

Статику и реверс-проксирование можно делать чем угодно, но разумно это делать nginx-ом, ничего принципиально лучше пока нет.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3), включить сжатие ассетов с правильным алгоритмом (brotli), возможно стоит сжать ассеты заранее. Кеширование статики должно работать нормально.

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

С динамикой всё работает примерно одинаково. Если хочешь максимальную производительность разумными усилиями - Go. Хуже всех по моему опыту Python. Но это экономия на спичках, с большой вероятностью любой популярный вариант будет работать достаточно быстро. Если что-то будет тормозить, то обычно это проблема плохо написанного кода.

База любая из популярных подойдёт, опять же если что-то будет тормозить, то это проблема плохо написанных запросов в базу.

Стоит подумать об отказе от ORM и работе с базой напрямую. Сам по себе ORM не проблема, но он усложняет оптимизацию работы с базой и требует очень высокой квалификации.

Фронтэнд можно любой, опять же все проблемы с производительностью будут следствием плохого кода, а не неправильного выбора фреймворка. У JS-экосистемы есть проблема разрастающихся зависимостей, на клиенте это может стать проблемой, поэтому очень тщательно относись к выбору используемых библиотек. Чаще всего лучше написать свой велосипед из сотни строк, чем подключать библиотеку, которая подтянет ещё пару сотен зависимостей (не сегодня, так завтра). HTML/CSS лучше писать самому, а не использовать популярные библиотеки со стилями.

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

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

Ещё нужно грамотно настраивать БД для быстрой работы. Опять же порекомендую пользоваться облаками и управляемыми БД, обычно они настроены неплохо и лучше ты не сделаешь.

Я думаю у них просто охренительно мощные и дорогие серваки + заранее сделанная статика раздаваемая охренительным CDN-ом))

Что используют

Дык возьмите и посмотрите:

• https://builtwith.com/detailed/ozon.ru
• https://builtwith.com/detailed/sberbank.ru

Так-то преждевременная оптимизация зло. Юзайте то, что юзали в прошлом магазине.

Непонятно, будете сами писать магазин, или заказывать? Вы типа готовы, или есть время за счёт заказчика, изучать новую технологию с нуля?

«Собственные магазины» на текущий момент это просто демонстрация бренда и т.п. Все всё по большей части покупают на озоне/wb. Поэтому траффик на магазин не будет большой да и увеличиваться имно не будет и там надо больше задумываться о красивой и удобной подаче, а не о производительности.

Собственный магазин это один из признаков того, что ты покупаешь не контрафакт из подвала (вероятно китайского), а что-то нормальное.

Вообще если надо полноценный магазин - то проще взять готовое.

Например бутрикс какой.

Да не спешный, но есть в виде саас. Чисто свой темплейт запилить, зато и платежи и бухучет и склады и налоги - все изкаропке

Ещё нужно грамотно настраивать БД для быстрой работы

взял vps, 16гб озу, 200 ссд, 8 ядер, а марию пока настроил так:

[client]
port=3306
socket=/run/mysqld/mysqld.sock
default-character-set=utf8mb4

[mysql]
default-character-set=utf8mb4

[mysqld_safe]
socket=/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/run/mysqld/mysqld.pid
socket=/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log
collation-server = utf8mb4_unicode_520_ci
init-connect='SET NAMES utf8mb4'
character-set-server = utf8mb4

symbolic-links=0
local-infile=0

skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 32M
table_open_cache = 8192
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 0

#innodb_use_native_aio = 0
innodb_file_per_table = 1
innodb_buffer_pool_size = 8G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_thread_concurrency = 6

max_connections=200
max_user_connections=50
wait_timeout=10
interactive_timeout=50
long_query_time=5

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

Есть время изучать как и желание. Цель - моя в получении опыта, заказчика - проба магазина на иных (не php) технологиях. Такой, больше пробный проект.

Допустим, что заюзать в небольшом магазине вместо php

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

Цель - моя в получении опыта, заказчика - проба магазина на иных (не php) технологиях.

Тогда — то, что лично тебе нравится.

Заказчику это не нужно, у него несколько магазинов на битриксе, опенкарте и престашоп еще есть. Хочет чего-то нового, и вопрос денег не беспокоит.

Хочет чего-то нового, и вопрос денег не беспокоит.

Всем бы таких заказчиков)

нового?

ну тогда еликсир и феникс в руки в вперед

Сделай на баше.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3)

Не могу не вспомнить историю онклауда/нехтклауда, которые сначала отдавали статическую мелочь, лепя ее в один файл на стороне сервера, и все работало приемлемо. А потом светлые умы «проанализировали протокол хэтэтэпэ» и сказали епта, у нас же хэтэтэпэ2, параллельные запросы везде, чего объединять-то теперь? И перестали.

И главная страница с их миллиардом нанофайликов цсс и жс (гуд коде практисес же!) начала грузиться полминуты.

а это разве не обязанность моческрипт-упаковщиков минифицировать и слеплять ассеты? причем тут хттп

так быстро генерится/отдается хтмл

Нынче не важно на чем у тебя написана генерация html, если у тебя грамотно: а) настроено кеширование: как на стороне сервера, так и на стороне браузера клиента б) сделана верстка страницы.

кстати о минификации, в ней вооьще есть смысл если нгинкс гзипит все это дело?

кеширование предполагаю memcached использовать, или я устарел?

Собственный магазин это один из признаков того, что ты покупаешь не контрафакт из подвала (вероятно китайского), а что-то нормальное.

Вообще не факт и там и там продать паль могут, даже в нормальном физическом магазине при личном визите могут паль или б/у подсунуть, а ты про online говоришь

обфускация

ну и возможно моческрипт быстрее работает на коротких именах переменных - точно не знаю правда ли это

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

Могут, да. Но всякие алиэкспрессы и их российские подражатели - это прямо как вывеска огромными буквами «рынок по продаже пали».

причем тут хттп

При том, что аналитики (сраные) решили, что раз в протокол (и реализацию) завезли нормальную конвейеризацию/мультиплексирование, то ассеты можно не клеить.

моческрипт

Фу.

Да, такое бывает. Я тоже включил HTTP/2 и сайт теперь стал грузиться вместо полутора секунд - 15 секунд. При этом ничего не менялось. Так и не понял, в чём дело.

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

для начала изучи какой-нить язык, напиши на нём хоть что-то

Курсы по снобизму преподаете?

Что фу. Учим историю. Изначально js назывался MochaScript и потом изза хайпа жявы его переименовали

Ну вот сиди и анализируй)

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

Я занимался нагруженным сайтом на друпале. Сделал около 10 оптимизаций. Почти все что можно сделать сделал. Осталось последнее. Это nginx reverce proxy. Дело в том что генерить каждый раз станицу дорого. Можно ввдавать готовый html и обновлять его каждый час например. Но пока эту тему не реализовал потому что нужен доступ по https а это не просто делается.

Насчёт БД используйте советы mysql tuner.

Но зачем? Есть же etag.

При динамической генерации его заполняем. А нжинксом обрабатываем.

Это прям простейшее кеширование с минимумом правок на беке генерящем динамику

Mocha

«Мока».

С другоооой стороны, «собственный магазин» это один из признаков того, что тебе щас продадут тот же азиатский ОЕМ, но с наклеечкой бренда и вдесятеро дороже.

Нет, это реализм. Изучать что-то новое до уровня написания прода - небыстро.

так быстро генерится/отдается хтмл?

Это где у озона и сбера что-либо быстро генерится и отдается?

В том и дело - OEM. А на алиэкспресс-клонах продают не OEM, там продают фейковые товары.

ozon время отдачи хтмл 90мс, а дальше думает уже ваш проц, как эту всю js вакханалию обработать:-)

Дело в том что генерить каждый раз станицу дорого.

Обычно нет, но надо смотреть на что тратится время, может у тебя там 100500 запросов в бд.

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

Да да, скорость печати 1000 знаков, но такая фигня получается.

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

там продают фейковые товары

Да нифига там не продают. Покажи мне гитару «Gibson» на алишке.

Mocha

«Мока».

По-русски обычно пишут как «мокко».