Pull to refresh

Comments 30

UFO just landed and posted this here
А если запросов — миллион, то уже нужен терабайт памяти :)
Использование Javascript — ещё одно из возможных решений. Мне кажется, что решение на стороне сервера несколько более изящно хотя бы потому, что позволяет позаботиться и о тех пользователях, у которых яваскрипт отключен (хотя их совсем немного). Тем не менее, JS-вариант тоже имеет право на существование, а, возможно, в каких-то случаях, будет даже более предпочтителен.
не хочется заботиться о пользователях, у которых яваскрипт отключен
это как не пользоваться руками, что бы не навредить себе
По-моему, это не совсем правильно. Я сейчас, наверное, сваливаюсь сильно в оффтопик, но я думаю, что о пользователях без javascript заботиться надо.

Во-первых, есть множество устройств, которые не полностью поддерживают JS, или имеют проблемы с его поддержкой. Во-вторых, у многих пользователей Firefox стоит расширение Noscript (что совершенно правильно, учитывая недавно обнаруженные в ветке 3.5 дыры). Кроме того, есть множество старых компьютеров, на которых JS отключен по причине низкой производительности (или используется какой-нибудь IE5, что ещё страшнее).

Конечно, в общем случае, это, даже суммарно, достаточно небольшая доля пользователей (максимум, 0,5%). Но 0,5% от 1000 человек — это пять человек, пять потенциальных покупателей вашего интернет-магазина. Почему бы не позаботиться о них, если это стоит совсем недорого… А если у вас 2-3 миллиона посетителей ежедневно?

Не надо отталкивать людей, с отключенным Javascript, вместо этого можно чуть более грамотно спроектировать своё приложение. Ведь, при правильном подходе, поддержать их не так уж и долго и сложно.
я не спорю, что нужно делать приложение без JS и потом для удобства навешивать его
но, если время на дрочку JS или без него, на дрочку ie6 итд во много раз превышает время обычной разработки, то ну его нах

мое мнение, не навязываю, точнее не верстать под ие6 навязываю, но это так, в плане революции от бессилия :)
Кажется, Вы никогда не работали с высоконагруженными проектами, где даже 0,5% аудитории — ощутимая цифра.
а я в данном контексте ничего не говорил про высоконагруженные проекты
в них то тем более палка о двух концах
если переложить часть расчетов на пользователя, на JS, то можно разгрузить сервер
можно шаблонизатор простенький на JS сделать, еще больше разгрузится

как сказали выше 0,5% от 1000 — это 5 человек… окупят ли эти пять человек все мозгоебство, которому подверглись кодеры или нет — вот тут нужно считать
пользователи, у которых яваскрипт отключен, должны быть отстранены от управления компьютером
Разумеется, если у вас 32-гигабайтный восьмиядерный сервер под проект, с посещаемостью тысяча уников в сутки, вам можно вообще не напрягаться, и (например) даже картинки отдавать PHP-скриптом. К сожалению, с ростом нагрузки возникает потребность экономить. Экономить, в том числе на мегабайтах памяти (которые умножаются на количество запущенных процессов веб-сервера).

Отдача статики nginx в разы быстрее, чем любой скрипт на любом динамическом языке. К тому же, в описанном случае вам вообще не надо запускать интерпретатор — и вы экономите ещё мегабайт пять-пятьдесят на нём. :)
UFO just landed and posted this here
А JS создась лишний запрос на сервер, который надо парсить и удовлетворять. ПХП и аналоги — сожрут память, время, и кроме того — их надо устанавливать.

Предлагаемое автором решение — из категории лайт, которое жжёт :)
UFO just landed and posted this here
Промах, уважаемый ;) Неважно какой запрос, нагрузку он всё равно создаёт.
UFO just landed and posted this here
Затраты могут быть немножко больше и на JS-реализацию. Для того, чтобы сделать рандомные блоки на стороне клиента, вам надо будет отдать клиенту все блоки сразу, да ещё и немного яваскрипта. Ну, или делать ещё, как минимум, один AJAX-запрос на каждую загрузку странички. Это рост числа соединений, и это трафик.

Так что, считайте, что вам дороже — чуть большие затраты CPU и памяти (на SSI), или трафика (на JS). Это не говоря уже о том, что JS может не у всех клиентов работать.
UFO just landed and posted this here
ага именно поэтому нужно использовать кривую архитектуру с пропатченым nginx. решать проблемы нагрузки ломая архитектуру подобным образом это путь камикадзе.
Во-первых, random_index входит в стандартный набор модулей nginx, так что патчить ничего не надо. Во-вторых, мне кажутся довольно странными ваши представления о прямоте (или кривости) архитектуры.
на мой взгляд это отчаянный шаг нагружать веб-сервер бизнес логикой.
Ну, не буду спорить, лучше напишу как-нибудь в свой блог, что я понимаю под высокой нагрузкой. Во многих случаях, просто некого больше этим нагрузить, кто бы справился. :)
может потому что это работает быстрее? потому как нативно. ngnx то тем и хорош — скоростью.
как я понимаю, он хорош тем, что быстро получает и быстро отдает, давая возможность апачу (если в связке с ним) не расходовать память по долгу обрабатывая все процессы.

Как-то так я это понял… сегодня первый день поставил nginx — радуюсь как ребенок :)
> Может можно в nginx как-то отследить — если есть файл, то выдавать кэшированую картинку, если нет не выдавать?

Навскидку придумал следующее решение. Можно попробовать использовать встроенный интерпретатор перла. В данном случае он будет весьма к месту, тогда алгоритм примерно следующий:

— получаем запрос к файлу с картинкой;

— в perl-хэндлере вычисляем md5 от запрошенного названия файла, и делаем internal_redirect на заранее описанный location, вида /cached_files_path/just_calculated_md5.jpeg;

— в описании локейшна /cached_files_path/ описываем фоллбэк для 404, как путь к скрипту, который эти файлы генерит и отдаёт;

Это должно сработать, а, поскольку вычисление md5 — процедура с достаточно предсказуемым временем выполнения, к тому же без ввода-вывода, решение не приведёт к дополнительным тормозам. Но, возможно я что-то упустил, так что пинайте меня, если я неправ. :)
Сенкс… значит я на верном пути :) Будем учить ))
Sign up to leave a comment.

Articles