[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Клиентская оптимизаци (высонагружаемый проект)
VELIK505
У проекта посещаемость более 40 000 уников в сутки. Стоит на 1 сервере 6 ядер 12 гиг оперативы.

Надо разнести статику по поддоменам.
Как сделать лучше.
допустим на img.site.ru сгрузить в корень все картинки и css

И подключать допустим CSS.
<link rel="stylesheet" type="text/css" href="http://img.site.ru/css.css">

Тут мы берём короткий путь для браузеров который быстрее они прочитают и подгрузят css ник и соответственно в Css нике уже будут пути к изображениям (bp.png) за вместо (./bp.png) и тд что тоже быстрее браузер вытащит.

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

Или лучше сделать на поддомене img так же разбить всё по папкам (не из корня подключать) images css и тут выборка будет идти побыстрее на наносекунды но и урлы увеличиваться будут и возвращение на дирректории назад.

2 вопрос.
Много читал про ob_start("compress"); - + написание своих регулярок и средствами php браузеру уже будет отдаваться 1 строчный HTML без пробелов и отступов. (Кто не знает что такое можно заглянуть в исходник гугла или яндекса)

Так тут имеем допустим такую архитектурку:
<?php
if(isset($_GET["str"])){$str = $_GET["str"];}else{$str = "index";}
switch ($str) {
case('index'): include('s/index.pag'); break;
case('lalal'): include('s/niceserf.pag'); break;
case('lalagaga'): include('s/news.pag); break;
case('
error404): include('s/404.pag'); break;
default: include('s/404.pag); break;
}
?>


Правильно ли загнать всё в упаковщика таким образом:
<?php
ob_start("compress");
function compress($buffer)
{

/* удалить табуляции, пробелы, символы новой строки и т.д. */
$search = array ("'\r'", "'\n'", "'([\r\n])[\s]+'", "'\t'","'>(\s+)
<'"
);
$replace = array ("", "", "\\1", "", "><");
$buffer = preg_replace($search, $replace, $buffer);

return $buffer;
}
if(isset($_GET["str"])){$str = $_GET["str"];}else{$str = "index";}
switch ($str) {
case('index'): include('s/index.pag'); break;
case('lalal'): include('s/niceserf.pag'); break;
case('lalagaga'): include('s/news.pag); break;
case('
error404): include('s/404.pag'); break;
default: include('s/404.pag); break;
}
ob_end_flush();
?>


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



Спустя 4 часа, 42 минуты, 31 секунда (14.07.2011 - 01:36) Nikitian написал(а):
У вас задача снизить нагрузку на сервер или только клиентская оптимизация? Если первое, то клиентская оптимизация тут мало чем поможет, если второе, то о нагрузке на сервер можете не думать.
По оптимизации нагрузки на сервер - ищите узкие места. Уверен, что не в пробелах и переносах дело. Если у вас gzip (а у вас же включен gzip для статики и динамики, иначе вообще неясна логика ваших действий), то эти пробелы-переносы роли практически не играют, алгоритм gzip весьма грамотно их сжимает.

По клиентской оптимизации: объединяйте ресурсы: 1 js, 1 css, css-sprites. Как альтернатива объединению js, можно использовать headjs - мне очень понравилось, жаль с yandex-map не состыкуются из-за устаревшего jquery в последних sad.gif Ставьте кэширование для статики максимальное, раскидывайте по cdn что можно (например)

По поводу вашего кода, пользуюсь этим - в шаблонах не стесняюсь в комментариях, даже если шаблоны не smarty и не поддерживают свой синтаксис комментов. Но другого предназначения для вырезания пробелов-переносов не вижу. Ваш код как минимум не аккуратен к textarea, input[type="text"], pre, code тегам, а точнее к их содержимому.

Спустя 4 часа, 45 минут, 27 секунд (14.07.2011 - 06:22) VELIK505 написал(а):
Спасибо.
CSS спрайтами уже зарубил кучу иконок и мини картинок=)
А как насчёт сведения обращений к серверу к минимуму, совмещая Js и СSS в 1 файл и 1 подключение вызывать.
<script type="text/javascript" src="lala.jscss#2"></script>

Это есть хорошо?

Спустя 1 час, 19 минут, 1 секунда (14.07.2011 - 07:41) Семён написал(а):
Скачай библиотеку minify и радуйся жизни!

Спустя 1 час, 50 минут (14.07.2011 - 09:31) kirik написал(а):
По первому вопросу - если в папке будет не много файлов (а стилей/скриптов/картинок в любом случае больше сотни не наберётся), то можно в одну папку складывать всё. Если же файлов много (допустим более 5к), то стоит задуматься о подпапках.
По второму вопросу - результат работы скрипта нужно кэшировать в файл и отдавать вебсервером.

ИМХО есть всего 2 очень важные вещи, которые нужно делать для уменьшения траффика и количества запросов:
- агрессивное кэширование всего-чего-только-можно браузером (при помощи отправки соответствующих заголовков + пара костылей)
- и агрессивное кэшировение всего что (почти)статично на стороне сервера и отдача этого контента быстрым вебсервером с включенным сжатием
Всё остальное - мизер, на который можно забить. Особенно на вырезание пробелов из html/css/js smile.gif
Когда будет под миллион запросов в сутки, тогда будет смысл в дальнейшей оптимизации.

Спустя 47 минут, 25 секунд (14.07.2011 - 10:18) VELIK505 написал(а):
Цитата (kirik @ 14.07.2011 - 06:31)
По первому вопросу - если в папке будет не много файлов (а стилей/скриптов/картинок в любом случае больше сотни не наберётся), то можно в одну папку складывать всё. Если же файлов много (допустим более 5к), то стоит задуматься о подпапках.
По второму вопросу - результат работы скрипта нужно кэшировать в файл и отдавать вебсервером.

ИМХО есть всего 2 очень важные вещи, которые нужно делать для уменьшения траффика и количества запросов:
- агрессивное кэширование всего-чего-только-можно браузером (при помощи отправки соответствующих заголовков + пара костылей)
- и агрессивное кэшировение всего что (почти)статично на стороне сервера и отдача этого контента быстрым вебсервером с включенным сжатием
Всё остальное - мизер, на который можно забить. Особенно на вырезание пробелов из html/css/js smile.gif
Когда будет под миллион запросов в сутки, тогда будет смысл в дальнейшей оптимизации.

Спасибо. В особенности за По второму вопросу - результат работы скрипта нужно кэшировать в файл и отдавать вебсервером.
Ещё хочу спросить на сервере используеться связка apache+nginx+gzip.
Если поставить XCache и выделить ему 128 метров оперативы будет ли эффект?
Много читал про него но так и не ставил не разу. Я как понял его ставишь через ssh и всё ну и админку ещё закинуть.

Спустя 4 часа, 53 минуты, 9 секунд (14.07.2011 - 15:11) Nikitian написал(а):
Агрессивное кэширование в файлы можно заменить кэшированием в память данных (не сформированных страниц!). Например xcache, memcache(d)... Это позволит гибко управлять выдачей каждому пользователю нужных данных и разгрузите винчестер, который является достаточно узким местом.

Спустя 2 дня, 6 часов, 15 минут, 5 секунд (16.07.2011 - 21:26) kirik написал(а):
Цитата (VELIK505 @ 14.07.2011 - 03:18)
apache+nginx+gzip

ИМХО php-fpm в такой связке выгоднее выглядит.

Цитата (Nikitian @ 14.07.2011 - 08:11)
Агрессивное кэширование в файлы можно заменить кэшированием в память данных (не сформированных страниц!). Например xcache, memcache(d)... Это позволит гибко управлять выдачей каждому пользователю нужных данных и разгрузите винчестер, который является достаточно узким местом.

Вебсервер и так будет держать часто запрашиваемые файлы в памяти, а пара десятков файлов для "дизайна" на диске погоды не сделают.
Но есть вариант когда юзеру даётся возможность менять дизайн своей странички.. тогда конечно кэшируем в key-value DB.

Спустя 36 минут, 59 секунд (16.07.2011 - 22:03) Nikitian написал(а):
Цитата (kirik @ 16.07.2011 - 21:26)
Вебсервер и так будет держать часто запрашиваемые файлы в памяти, а пара десятков файлов для "дизайна" на диске погоды не сделают.
Но есть вариант когда юзеру даётся возможность менять дизайн своей странички.. тогда конечно кэшируем в key-value DB.

Если только речь идёт про информационный сайт. Если же есть пользователи, авторизация, кастомизация контента под посетителей.. Можно конечно извращаться с ssi-подключением блоков, но это ни раз уне наглядно и сильно завязано на платформу.

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

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.