Ну, не буду спорить, лучше напишу как-нибудь в свой блог, что я понимаю под высокой нагрузкой. Во многих случаях, просто некого больше этим нагрузить, кто бы справился. :)
Во-первых, random_index входит в стандартный набор модулей nginx, так что патчить ничего не надо. Во-вторых, мне кажутся довольно странными ваши представления о прямоте (или кривости) архитектуры.
> Может можно в nginx как-то отследить — если есть файл, то выдавать кэшированую картинку, если нет не выдавать?
Навскидку придумал следующее решение. Можно попробовать использовать встроенный интерпретатор перла. В данном случае он будет весьма к месту, тогда алгоритм примерно следующий:
— получаем запрос к файлу с картинкой;
— в perl-хэндлере вычисляем md5 от запрошенного названия файла, и делаем internal_redirect на заранее описанный location, вида /cached_files_path/just_calculated_md5.jpeg;
— в описании локейшна /cached_files_path/ описываем фоллбэк для 404, как путь к скрипту, который эти файлы генерит и отдаёт;
Это должно сработать, а, поскольку вычисление md5 — процедура с достаточно предсказуемым временем выполнения, к тому же без ввода-вывода, решение не приведёт к дополнительным тормозам. Но, возможно я что-то упустил, так что пинайте меня, если я неправ. :)
По-моему, это не совсем правильно. Я сейчас, наверное, сваливаюсь сильно в оффтопик, но я думаю, что о пользователях без javascript заботиться надо.
Во-первых, есть множество устройств, которые не полностью поддерживают JS, или имеют проблемы с его поддержкой. Во-вторых, у многих пользователей Firefox стоит расширение Noscript (что совершенно правильно, учитывая недавно обнаруженные в ветке 3.5 дыры). Кроме того, есть множество старых компьютеров, на которых JS отключен по причине низкой производительности (или используется какой-нибудь IE5, что ещё страшнее).
Конечно, в общем случае, это, даже суммарно, достаточно небольшая доля пользователей (максимум, 0,5%). Но 0,5% от 1000 человек — это пять человек, пять потенциальных покупателей вашего интернет-магазина. Почему бы не позаботиться о них, если это стоит совсем недорого… А если у вас 2-3 миллиона посетителей ежедневно?
Не надо отталкивать людей, с отключенным Javascript, вместо этого можно чуть более грамотно спроектировать своё приложение. Ведь, при правильном подходе, поддержать их не так уж и долго и сложно.
Использование Javascript — ещё одно из возможных решений. Мне кажется, что решение на стороне сервера несколько более изящно хотя бы потому, что позволяет позаботиться и о тех пользователях, у которых яваскрипт отключен (хотя их совсем немного). Тем не менее, JS-вариант тоже имеет право на существование, а, возможно, в каких-то случаях, будет даже более предпочтителен.
Разумеется, если у вас 32-гигабайтный восьмиядерный сервер под проект, с посещаемостью тысяча уников в сутки, вам можно вообще не напрягаться, и (например) даже картинки отдавать PHP-скриптом. К сожалению, с ростом нагрузки возникает потребность экономить. Экономить, в том числе на мегабайтах памяти (которые умножаются на количество запущенных процессов веб-сервера).
Отдача статики nginx в разы быстрее, чем любой скрипт на любом динамическом языке. К тому же, в описанном случае вам вообще не надо запускать интерпретатор — и вы экономите ещё мегабайт пять-пятьдесят на нём. :)
Возможно, и у меня бы заработало. :) Я не стал делать make install по двум причинам. Во-первых, модем мне дали совсем ненадолго — «на попробовать», а во-вторых, наученный горьким опытом, я очень не люблю устанавливать софт не из пакетов. Поэтому, кстати, то, что всё заработало и без make install меня, конечно, обрадовало. Ну а запустить команду dhclient wimax0 и написать в /etc/resolv.conf адрес DNS-сервера — не такая уж и большая проблема для одноразового тестирования.
Как минимум, с выхода Fedora 11. Или даже раньше. Возможно, вы не в курсе, но Fedora 11 вышла с бета-версиями Firefox и Thunderbird, поскольку релизов на тот момент просто не существовало. Естественно, пакеты обновляются со временем, так что сейчас в репозиториях лежит вполне себе актуальный FF 3.5.2 и последняя бета Thunderbird.
Да, я видел остальные статьи. Моя запись в моём блоге была предназначена, в основном, для меня же — чтобы, когда я всё-таки разорюсь на собственное подключение к Yota, не забыть как, и что там надо настраивать. :)
Очень любопытно. Я раньше слышал про эту фичу, но как-то руки и глаза не доходили документацию прочитать. Кажется, я уже даже знаю, где это можно применить, так что, спасибо.
Ну, в общем-то не очень сложно — все вышеописанные операции, включая тест скорости, заняли не более получаса. Это притом, что я раньше никогда не имел дела с WiMax модемами.
А коллега как-то не вполне рад качеству драйвера под Вистой — модем почему-то не всегда определяется сразу после включения. Опять таки, девайс новый, его поддержки «из коробки» нет, наверное, ещё ни в одной ОС, так что я даже скорее удивлён, что всё заработало без особых проблем и сразу.
Честно говоря, лениво. Никаких принципиальных мегаотличий от предыдущих версий там нет — это тот же самый старый добрый Thunderbird, чуть более удобный для использования. За это я его и люблю. :)
Извините, что задержался с ответом — ваш комментарий погрузил меня в лёгкую задумчивость на целых два дня. :)
В общем, дело в том, что, на текущий момент, почти весь дисковый ввод-вывод в Nginx — синхронный. Игорь сейчас работает над тем, чтобы переделать его на AIO, но результат может появиться ещё не скоро.
Синхронность работы с ФС, при обычной нагрузке веб-сервера, не составляет проблемы, поскольку обычно отдаётся относительно небольшое количество мелких файлов, которые прекрасно размещаются в кеше ОС, и читаются оттуда практически мгновенно. Тем более, что системные вызовы write* итак реализованы в той или иной степени асинхронно (об этом обычно заботится драйвер файловой системы).
А вот в случае нагрузки, характерной для файлового хостинга — большое количество больших файлов, которые не помещаются в кеш, и запрашиваются почти рандомно — имеет смысл создавать «по процессу на жёсткий диск» именно для того, чтобы избежать блокировок на дисковом вводе-выводе. Это не очень хорошо, но, если подумать, в этом случае тормозом, в любом случае, станет жёсткий диск, а эту проблему никаким асинхронным вводом-выводом не решить.
Кстати, системный вызов sendfile работает в большой степени синхронно. Он позволяет избежать лишнего копирования данных в адресное пространство процесса, но, не выполняет отдачи данных «совсем в фоновом режиме» (впрочем, если работать с асинхронными сокетами, ситуация, кажется, немного меняется).
Ну, собственно, в большинстве случаев, это будет довольно плохой совет. :) Хорошим он может быть только под весьма специфической нагрузкой, типа файлового хостинга.
Навскидку придумал следующее решение. Можно попробовать использовать встроенный интерпретатор перла. В данном случае он будет весьма к месту, тогда алгоритм примерно следующий:
— получаем запрос к файлу с картинкой;
— в perl-хэндлере вычисляем md5 от запрошенного названия файла, и делаем internal_redirect на заранее описанный location, вида /cached_files_path/just_calculated_md5.jpeg;
— в описании локейшна /cached_files_path/ описываем фоллбэк для 404, как путь к скрипту, который эти файлы генерит и отдаёт;
Это должно сработать, а, поскольку вычисление md5 — процедура с достаточно предсказуемым временем выполнения, к тому же без ввода-вывода, решение не приведёт к дополнительным тормозам. Но, возможно я что-то упустил, так что пинайте меня, если я неправ. :)
Во-первых, есть множество устройств, которые не полностью поддерживают JS, или имеют проблемы с его поддержкой. Во-вторых, у многих пользователей Firefox стоит расширение Noscript (что совершенно правильно, учитывая недавно обнаруженные в ветке 3.5 дыры). Кроме того, есть множество старых компьютеров, на которых JS отключен по причине низкой производительности (или используется какой-нибудь IE5, что ещё страшнее).
Конечно, в общем случае, это, даже суммарно, достаточно небольшая доля пользователей (максимум, 0,5%). Но 0,5% от 1000 человек — это пять человек, пять потенциальных покупателей вашего интернет-магазина. Почему бы не позаботиться о них, если это стоит совсем недорого… А если у вас 2-3 миллиона посетителей ежедневно?
Не надо отталкивать людей, с отключенным Javascript, вместо этого можно чуть более грамотно спроектировать своё приложение. Ведь, при правильном подходе, поддержать их не так уж и долго и сложно.
Отдача статики nginx в разы быстрее, чем любой скрипт на любом динамическом языке. К тому же, в описанном случае вам вообще не надо запускать интерпретатор — и вы экономите ещё мегабайт пять-пятьдесят на нём. :)
А коллега как-то не вполне рад качеству драйвера под Вистой — модем почему-то не всегда определяется сразу после включения. Опять таки, девайс новый, его поддержки «из коробки» нет, наверное, ещё ни в одной ОС, так что я даже скорее удивлён, что всё заработало без особых проблем и сразу.
В общем, дело в том, что, на текущий момент, почти весь дисковый ввод-вывод в Nginx — синхронный. Игорь сейчас работает над тем, чтобы переделать его на AIO, но результат может появиться ещё не скоро.
Синхронность работы с ФС, при обычной нагрузке веб-сервера, не составляет проблемы, поскольку обычно отдаётся относительно небольшое количество мелких файлов, которые прекрасно размещаются в кеше ОС, и читаются оттуда практически мгновенно. Тем более, что системные вызовы write* итак реализованы в той или иной степени асинхронно (об этом обычно заботится драйвер файловой системы).
А вот в случае нагрузки, характерной для файлового хостинга — большое количество больших файлов, которые не помещаются в кеш, и запрашиваются почти рандомно — имеет смысл создавать «по процессу на жёсткий диск» именно для того, чтобы избежать блокировок на дисковом вводе-выводе. Это не очень хорошо, но, если подумать, в этом случае тормозом, в любом случае, станет жёсткий диск, а эту проблему никаким асинхронным вводом-выводом не решить.
Кстати, системный вызов sendfile работает в большой степени синхронно. Он позволяет избежать лишнего копирования данных в адресное пространство процесса, но, не выполняет отдачи данных «совсем в фоновом режиме» (впрочем, если работать с асинхронными сокетами, ситуация, кажется, немного меняется).