Next Generation CMS :: Форум поддержки

А для чего это?

infinity237, там даже обязательное подтверждение email'а стоит.
Народ ручками постит, а тут уже капча ничем не поможет.

RocketBoy, сложный вопрос, т.к. свёрстанного варианта пока ещё нет и, возможно, в процессе реализации что-то будет переделываться.

Хм.. принудительная проверка e-mail адреса не помогает... ладно, будем более другими методами бороться

v01d, посмотрел общее кол-во хитов-запросов к web серверу (по access log'у) у того сайтика ( uz-translations.net ) - получается 580 тысяч запросов в сутки.
Что даёт 7 запросов в секунду в среднем или до 15 запросов в секунду в ЧНН.
Для варианта "только apache" потребуется как минимум 45 worker'ов (а лучше - 60), что в нашей конфигруации потребует от 45*25 = 1125 mb до 60*25 = 1500 mb.

v01d, очень советую почитать что же такое NGINX.
Если вкратце - тот факт, что ты очень часто видишь отказы nginx (а точнее - что-то вроде: "не могу подключиться к backend" серверу), это не показатель того, что nginx плох. Это показатель того, что его используют на серьёзно нагруженных серверах. И не всегда сервера в состоянии справиться с нагрузкой.

NGINX используется для отдачи статического контента и для проксирования запросов к backend'ам (в их качестве может стоять либо старый добрый apache, либо fastcgi,.. либо что угодно включая даже IIS).

На примере uztranslations'а:
- без использования nginx'а ему требовалось для нормальной работы с ~30k хитами в сутки (это 30k хитов в сутки, но для каждой страницы грузится ещё 10+ картинок, т.е. апачу приходилось обрабатывать 300+k хитов) не менее 10 worker процессов apache'а, каждый из которых кушает 25mb оперативки. Итого сайт более менее стабильно работал (иногда были отказы) потребляя 250 mb RAM.
- с nginx'ом при ~50k хитах в сутки (при этом 50*10+ = 500+k хитов статических картинок отдаёт nginx, причём отдаёт без дополнительных затрат CPU и значительно быстрее апача) и при почти нулевом кол-ве отказов хватает всего 4х worker процессов (100 mb RAM).

Ах да, на обслуживание всего сервера работает ещё 4 worker процесса nginx с общим потреблением в 12 mb RAM. Для оптимизации им можно добавить оперативки и увеличить их кол-во, тогда потребление может достигнуть 30 mb RAM, но сейчас в этом нет необходимости.
Кстати, я совершенно не уверен, что без nginx'а этот сервер смог бы справиться даже с одним только uz-translations'ом - у него всего 2 Gb RAM, чего достаточно для запуска всего 80 worker'ов apache'а (+сама ОС, кеширование, ну и mySQL).

Чем же так хорошо nginx?
Да тем, что он многопоточный и один воркер может одновременно обрабатывать десятки или даже сотни одновременных запросов.
А апач - только один (в prefork режиме. thread'овый же режим работы всё ещё очень не советуют использовать совместно с php).

А теперь представь - зашло к тебе 20 человек с модемным подключением и каждый качает файл на 10 мегабайт,.. да ещё этот файл в 10 потоках качают.... время скачивания каждым пользователем - 30 минут.
Итого в течении 30 минут у тебя может быть занято:
1. 20*10 = 200 worker процессов апача. Если считать, что каждый процесс кушает по 10mb ram, то это 2Gb RAM
2. 1 worker nginx (3 mb и то частично); если же контент генерится динамически (или выдаётся через скрипт-считалку), то будет ещё 200 запросов к worker'у апача, и в случае быстрой генерации контента справиться может 1 worker (но на всякий случай мы выделим 3 штуки) = 3 * 10 = 30.

Итого на самом обыкновенном сайте использование nginx позволяет сэкономить очень много RAM'а и некоторое кол-во CPU (т.к. запуск каждого worker'а apache тоже требует определённое время).

p.s. Естественно, nginx не один такой. Подобных серверов существует 3 или 4 штуки. Просто так сложилось, что в exUSSR самым известным стал именно nginx.

p.s. Ну и естественно, nginx - это решение для некрупных систем.
Те, кто для обслуживания своих сайтов ставит 1 или более стоек - используют аппаратные и значительно более надёжные решения.
Наиболее распространённый вариант - пара (для резервирования) Cisco Content Switch'ей (CSS 11xxx), по цене 300-600 т.р. (в зависимости от комплектации) за штуку.

sparco, а ты отключи JScript'ы и посмотри что будет с этим меню (подсказка - ничего не будет, меню вообще не появится).

По условиям задачи меню должно отображаться даже в случае отключения JScript'ов, поэтому оно должно отрисовываться через HTML. И DTree тут не подходит (хотя он мне тоже нравится).

Выложена (в начале темы) версия плагина 0.02, в ней исправлена найденная ошибка.

Наверное, поможет iconv. Или конвертер UTF8 => win1251, идущий в составе движка.

При постинге комментариев браузер передаёт запрос через AJAX именно в UTF8 кодировке, а двиг уже делает преобразование.

RocketBoy, у тебя какая версия двига?
Судя по тому, что я вижу - у тебя не отображаются языковые файлы от плагина.
Такая ситуация возможна в Release Candidate.

Попробуй обновить двиг до самой последней, выложенной на форуме.
Проблемы должны будут решиться после этого.

RocketBoy, я не могу воспроизвести проблему. У меня работает.
Стукнись в аську.

p.s. Точно после создания первого поля ты его сначала переименовываешь, а после этого - создаёшь следующее?

graf, спасибо за предложение.
Рисовал и верстал d7p4x, свёрстанно очень качественно. Так что оптимизация не потребуется.