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

vadim008, ты уже не первый с этой проблемой
Некоторые FTP клиенты при заливке файлов автоматически переводят их имена в нижний регистр.
Добавлю в инсталлер проверку на наличие подобной подставы от FTP клиента.

t3s, хороший пример можно найти в engine/actions/news.php
В SVN версии найди строку 824 и обрати внимание на:

	$newsEntries = array();
	foreach ($mysql->select($sqlResult) as $row) {
		$newsEntry = array(...тут заполнение);
		....
		$newsEntries []= $newsEntry;

	}
...
	$tVars = array(
		'entries'		=>	$newsEntries,
		...
		'flags'			=> array(
			'comments'		=> getPluginStatusInstalled('comments')?true:false,
			'allow_modify'	=> ($userROW['status'] <= 2)?true:false,
		),
	);

Т.е. ты создаёшь массив записей и с ними уже работает TWIG.

А вот шаблон:

...
{% for entry in entries %}
<tr align="left" >
	<td width="30" class="contentEntry1">{{ entry.newsid }}</td>
	<td width="60" class="contentEntry1">{{ entry.itemdate }}</td>
	<td width="48" class="contentEntry1" cellspacing=0 cellpadding=0 style="padding:0; margin:0;" nowrap>
...
{% else %}
<tr><td colspan="6"><p>- {{ lang.editnews['not_found'] }} -</p></td></tr>
{% endfor %}
...

Выполнить запрос:

update ng_users set pass=md5(md5('123')) where id = 1

с его помощью ты установишь пароль '123' для юзера с ID = 1 (обычно это и есть админ)

Нет, без правки шаблона не получится.

Проще при неправильной капче заново отображать эту же форму (с заполненными полями).

Так я ж потом указывал, что всё можно сделать через стандартное меню категорий.
А про "кол-во постов за сутки" никто и не говорил..

1. Индексация слов из текста
2. Возможность искать с учётом корней слов (в поиске ввёл "собака", а нашлись статьи в которых есть "собак" и "собаки")
3. Поиск на основе индекса, а не полным сканированием всех новостей (как делает mysql при поиске через like)

legenda, на текущий момент это - штатное поведение для плагина xfields при использовании полей типа "группа изображений".

Это ~200 хитов в минуту.

По поводу оптимизации и всего остального - это уже работа для системного администратора.
Проанализировать логи, посмотреть средний профиль запросов, выполнить тонкую настройку mysql, web сервера и так далее.
К примеру, некоторые страницы можно кешировать средствами nginx'а, это может дать (а может и не дать - нужно чётко понимать требования) значительный прирост в производительности.

Будет желание - обращайся. Но ценник начинается от $100 (зависит от требований).
Как вариант - можешь найти исполнителей на такую задачу на сайтах фрилансеров.

legenda, посмотри сам на логи.
Обрати внимание, что тормоза происходят в самые непредсказуемые моменты.

В такой ситуации мы тебе ничем не поможем, тут одно из двух:
1. Кол-во посетителей превышает возможности сервера
2. У хостера серьёзные проблемы с нагрузкой на систему (ты же не один на этом сервере живёшь)

Я склоняюсь к первому варианту.
Я ведь всё правильно помню, сайт - sportanalytic.com ?

Вот для примера результаты проверки скорости работы твоего сайта.
* 30 запросов в 1 поток:

