iHead: гипертрединг - вобще-то не удваивает полноценные ядра.
иногда результат может быть близок к удвоенному, но зачастую прирост от гипертрединга где-то 1.6 раза.
Это так, но немного не в тему, т.к. производительность падает не из-за того, что есть недостаток ниток, а из-за того, что нитки используют общий кеш.
iHead:
да и необходимости нет в большом числе процесcов nginx, т.к. внутри процесса параллелизация происходит за счет событий.
нельзя ли тут поподробнее? Я плохо понимаю как может быть параллелизация в одном потоке за счет событий - если у вас куча событий стоит в очереди и ждет выполнения, то тут не параллелизация, а наоборот как раз наоборот, последовательное выполнение.
В этом кстати недостаток систем построенных по этой схеме - теряется интерактивность, если у вас выстроилась очередь из 100 сообщений, то обрабатываются эти сообщения последовательно, и пока 99 сообщений не будет обработано, 100-е будет ждать своей очереди. В отличии от многониточных систем, где каждой нитке (грубо говоря, сообщению), дается немного времени выполнения, поэтому обрабатываться сотое сообщение вполне может начаться когда обработка первого еще не закончилась.
iHead:
я бы поставил 4, у вас сервер не только ведь статику отдает, но и, наверняка, динамику генерит, БД поднята (а там везде свои потоки).
это да, надо смотреть на конкретную систему. А еще лучше вообще ничего не трогать, если все устраивает :)
да все очень просто - сколько тредов одновременно может выполняться, столько и нужно ставить.
У вас с гипертредами 24? Значит ставьте 24.
Я, правда, ставлю N + 1
На очень нагруженных системах можно выделить отдельно треды скажем для веб-сервера и отдельно для базы данных, чтобы программные треды не скакали по аппаратным. Но это на действительно очень нагруженных системах
Это все в теории естественно, на практике зависит от конкретного случая, какие компоненты у вас работают, как распределяется нагрузка по компонентам, какие требования у компонентов. Ну и добавьте сюда железо, которое не из одного проца состоит, есть же еще харды, сетевые карты, как прерывания распределены. Шаманство, в общем
Ну и старый принцип - работает нормально? Не трогай.
masterfast: Есть третий случай (клинический 😂), когда коммент без пробела и НЕ в начале строки. В этом случае хз че делать. В ручную - не вариант, нужна автоматизация, иначе крыша съедет выискивать и удалять целую кучу комментов.
In a nutshell, the policy permits scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions — but prevents access to most methods and properties across pages on different sites.
A strict separation between content provided by unrelated sites must be maintained on client side to prevent the loss of data confidentiality or integrity.
netwind: А ты возьми популярный (!) сайт для народа (!) и посчитай сколько там ящиков в доменах обслуживаемых mail.ru - их будет около 40-50%.
Хотелось бы не работать, но приходится.
тут ситуация-то немного другая, ящики принадлежат ТС, он легко может у вменяемого провайдера создать ящики и слать туда.
Параллелизация внутри nginx идет за счет создания нитей в рамках одного процесса (to iHead, почитайте на досуге в чем отличия)
хм, че-то вы тут загнули.
сцылкой не поделитесь почитать? а то быстрый гуглопоиск ниче не дает такого.
гипертрединг - вобще-то не удваивает полноценные ядра.
иногда результат может быть близок к удвоенному, но зачастую прирост от гипертрединга где-то 1.6 раза.
Это так, но немного не в тему, т.к. производительность падает не из-за того, что есть недостаток ниток, а из-за того, что нитки используют общий кеш.
да и необходимости нет в большом числе процесcов nginx, т.к. внутри процесса параллелизация происходит за счет событий.
нельзя ли тут поподробнее? Я плохо понимаю как может быть параллелизация в одном потоке за счет событий - если у вас куча событий стоит в очереди и ждет выполнения, то тут не параллелизация, а наоборот как раз наоборот, последовательное выполнение.
В этом кстати недостаток систем построенных по этой схеме - теряется интерактивность, если у вас выстроилась очередь из 100 сообщений, то обрабатываются эти сообщения последовательно, и пока 99 сообщений не будет обработано, 100-е будет ждать своей очереди. В отличии от многониточных систем, где каждой нитке (грубо говоря, сообщению), дается немного времени выполнения, поэтому обрабатываться сотое сообщение вполне может начаться когда обработка первого еще не закончилась.
я бы поставил 4, у вас сервер не только ведь статику отдает, но и, наверняка, динамику генерит, БД поднята (а там везде свои потоки).
это да, надо смотреть на конкретную систему. А еще лучше вообще ничего не трогать, если все устраивает :)
да все очень просто - сколько тредов одновременно может выполняться, столько и нужно ставить.
У вас с гипертредами 24? Значит ставьте 24.
Я, правда, ставлю N + 1
На очень нагруженных системах можно выделить отдельно треды скажем для веб-сервера и отдельно для базы данных, чтобы программные треды не скакали по аппаратным. Но это на действительно очень нагруженных системах
Это все в теории естественно, на практике зависит от конкретного случая, какие компоненты у вас работают, как распределяется нагрузка по компонентам, какие требования у компонентов. Ну и добавьте сюда железо, которое не из одного проца состоит, есть же еще харды, сетевые карты, как прерывания распределены. Шаманство, в общем
Ну и старый принцип - работает нормально? Не трогай.
В общем такой маленький вопросик.
У nginx worker_processes советуют ставить равным количеству ядер.
По спецификации проца там 4 ядра, но 8 потоков.
В данном случае что лучше ставить, 4 или 8?
8
десять символов
Есть третий случай (клинический 😂), когда коммент без пробела и НЕ в начале строки. В этом случае хз че делать. В ручную - не вариант, нужна автоматизация, иначе крыша съедет выискивать и удалять целую кучу комментов.
[^http:]//.*
Ищет // такие чтобы перед ними не было http:
это не так
ох черт, я не внимательно прочитал :(
Думал над этим, а вдруг база запорчена окажется и записей (строк) вернет больше чем одну?
легко проверить, если id - primary key, то гарантируется что больше одной не вернется
document.getElementById('targetFrame').contentWindow.targetFunction();Это если в одном домене
вот! точно! я же помню у меня не получалось!
A strict separation between content provided by unrelated sites must be maintained on client side to prevent the loss of data confidentiality or integrity.
А ты возьми популярный (!) сайт для народа (!) и посчитай сколько там ящиков в доменах обслуживаемых mail.ru - их будет около 40-50%.
Хотелось бы не работать, но приходится.
тут ситуация-то немного другая, ящики принадлежат ТС, он легко может у вменяемого провайдера создать ящики и слать туда.
достучаться до ифрейма из родителького окна нельзя.
погорячился, можно
document.getElementById('targetFrame').contentWindow.targetFunction();