Таким образом у меня будет 8 исходящих по 0,1 МБит/с.
А мне нужно 1 исходящее на 0,8 МБит/с
Что еще могу сказать:
Время кеширования достаточно. ИНтервал между первым и последним запросом к файлу - 1 мин.
Какие вижу варианты:
1. Сделать промежуточный прокси (с хранением кеша в том же месте, если это 1 физический сервер).
Но если к этому прокси будет стучаться несколько бекэндов, то тоже возможна ситуация с повторными запросами.
2. Отдавать через fastcgi_cache_lock + php
Блокировку запросов делать уже в php, если поступил второй такой запрос.
Только непонятно, что будет, если по повторному запросу отдать допустим 503 ответ.
Если бы у X-Accel-Redirect можно было задать время.
3. Отдавать через try_files + fastcgi_cache_lock + php
После скачивания ложить файл, куда нужно, и время fastcgi кеша пару секунд, чтобы не было дублирования.
Ложить файл через fastcgi_store или php.
Тоже непонятно, что будет, если по повторному запросу отдать допустим 503 ответ.
4. Отдавать через try_files + php
После скачивания ложить файл, куда нужно.
По повторному запросу отдаем заголовок 'Refresh: 3; url=http://'.$_SERVER['HTTP_HOST'].$uri
Браузер через 3 секунды придет, а файл уже будет.
(на данный момент такая схема используется в другом месте)
5. Посмотреть на встроенный в nginx lua | perl
6. Отправить багрепорт в nginx. :)
Однобайтовая кодировка - это не плохо.
А многобайтовая может быть чуть хуже из-за большего размера страницы и времени ее скачивания.
Если все нужные символы влезают в win-1251 или html-entities, то смысла переходить нету.
Циферные ссылки для более быстрого поиска в базе данных.
Также у новости может поменяться текстовый юрл, но циферный останется.
Сайты в моей тематике (онлайн ТВ) постоянно рендомизируются во всех ПС. :)
Постоянно появляются новые сайты в ТОП-10.
Любую Любую
RewriteCond %{REQUEST_FILENAME} !^/blog/.*\.html$
RewriteCond %{REQUEST_URI} !^/blog/.*\.html$
Проверял на локальном сервере, все работает...
Замена приведет к тому, что не будут обрабатываться адреса вроде:
/blog/bla-bla-bla?query_string=some.html
:)
Оно и не должно добавлять...
Оно должно давать работать старым адресам с новым движком. :)
Если Вы вообще не в теме, попросите кого-то натстроить, а то я мог бы посоветовать выполнить rm -rf из консоли :)
П.С.
RewriteRule ^blog/(.+)$ /blog/$1.html [L]
Правильно так:
RewriteEngine OnRewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !^/blog/.*\.html$RewriteRule ^blog/(.+)$ /blog/$1.html [L]
gzip_min_length 10;
Смысла в этом нет.
Достаточно
gzip_min_length 1024;
Вы точно обращаетесь к серверу localhost? :)
Пропишите а этом блоке
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { return 403;}
Если ответ будет не 403, значит эта секция не отрабатывает.
Возможно js файлы обрабатываются в других файлах.
Почему сервер localhost прописан в nginx.conf, а не в
include /etc/nginx/conf.d/*.conf;include /etc/nginx/vhosts/*/*;
Я бы делал не редирект 301, а просто реврайтил бы адреса.
Движок фигня.
П.П.С.
RewriteCond лишний.
Достаточно так:
Лучше не играться с регистрами, а все приводить в нижний регистр.
Это попахивает детством.
Также следует учитывать, что возможны конфликты имен при скачке сайта на локальный комп с виндой.
И наоборот, верблюды в именах могут быть не обработаны сервером из-за того, что прописали нижним регистром.
Если же вы сайт не будете гонять туда сюда (например он очень большой),
то для экономии для длине юрла (имени файла) для увелиения количества вариантов при неизменном длине можно использовать.
У ютуба вон юрлы регистрозависимы, хотя обычно в базе ставят _ci кодировку.
Но скрипты не рекомендовал бы называть в прыгающем варианте все равно.