Concurrency Level:      1
Time taken for tests:   23.003 seconds
Complete requests:      30
Failed requests:        0
Write errors:           0
Total transferred:      6007020 bytes
HTML transferred:       5994870 bytes
Requests per second:    1.30 [#/sec] (mean)
Time per request:       766.759 [ms] (mean)
Time per request:       766.759 [ms] (mean, across all concurrent requests)
Transfer rate:          255.02 [Kbytes/sec] received

* 30 запросов в 2 потока:

Concurrency Level:      2
Time taken for tests:   16.312 seconds
Complete requests:      30
Failed requests:        2
   (Connect: 0, Receive: 0, Length: 2, Exceptions: 0)
Write errors:           0
Total transferred:      6007018 bytes
HTML transferred:       5994868 bytes
Requests per second:    1.84 [#/sec] (mean)
Time per request:       1087.499 [ms] (mean)
Time per request:       543.750 [ms] (mean, across all concurrent requests)
Transfer rate:          359.62 [Kbytes/sec] received

* 30 запросов в 3 потока:

Concurrency Level:      3
Time taken for tests:   12.068 seconds
Complete requests:      30
Failed requests:        2
   (Connect: 0, Receive: 0, Length: 2, Exceptions: 0)
Write errors:           0
Total transferred:      6205693 bytes
HTML transferred:       6193138 bytes
Requests per second:    2.49 [#/sec] (mean)
Time per request:       1206.825 [ms] (mean)
Time per request:       402.275 [ms] (mean, across all concurrent requests)
Transfer rate:          502.16 [Kbytes/sec] received

Обрати внимание, даже при 3х одновременных запросах (на главную страницу) время генерации страницы составляет 1.2 сек.
3 одновременных потока и время генерации 1.5 секунды дадут нам производительность в 1.5/3 = 0.5 req/sec => 172k (теоретических) и ~70k (практических с учётом неравномерности нагрузки в разное время суток) хитов в сутки.

А теперь - смертельный номер, делаем 10 одновременных запросов:

Concurrency Level:      10
Time taken for tests:   9.645 seconds
Complete requests:      30
Failed requests:        2
   (Connect: 0, Receive: 0, Length: 2, Exceptions: 0)
Write errors:           0
Total transferred:      6004978 bytes
HTML transferred:       5992828 bytes
Requests per second:    3.11 [#/sec] (mean)
Time per request:       3215.132 [ms] (mean)
Time per request:       321.513 [ms] (mean, across all concurrent requests)
Transfer rate:          607.98 [Kbytes/sec] received

... странно, смерть не наступила. Ну да ладно.
Заметь, теперь на генерацию страницы уходит уже 3.2 секунды (одновременно сервер получает по 10 запросов !!)

Идём дальше - 20 одновременных запросов, общее кол-во - 100 штук:

Concurrency Level:      20
Time taken for tests:   28.831 seconds
Complete requests:      100
Failed requests:        9
   (Connect: 0, Receive: 0, Length: 9, Exceptions: 0)
Write errors:           0
Total transferred:      20016587 bytes
HTML transferred:       19976087 bytes
Requests per second:    3.47 [#/sec] (mean)
Time per request:       5766.234 [ms] (mean)
Time per request:       288.312 [ms] (mean, across all concurrent requests)
Transfer rate:          678.00 [Kbytes/sec] received

Время генерации - 5.7sec/запрос (в одном потоке).

Продолжаем DOS'ить сайт - 40 одновременных запросов,  всего 100 штук:

Concurrency Level:      40
Time taken for tests:   26.310 seconds
Complete requests:      100
Failed requests:        26
   (Connect: 0, Receive: 0, Length: 26, Exceptions: 0)
Write errors:           0
Total transferred:      20016605 bytes
HTML transferred:       19976105 bytes
Requests per second:    3.80 [#/sec] (mean)
Time per request:       10524.014 [ms] (mean)
Time per request:       263.100 [ms] (mean, across all concurrent requests)
Transfer rate:          742.97 [Kbytes/sec] received

При 40 одновременных запросах время генерации страницы составило уже 10.5 секунд.... для посетителей это уже совсем плохо, но до твоих цифр (под 60+ секунд) мы пока не добрались.

Увеличиваем нагрузку - 500 запросов в 60 одновременных сессиях (уже явная DOS атака):

Concurrency Level:      60
Time taken for tests:   149.762 seconds
Complete requests:      500
Failed requests:        418
   (Connect: 0, Receive: 0, Length: 418, Exceptions: 0)
Write errors:           0
Total transferred:      100080882 bytes
HTML transferred:       99878382 bytes
Requests per second:    3.34 [#/sec] (mean)
Time per request:       17971.388 [ms] (mean)
Time per request:       299.523 [ms] (mean, across all concurrent requests)
Transfer rate:          652.61 [Kbytes/sec] received

Ура, мы уже добрались до 17 секунд на генерацию страницы. Правда добрались под явным DOS'ом... при этом среднее время генерации страницы (с учётом одновременных потоков) получается 300ms, т.е. в пике в час ты можешь отдать до 12 тысяч хитов.

Но и в этой ситуации мы так и не увидели твоих 80+ секунд... что же делать?
Раз уж пошла такая пьянка, то давай отправим 1000 запросов в 150 одновременных сессий...

Concurrency Level:      150
Time taken for tests:   288.442 seconds
Complete requests:      1000
Failed requests:        904
   (Connect: 0, Receive: 0, Length: 904, Exceptions: 0)
Write errors:           0
Non-2xx responses:      7
Total transferred:      198798784 bytes
HTML transferred:       198395108 bytes
Requests per second:    3.47 [#/sec] (mean)
Time per request:       43266.315 [ms] (mean)
Time per request:       288.442 [ms] (mean, across all concurrent requests)
Transfer rate:          673.06 [Kbytes/sec] received

Ура, мы добились этого!
Время генерации 43 секунды... но постойте, такое время получилось при 150 одновременных запросах!!!
Т.е. за 280 секунд (4.5 минуты) ты выдал 1000 хитов, что даёт ~13k хитов в час.
Как ты видишь, цифра (максимальная производительность) на 150 одновременных запросах очень близка к цифре, полученной и на 60 одновременных запросах..

Мой вывод:
1. У сайта нет проблем с производительностью, цифры в 15-30-60-90 секунд выдаются из-за бешенного кол-ва одновременных запросов к серверу, сервер физически не может справиться с таким потоком. Обращать внимания на эти цифры нет никакого смысла, у тебя же не 100 ядерный процессор и ты сам должен понимать, что увеличение одновременного кол-ва запросов в 2 раза ведёт к замедлению работы всех одновременных скриптов в те же 2 (и даже больше) раз. Кстати, у твоего сервера (судя по результатам) - всего 2-3 ядра.
2. Пиковая оптимальная производительность твоего сервера (с твоей конфигурацией плагинов) составляет 2.5 запроса в секунду.
3. Пиковая допустимая производительность составляет 2.8-2.9 запросов в секунду. Всё что выше - ведёт у показанным тобой (и мной) примерам.
4. Если хочешь, чтобы сайт работал быстрее, то на выбор:
4.1. Ставь более мощный сервер (отчасти может спасти вынос mySQL на отдельный сервер (может дать прирост до 40+%), кое-что даст оптимизация настроек mySQL...)
4.2. Отключай всякие ресурсоёмкие плагины

Кстати, для сравнения - вот результаты отправки 1000 запросов в 30 сессиях на сайт (работает на NG), получающий 2 ядра от Core2Quad Q9550:

Concurrency Level:      30
Time taken for tests:   144.562 seconds
Complete requests:      1000
Failed requests:        624
   (Connect: 0, Receive: 0, Length: 624, Exceptions: 0)
Write errors:           0
Total transferred:      95647694 bytes
HTML transferred:       95337694 bytes
Requests per second:    6.92 [#/sec] (mean)
Time per request:       4336.868 [ms] (mean)
Time per request:       144.562 [ms] (mean, across all concurrent requests)
Transfer rate:          646.13 [Kbytes/sec] received

ему требуется 150-160ms на генерацию страницы, что даёт оптимальную нагрузку в 6 запросов в секунду.
Если сайт получит все 4 ядра, то сможет отдавать до 12 запросов в секунду (в максимуме это 1 миллион запросов в сутки, в реальности же с учётом неравномерности нагрузки - всего 400-500k запросов в сутки, что позволит обслужить 50-150k посетителей в сутки).
Много это или мало - судить не мне.

kpripper, нефига ж себе!
В slow queries занесли запрос на получение списка категорий.
У тебя ведь общее кол-во категорий меньше хотябы 2000 штук?

Раз ты не хочешь выяснять что это за плагин у тебя такой странный (жрущий ресурсы, причём - не входящий в базовую поставку системы), то вариант только один - увеличить производительность сервака.
Разве нет?