DeepVarvar а как бэть с кэшем запросов? Перечитай мои предпосылки выше
Всеже скорее имаги в фс лучше
А давайте еще вспомним разгон соединения
Браузеры умеют брать статику в одном соединении
Тоесть в одном соединении несколько файлов
Скрипты не уверен

Ты имел ввиду какойнить SPDY/HTTP2-пердакол или кип-алайв?
В любом случае, если сервер не умеет "не закрывать" (SO_LINGER, SO_REUSEADDR, SO_REUSEPORT) сокет, браузер ничо не сможет.

Кипэлайв ниче не значит
Ты уверен что браузеры будут разгонять имагу с скрипта также как статику в обычные 6 потоков?
Обычно браузеры качают статику в 6 потоков....глянь таймлайны
Ооой....пофиг....
Я думал думал....имаги в бд кроме простоты контроля все остальное проблемы
Имаги должны быть в фс
Спорим?
(Добавление)
Хотя че тут спорить? Выше я рассказал проблемы бд в этом случае....финиш

Есть у меня парочка узких мест, где я бы посохранял имаги в БД.
В остальном я сам все храню в ФС.

А, так ты про партиал 206?

че?
(Добавление)
Не
Я про то что браузеры не качают всю статику отдельными запросами
Они берут все.....ооой....лень
Я забил

https://benramsey[dot]com/blog/2008/[dot][dot][dot]-range-requests/

DeepVarvar да мне пофиг
Посмотри лучше лучше последнюю серию силиконовой долины
И как они умеют последние серии делать лучшими?
Если все не смотрел смотри сначала угар

Колись уже что ты там имел ввиду.

Перевод кубик в кубике
Это важно

кстати профит от имаг в БД пропадает, когда на серваке SSD в рейде.

Давай еще уточним о каких "потоках" ты глаголешь, ато не совсем понятно что ты сказать то хочешь.

Да банально все
Ты в курсе что пакеты разгоняются?
Так вот браузеры пытаются в одно соединение все качать
Чтоб разогнать
А чтоб зря не ждать между пакетами они это делают в несколько конектов
Тоесть когда говорят на каждую имагу подзапрос на самом деле устанавливается 6 соединений и все выкачивают подряд
6 это как правило
Чтоб и разгон был и не ждать разгона
В курсе что размер пакета увеличивается? Помнишь как в тупой винде качали? Сначала скорость маленькая потом выше и выше? Это прротокол...пакеты растут
Так вот скрипты они так не качают...хотя утверждать железно нельзя
Щас ясно?
(Добавление)
Ой посмотрите лучше сериал
Угар

Вот в этом месте подробнее пожалуйста. Как протокол должен понять что по одному и тому же соединению пошла другая картинка?

Тоесь кипэлайв что по тому же соединению пошло вторая страница тебя не смущает
Илюха, устал чтоли?
По заголовкам ясен пень!
Посмотри сериал клянусь ооочень классный
Прям очень....прям угар....с начала только смотри
(Добавление)
Чтоб не сомневаться открой таймлайны в хроме
И погугли как их читать
Много интнресного можно узнать
(Добавление)
Дэк вот я и думаю...кроме явных траблов с беде я думаю что еще и оптимизация браузера пойдет по .... не лучшему пути
(Добавление)
Ну и опять масштабируемость
А в фс все четко и понятно

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

Почему я спрашивал?
Вот почему (я могу быть не точен, но общую картину дам):

HTTP 1.0/1.1 задумывался как запрос-ответ с разрывом соединения.
Т.к. он работает поверх TCP, решили:

0) заимпровить, как я уже писал выше, три волшебных опции при написании серверов и клиентов + threads/select/poll/epoll.

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

(вообще сервер всегда сообщает клиенту что он может, а клиент выбирает что ему подойдет)

2) копрорация бобра запилила свой велосипед SPDY. Боюсь быть не правым, но, хрен с ним, ляпну, что это первая попытка запилить БИНАРНЫЙ протокол, вместо текстового HTTP.

3) не так давно релизнулся HTTP2, он бинарный (и работает только по https), по одному постоянному соединению, в обе стороны (даже без учета https шифрования) летят бинарные пакеты. Браузер может запросить в любой момент любой файл, любой кусок файла, любой урл. Т.е. да, ответ, вернувшийся от сервера "А" совсем не значит, что на сервере "А" был такой файл (привет роскомпозору!!!). Ну и еще много всяких плюшек.