Картинки-смайлы отдаются сервером с того же жесткого диска, с которого берет данные мускуль. Странное желание - запрячь мускуль хранить blob-ы ради того, чтобы не читать их напрямую с винчестера. Чтобы смайлы отдавать из мускуля, нужен 1) грамотный админ, 2) куча RAM (чтобы мускуль кешировал картинки в ней).
RxB, я не рассматриваю вариант с распределенным сервером (отдельные машины под фронт-энд, под БД и под дисковый массив). Вряд ли владелец такого добра задавал бы такие вопросы. Может, я дурак, тогда буду благодарен за ссылочку, где можно почитать, откуда мускуль будет брать смайлы (при условии, что RAM-кеш занят локализацией и path).
Не важно, где будут храниться смайлы, если они будут в базе, они всё равно будут отдаваться http запросом, но к соответствующему скрипту, что более накладно. Так что ваша проблема решена не будет.
Если у вас не шаред хостинг, то ставьте фронтэнд отдающий статику или переходите на php в режиме fcgi, чтобы уменьшить затраты ресурсов при раздаче статики. Если шаред, просто меняйте хостинг.
Не важно, где будут храниться смайлы, если они будут в базе, они всё равно будут отдаваться http запросом, но к соответствующему скрипту, что более накладно.
если открывается странича на которой 30 смайликов то на сервере будет примерно 5-10 httpd сессий. а если эти смайлы засунуть в CSS то гдето 1-2 httpd сессии
кстате вот модуль хороший на эту тему
http://drupal.org/project/css_emimage этот модуль помогает автоматически использовать технику CSS Data:URI, то есть включать изображения, подключаемые при помощи CSS, прямо внутрь файла. Таким образом, если ваша тема оформления использует CSS-изображения, то использование данного модуля поможет резко сократить количество HTTP-запросов к сайту, которое требуется для его загрузки.
если смайлы будут храниться в базе и они будут отдаваться каждый через httpd - то это отпадает
походу надо будет сократить количество смайлов и пихнуть их в CSS
RxB, я не рассматриваю вариант с распределенным сервером (отдельные машины под фронт-энд, под БД и под дисковый массив). Вряд ли владелец такого добра задавал бы такие вопросы. Может, я дурак, тогда буду благодарен за ссылочку, где можно почитать, откуда мускуль будет брать смайлы (при условии, что RAM-кеш занят локализацией и path).
Вы хоть что-то читали? Думаю нет, да и я вроде не писал про отдельные серванты.
В остальном думаю, это весеннее обострение premature optimazation
Если у вас свой сервер, вам просто нужен фронтэнд, например на nginx.
Который не съедая ваши ресурсы (он не форкается на каждый запрос) будет шустренько отдавать ваши смайлики(а заодно и остальную статику)с диска (точнее из кеша файловой системы на самом-то деле). И вас сразу куда меньше будет беспокоить количество http запросов.
Вы ещё удивитесь, НАСКОЛЬКО меньше ресурсов будет расходоваться.
Следующим пунктом, может стать полный отказ от apache, в пользу php-fpm например.
Описанный вами выше подход, годится для статичных элементов оформления страницы, а не для динамического контента, да и полезность его на самом деле достаточно спорна - он порождает лишние проблемы...
В общем вы решаете проблему не с того конца.
Лучше уж картинки используемые для оформления в спрайты соберите.
Спасибо за советы! У меня обычный виртуальный хостинг :} там ограничение на число запущенных процессов от имени пользователя - 32 процесса (мало) httpd поднимаются и всё,, сайта не видно
логи копал и увидел как блок со смайлами загружается,, это ppc httpd процессы взлетают в небо)) со временем перейду на новый уровень VDS, или сервер ^_^ сейчас пока в оптимизатора поиграюсь,, полезное занятие, много интересного узнаю
со смайлами решил пока так. убрать побольше лишних самайлов. потом основные смайлы,, штучек 5 засуну в CSS а другие мало используемые будут грузится с другого хостинга Да и сам CSS переберу сейчас
и такой :} как раз то что нужно IMG! оказывается можно картинки пихать не только в CSS,,, вот я неуч проблема решена на %200 думаю многим это будет полезно
30 смайлов на страницу - это ничто. В друпале есть другие места, где нужно оптимизировать.
ТС, упрощайте, не усложняйте
продвигаюсь по всем фронтам добрался до графики
хостинг такой у меня
ограничение на число запущенных процессов от имени пользователя: 32 процесса
на хостинге 3 сайта, один из них drupal. посещаемость в сумме 400-500 в день
каждый сайт сейчас ковыряю
загрузите эти 30 смайлов и посмотрите в SSH консоле (команда "ps") сколько там httpd сессий вообще каждая httpd сессия мозг жрет хорошо (на форумах начитался)
Комментарии
омг
омг омг)
Картинки-смайлы отдаются сервером с того же жесткого диска, с которого берет данные мускуль. Странное желание - запрячь мускуль хранить blob-ы ради того, чтобы не читать их напрямую с винчестера. Чтобы смайлы отдавать из мускуля, нужен 1) грамотный админ, 2) куча RAM (чтобы мускуль кешировал картинки в ней).
Далеко не факт
RxB, я не рассматриваю вариант с распределенным сервером (отдельные машины под фронт-энд, под БД и под дисковый массив). Вряд ли владелец такого добра задавал бы такие вопросы. Может, я дурак, тогда буду благодарен за ссылочку, где можно почитать, откуда мускуль будет брать смайлы (при условии, что RAM-кеш занят локализацией и path).
это понятно что с жесткого диска они отдаваться будут =)просто нужно обойти httpd сессии
не думаю что кучи RAM потребуется, смайлы не очень много весят
наверное лучше самайлы запихать в CSS
ps. на этом форуме смайлы отключены
Может они тупо не нужны тут?
Голый апач на серванте верх извращения, был бы у вас тот nginx фронтэндом, то скорее всего не возникало бы таких вопросов
Не важно, где будут храниться смайлы, если они будут в базе, они всё равно будут отдаваться http запросом, но к соответствующему скрипту, что более накладно. Так что ваша проблема решена не будет.
Если у вас не шаред хостинг, то ставьте фронтэнд отдающий статику или переходите на php в режиме fcgi, чтобы уменьшить затраты ресурсов при раздаче статики. Если шаред, просто меняйте хостинг.
если открывается странича на которой 30 смайликов то на сервере будет примерно 5-10 httpd сессий. а если эти смайлы засунуть в CSS то гдето 1-2 httpd сессии
кстате вот модуль хороший на эту тему
http://drupal.org/project/css_emimage
этот модуль помогает автоматически использовать технику CSS Data:URI, то есть включать изображения, подключаемые при помощи CSS, прямо внутрь файла. Таким образом, если ваша тема оформления использует CSS-изображения, то использование данного модуля поможет резко сократить количество HTTP-запросов к сайту, которое требуется для его загрузки.
если смайлы будут храниться в базе и они будут отдаваться каждый через httpd - то это отпадает
походу надо будет сократить количество смайлов и пихнуть их в CSS
Вы хоть что-то читали? Думаю нет, да и я вроде не писал про отдельные серванты.
В остальном думаю, это весеннее обострение premature optimazation
Если у вас свой сервер, вам просто нужен фронтэнд, например на nginx.
Который не съедая ваши ресурсы (он не форкается на каждый запрос) будет шустренько отдавать ваши смайлики(а заодно и остальную статику)с диска (точнее из кеша файловой системы на самом-то деле). И вас сразу куда меньше будет беспокоить количество http запросов.
Вы ещё удивитесь, НАСКОЛЬКО меньше ресурсов будет расходоваться.
Следующим пунктом, может стать полный отказ от apache, в пользу php-fpm например.
Описанный вами выше подход, годится для статичных элементов оформления страницы, а не для динамического контента, да и полезность его на самом деле достаточно спорна - он порождает лишние проблемы...
В общем вы решаете проблему не с того конца.
Лучше уж картинки используемые для оформления в спрайты соберите.
Вот проблемы у людей...ставить выделенный сервер или нет ради смайлов...
to bsyomov:
Спасибо за советы! У меня обычный виртуальный хостинг :} там ограничение на число запущенных процессов от имени пользователя - 32 процесса (мало) httpd поднимаются и всё,, сайта не видно
логи копал и увидел как блок со смайлами загружается,, это ppc httpd процессы взлетают в небо)) со временем перейду на новый уровень VDS, или сервер ^_^ сейчас пока в оптимизатора поиграюсь,, полезное занятие, много интересного узнаю
со смайлами решил пока так. убрать побольше лишних самайлов. потом основные смайлы,, штучек 5 засуну в CSS а другие мало используемые будут грузится с другого хостинга Да и сам CSS переберу сейчас
свой сайт проспамлю its0ft.ru
мне ещё на хостинге посоветовали: чтобы не плодить лишних httpd процессов нужно пути к картинкам прописывать так
img scr="image/smile.gif...
а не
img scr="http://сайт/image/smile.gif...
это бред?
для уменьшения html кода конечно гуд
бред и тема бред. сделайте смайлики спанами, например и спрайтами доблбите графику в CSS. типа:
<span class="smile-2" />
<span class="smile-3" />
<span class="smile-4" />
и т.д. ну и преобразования с BB сделть на проблема, как и кнопки на редактор
сервис хороший нашел
http://websemantics.co.uk/online_tools/image_to_data_uri_convertor/
приабразует фотки в такой вид для CSS
{
width: 997px;
height: 147px;
background-repeat: no-repeat;
background-image: url(data:image/gif;base64,R0lGODlh5QOTAOb/AP/////+///9/v78/f39/f37/Pz6+/v7+/v5+vr4+fn6+fn3+Pf29/Xz9PPx8vHv8PDu7+7u7uvq6+no6ejm5+f9euLh4d3d3druc9rY2dLR0c3gbc3LzMvLy8jHyMfGx8PCw8DSZ769vLiw8IuHMNysxQBAQA7);
}
и такой :} как раз то что нужно IMG! оказывается можно картинки пихать не только в CSS,,, вот я неуч проблема решена на %200 думаю многим это будет полезно
img width="997" height="147" title="" alt="" src="data:image/gif;base64,R0lGODlh5QOTAOb/AP/////+///9/v78/f39/f37/Pz6+/v7+/v5+vr4+fn6+fn3+Pf29/Xz9PPx8vHv8PDu7+7u7uvq6+noNysxQBAQA7" /
30 смайлов на страницу - это ничто. В друпале есть другие места, где нужно оптимизировать.
ТС, упрощайте, не усложняйте
продвигаюсь по всем фронтам добрался до графики
хостинг такой у меня
ограничение на число запущенных процессов от имени пользователя: 32 процесса
на хостинге 3 сайта, один из них drupal. посещаемость в сумме 400-500 в день
каждый сайт сейчас ковыряю
загрузите эти 30 смайлов и посмотрите в SSH консоле (команда "ps") сколько там httpd сессий вообще каждая httpd сессия мозг жрет хорошо (на форумах начитался)
Вообще, я бы начал с того, что у ТС крайне интересный хостинг
пройдёт через пол года
Проблема решилась сменой хостинга но вся эта оптимизация пригодилась