Оптимизация загрузки изображений и аватар -download/file.php

[drlov]

Добрый день,

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

В phpbb, чтобы отобразить какое-либо изображение вставленное вложением, нужно выполнить скрипт download/file.php, который сделает несколько обращений к базе данных, проверки прав доступа. Тоже касается загрузки аватар.

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

Я начинаю подумывать над переработкой системы вложений - перед отображением топика проверять, что вложение картинка и отображать прямую ссылку на физический файл, минуя download/file.php.

Кто-нибудь интересовался подобной проблемой?
Может есть уже готовые решения для сайтов с большой посещаемостью?

[MAzZY]

Запретите хотлинкинг в htaccess

[drlov]

Запретите хотлинкинг в htaccess

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

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

А я хочу именно рендерить атачи как простые картинки, с прямыми линками...

[Mr. Anderson]

drlov
Как вариант - кешируйте запросы к БД. Описанные вами запросы - семечки и при правильном размере Qcache (мы же про MySQL говорим, да?) закешируются все (ну хорошо - наиболее частые) и будут отдаваться за тысячные доли секунды практически без нагрузки.

[drlov]

Как вариант - кешируйте запросы к БД. Описанные вами запросы - семечки и при правильном размере Qcache (мы же про MySQL говорим, да?)

да, говорим про мускул.
Почитал про этот кеш на хабре, вот выдержка:

Одна из самых бесполезных вещей в мускуле. Вроде бы даже слышал что ее уберут в 6 или 7.
Для проектов с большой нагрузкой мускуль кеш использовать бессполезно, ООЧЕНЬ не эффективно. Для остальных особой разницы и востребованности нет.

Мое мнение - это вовсе не выход, а так попытка сделать затычку.

У меня сейчас с возросшей посещаемостью (под 5000 хостов) начались резкообразные скачки нагрузки на сервер, кол-во конекшенов к апачу доходит до 100 и гаплык 500 ошибка...
Хостер естественно говорит нужно железо апгрейдить, но ведь я понимаю, что phpbb с картинками в качестве вложений жутко не оптимизирован и если оптимизнуть то ресурсов еще хватит огого...

!!! И вообще, где это видано, что для того чтобы загрузить с сервера простую картинку, серверу нужно сделать кучу работы, вместо простой отдачи файла, он запускает php, подключает кучу файлов, делает два-три запрос к базе, это жесть!!!!!! О какой оптимизации может идти речь?


PS. так для инфы моя конфа: phpbb 3.0.7-PL1, полный пакет ultimate seo, + пара модов последних версий, из которых самый тормозящий это board3_portal.

[Mr. Anderson]

drlov
Мнение про кеш довольно спорное, ну да это тема отдельного разговора.

под 5000 хостов

Это суточное?

кол-во конекшенов к апачу доходит до 100 и гаплык 500 ошибка

Правильно настроенный nginx спасет отца русской демократии
Ну и апач тоже можно настроить как надо... Если он в IO-очередь не упирается, то и коннекты увеличить не проблема.

Хостер естественно говорит нужно железо апгрейдить

И у вас, конечно же, от нового железа количество коннектов к апачу в пиках упадет?

где это видано

Например там, где вы закачиваете картинка НА ФОРУМ, а не на файловое хранилище или какую-то публичную веб-галерею.
Помимо прочего, такие проверки позволяют не использовать ваш хост как файлопомойку (а также упрощают поиск потерянных вложений).

[drlov]

Это суточное?

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

Правильно настроенный nginx спасет отца русской демократии

В этом я профан... поспрашиваю знающих...

Ну и апач тоже можно настроить как надо... Если он в IO-очередь не упирается, то и коннекты увеличить не проблема.

Что интересное конекты увеличивать увеличивали до 200, так нагрузка на сервере скакнула вообще за 100%, а вот касательно проверки на IO-очередь, это го не делали, да и честно я сам не знаю как это проверить, а хостер видимо режим снежинки включил.

И у вас, конечно же, от нового железа количество коннектов к апачу в пиках упадет?

Тоже самое я сказал хостеру!

Например там, где вы закачиваете картинка НА ФОРУМ, а не на файловое хранилище или какую-то публичную веб-галерею.

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

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

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


