LiveStreet CMS

* в теории 2.5 мб, в реальности от 8 до 56 мб, при наших 256 мб предоплаченых это важно

видимо у меня особенный воркер раз он жрет 1600к памяти

ps v 21169                                                                                  PID TTY STAT TIME MAJFL TRS DRS RSS %MEM СOMMAND                                                                                                
21169 ? S   0:25  1 637 5706 1600 0.1 nginx: worker process                                                                                

ajax-соединения с keep-alive убьют ваш воркер и вы потеряете процессорное время. ах нуда, каждый пользователь может создавать от 2 коннектов, так что 80к вы можете смело делить пополам. причем 80к — это ваши галюцинации, поскольку ядро линукса без тюнинга и патчей не позволит создать больше 65к соединений

можете дальше продолжать настраивать сервера строго по документации и мифическим 80к

мне даже спорить с вами лень.
дам подсказки:
* сколько простаивающий воркер жрет памяти?
* сколько воркер с worker_connection = max отбирает процессорного времени с учетом того, что все коннекты для этого воркера находятся в состоянии keep-alive
* сюда же, сколько воркеров остаются рабочими и сколько при этом они потребяют процессорного времени?
* сколько нужно оперативной памяти для работы mysql при 80к соединениях и будет ли играть роль прирост памяти для кэша в размере одного простаивающего воркера?

вы наркоман.
бросайте это дело и идите читать про незакрытые коннекты с кипалайвом.

про 12 вокеров на 8 на ядерных системах, аргументы в студию.

это здравый смысл, воркер не обязательно может что-либо обрабатывать. может просто висеть с нулевой загрузкой cpu. теоретически вы можете упереться в max connection.

Вы вообще в курсе что worker process 8 для nginx надо делать только на 8 ядерных системмах7

Вы вообще в курсе, что worker process можно сделать каким угодно и количество ядер — рекомендация.
Например для 8 ядерного 8 воркеров — рекомендация, а 12 например — оптимум

упс, не посмотрел дату :(

нгинкс проксирует не все, а по регуляркам и локейшенам. все что не попадает под локейшн, отдает нгинкс. в этом и проблема

около суток.

а вообще чем больше жалоб, тем негативнее относится хостер)

там ключевое слово abuse. то есть все что могло не понравиться кому-либо, может быть приравнено к нарушению прав.

Естественно, что дается время на устранение.

и серваки изымают по первому abuse

оно?
livestreetcms.ru/addons/view/7/

autosape.ru/templates/skin/developer/images/bg.png — 403 Forbidden

X-Cache	MISS from proxy
X-Cache-Lookup	MISS from proxy:8008
X-Powered-By	PHP/5.2.17

ок, добавил в описание топика расширения для chrome :)

а если так?

chrome.google.com/webstore/search/firephp?hl=ru

увеличенную копию скрина добавил по клику на картинку :)

возможно, но xdebug требует как минимум модуль под php :)

есть. например

$this->AddHook('topic_edit_before', 'TopicEditBefore', __CLASS__, приоритет);

по дефолту я знаю, что сокеты быстрее, но речь идет при больших дисковых нагрузках.

Иногда бывает так, что много процессорного времени уходит на дисковые операции, т.е. IOwait.

. Само взаимодействие тоже строго через сокет — линукс же!

сам сфинкс просто вешаем на сокет.

имею мнение, что при большом IO пользы от сокетов ненамного больше, а зачастую и меньше, чем через Loopback

маппер же. с логикой в классе.
дело не в разведении жира а в человеческой структуре.