Туда же до кучи «То же относится к запросам части ответа byte-ranges и к запросам FLV не с начала файла: чтение невыровненных начала и конца ответа будет блокирующимся.»
Заметят. Всего-то нужно каждому воркеру уйти в блокирующее чтение пусть даже 512ти байт — запросы приниматься и обрабатываться в это время не будут.
проект звучит слишком гордо, не было никакого «проекта», заложенной масштабируемости и прочих модных слов, зато есть load average под 40 и полное непонимание чего там где и как жрёт ресурсы… ну и деньги на второй сервер, да и на 3ий думаю найдут :)
прямо сейчас, кстати, наблюдаю обратную ситуацию — люди вместо оптимизации берут второй сервер — но у них типа рост и оптимизацией заниматься особо некогда, наращивают функциональность :)
про доказано «От сжатия я также отказался, т.к. доказано выйгрыш в скорости загрузки файла теряется в скорости его распаковки» можно привести источники? И, кстати, подправьте «выйгрыш»
Заметят. Всего-то нужно каждому воркеру уйти в блокирующее чтение пусть даже 512ти байт — запросы приниматься и обрабатываться в это время не будут.
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 250
vm.dirty_expire_centisecs = 3000
это призвано сделать что?
как эксперат в майском фуршете
наверное «как эксперта»?
Собственно купил core quad чтоб гамацца в супком — на старом компе p4 prescott — тормозили именно юниты, видяха справлялась легко.
syntax: gzip_disable regex [regex ...]
default: нет
context: http, server, location
Директива (0.6.23) запрещает сжатие ответа методом gzip для запросов со строками «User-Agent», совпадающими с заданными регулярными выражениями.
Специальная маска «msie6» (0.7.12) соответствует регулярному выражению «MSIE [4-6]\.», но работает быстрее.