Ребят, гляньте на сайт ЯПлакал, посмотрите на посещалку, И !!! обращаю ваше внимание, он сделан целиком на форумном движке, правда не phpbb, а IPB, только вот я не в курсе, там сами прогеры переделывали систему вложений или она такая идет изначально. А вложения там сделаны прямыми линками.


Потому как я сейчас вижу, на phpbb, кардинально не меняя систему вложений или не меняя кардинально железо, о высокой посещаемости можно забыть, в связи с неоправданной нагрузкой на сервер!

[Mr. Anderson]

ну да.

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

В этом я профан...

Не знать - не стыдно (с)

Тоже самое я сказал хостеру!

Ну да он у вас явно

режим снежинки включил.

Дак если сервер загибается от нагрузки

Для начала я бы определил источник этой нагрузки. И уже от этого плясал бы. Например, если ресурсов свободных дофига, но IO-очередь заполнена, процессы будут ждать её освобождения, почем зря повышая показатели загрузки. И тут уже практически пофигу будет запускаться пхп для обработки скрипта и проверки прав или апач "напрямую побежит" к файлу - оба варианта будут ждать очереди.

К тому же статистика потеряности ничтожна мала!

Не в последнюю очередь потому, что есть проверки. Без них вы бы каких-то левых файлов вообще не увидели (как из тысяч файлов найти левый?).

гляньте на сайт ЯПлакал, посмотрите на посещалку

Вы уверены, что знаете на чем оно крутится и как настроены бекэнды?

о высокой посещаемости можно забыть, в связи с неоправданной нагрузкой на сервер!

В сети довольно много ОЧЕНЬ посещаемых проектов на phpBB. Проблем, очевидно, не испытывают. Вывод?

[drlov]

То есть вам нужно бекэнд оптимизировать, если есть проблемы (и таки да - кеш запросов вам тут тоже поможет).

Вот как раз перевод вложений на прямые линки, я и считаю первым шагом оптимизации.
При чем планирую это сделать (если никто еще не сделал и не сообщит) в функции parse_attachments. Таким образом и механизм вложений будет целиком работать, включая редактирование и поиск потерянных вложений. Вот только при рендеринге темы в сообщения будут вставляться картинки не ссылкой через /download/file.php и id вложениями, а прямыми ссылками на реальные файлы находящиеся в папке /files/+ 'physical_filename'.
(Можно конечно приклеить еще и расширение, например .jpg, и в .htaccess его убирать, для ссылки на реальный файл)

Для начала я бы определил источник этой нагрузки. И уже от этого плясал бы. Например, если ресурсов свободных дофига, но IO-очередь заполнена, процессы будут ждать её освобождения, почем зря повышая показатели загрузки. И тут уже практически пофигу будет запускаться пхп для обработки скрипта и проверки прав или апач "напрямую побежит" к файлу - оба варианта будут ждать очереди.

Не уверен что отвечу грамотно, но могу сказть, что при увеличении коннектов к апачу, пропорционально возрастала загруженность CPU сервера.
Инфу смотрел через apstat.
....
Только что у себя глянул, запросы вида GET /forum/resources/image/10204 HTTP/1.1 по непонятной причине долго остаются в стадии "C" Closing connection. Как я гипотетически понимаю они забивают канал, неоправданно долго, забивая свободные конекты к серверу. Такс... нужно с этим разбираться, учитывая то что вчера обновил /download/file.php из последнего пакета SEO Premod. Попробую откатить и проверить.

Но, это лишний раз доказывает, то что картинки нужно отдавать стаждущим напрямую минуя всю ересь от лукавого!

Вы уверены, что знаете на чем оно крутится и как настроены бекэнды?

Уверен там и железо не из одного системника, а так же хорошая оптимизация кода, которая исключает sql+php при отдаче картинки.

В сети довольно много ОЧЕНЬ посещаемых проектов на phpBB. Проблем, очевидно, не испытывают. Вывод?

Не спорю, НО, хочу глянуть хоть на один, в котором графический материал во вложениях, несет очень большой % информации в сравнении с простым текстом.

[DK7]

Не спорю, НО, хочу глянуть хоть на один, в котором графический материал во вложениях, несет очень большой % информации в сравнении с простым текстом.

могу на двойку ссылку кинуть.

[Mr. Anderson]

я и считаю первым шагом оптимизации

Не хочу вас обидеть, но считать вы можете все, что угодно, однако, не факт, что это будет иметь отношение к реальности. И, как мы видими, так оно, собственно, и есть...

Таким образом

Расскажите планируемый алгоритм, а то "за лесом деревьев не видать" (с)

Не уверен что отвечу грамотно

Перечитываем

если ресурсов свободных дофига, но IO-очередь заполнена, процессы будут ждать её освобождения, почем зря повышая показатели загрузки

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

Но, это лишний раз доказывает, то что картинки нужно отдавать стаждущим напрямую минуя всю ересь от лукавого!

Этого это совсем не доказывает. Говорю же вам - если у вас затык в IO (а это, учитывая последний ваш пост, так и есть) и/или исчерпании количества коннектов (а это - как следствие), то хоть вы напрямую отдавайте, хоть "через крюк в сто верст", а затык никуда не денется.
Я же говорю - сначала найдите источник проблемы, а уж потом занимайтесь лечением.

Уверен

Я уверен только в том, что я не знаю людей, у которых хватит навыка и терпения оптимизировать код IPB
Ну и еще в том, что софт на сервере у них настроен "как надо". Все остальное - ни на чем не основанные домыслы.

несет очень большой %

Чтобы не придумывать мифических условий советую просто открыть big-boards.com
Узнаете много нового

[drlov]

могу на двойку ссылку кинуть.

Спасибо, было бы интересно глянуть, особенно если там много картинок и они вставлены атачами и там хорошая посещаемость и есть факт наличия хотлинкинга на их атачи.

Не хочу вас обидеть, но считать вы можете все, что угодно, однако, не факт, что это будет иметь отношение к реальности.

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

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

Расскажите планируемый алгоритм, а то "за лесом деревьев не видать" (с)

Вообще-то я описал планируемый алгоритм в прошлом посте. Не уже ли не понятна идея?? Ок... поведем искать деревья:
Есть такая функция parse_attachments, которая в отдаваемом в браузер посте, превращает атачи в реальные теги <IMG>, только вот подсовывает им в качестве SRC ссылку на file.php и id картинки из базы. Так вот я планирую в этой функции тегу <IMG> в качестве SRC подставлять реальные ссылки на файлы находящиеся в папке /files/+ 'physical_filename'.
Тем самым при загрузке топика будет выполнятся viewtopic.php , а картинки в топике будут отданы простой ссылкой на файл, плюс если кто-то захотлинкает такаю картинку, то это будет не ссылка на скрипт file.php отдающий картинку, а просто прямая ссылка на картинку.
Хоть я и не лесник, но обрисовал деревья за лесом как мог. (с)

Чтобы не придумывать мифических условий советую просто открыть big-boards.com Узнаете много нового

Спасибо за совет, но это начинает уже отдавать передергиванием...
Да там сайты с большим кол-вом постов, да я видел этот ресурс ранее, но что-то при беглом просмотре, я не заметил там большого кол-ва вложений в темах, вернее вовсе не обнаружил картинки вставленные вложениями..
Если вы Mr. Anderson вместо передергивания, а в качестве конструктива, покажите реально работающий и с высокой посещаемостью форум с большим кол-вом вложений (например piatiiugol.com), вот тогда было бы интересно.

[Nekstati]

drlov, это случайно не то?
http://www.phpbb.com/community/viewtopi ... 0&t=757785

[drlov]

drlov, это случайно не то?
http://www.phpbb.com/community/viewtopi ... 0&t=757785

Спасибо, но это не то, там так же все атачи отдаются через file.php только скрипт их может подтягивать с другого сервера по FTP.
Единственное что полезное можно взять на заметку у этого мода, это часть по аплоуду атачей на совершенно другой сервак, что снизит нагрузку с основного когда картинок станет оочень много.
Вот только все равно нужно править parse_attachments, который будет прописывать статические линки ведущии на тот сервер.

[DK7]

Спасибо, было бы интересно глянуть, особенно если там много картинок и они вставлены атачами и там хорошая посещаемость и есть факт наличия хотлинкинга на их атачи.

Картинок очень много. Около 10 гигов, и они выставлены атачами. И посещаемость хорошая. ( ну все относительно) Примерно 250-300 уникальных пользователей в сутки.
ссылка в личке.