seodude:

Не говоря уже о том, что пейджер надо оптимизировать, чтобы он базу не нагружал как гавно слона, а вы … как по учебнику все. Опыта то совсем нет чтоли разработки? Как базы себя ведут не знаете? дурдом.

Запросы по 10 секунд выполняются .. куда катится мир, и это новостной движек рассчитанный на нагрузку и большое количество записей

seodude:

Алексей, есть под рукой немаленькая ДЛЕшка? просто вдруг это у моего бд сервера боку снесло, написал я конечно ядовито, но моей злобе не было предела

По факту, я знаю еще методики ускорить запросики, вот например запросик


SELECT SQL_NO_CACHE id, autor, date, short_story, SUBSTRING(full_story, 1, 15) as full_story, xfields, title, category, alt_name, comm_num, allow_comm, allow_rate, fixed, rating, vote_num, news_read, votes, flag, editdate, editor, reason, view_edit, tags FROM dle_post WHERE category IN ('5') AND approve=1 ORDER BY date DESC LIMIT 660,15;

15 rows in set (1.11 sec)


переписываем запрос на запрос такого плана.


SELECT SQL_NO_CACHE p.id, autor, date, short_story, SUBSTRING(full_story, 1, 15) as full_story, xfields, title, category, alt_name, comm_num, allow_comm, allow_rate, fixed, rating, vote_num, news_read, votes, flag, editdate, editor, reason, view_edit, tags FROM dle_post p INNER JOIN (SELECT id FROM dle_post WHERE category IN ('5') AND approve=1 ORDER BY date DESC LIMIT 660,15) i using(id);

15 rows in set (0.02 sec)


Есть разница? результаты возвращает очевидно одинаковые

Вот если бы разработчики ДЛЕ писали запросы правильно, то двиг бы РЕАЛЬНО летал, ибо сложного там ничего нет в плане аналитики .. а щас это кусок тормозного говна, переписывать все запросы руками — застрелиться, да и зачем мне это, не так уж много и приносит он дле ибо серьезных проектов на нем у меня нету

seodude:

я в краснодаре сейчас живу, у меня конопля под окном растет, вот и пишутся запросы на отлично xDD

seodude:

2Serg может в россии все настолько плачевно(было по крайней мере) что во времена создания той же DLE она не была бы не куплена ни разу и жрать разработчикам нечего бы было?

2kukusa — на 1 сайте, я вообще сайты не держу по факту, вот сейчас появилось 2 сайта адалт тематики. Один из них как тест был сделан на ДЛЕ, сейчас плачу, смотря на сервер, и удалить нельзя, трафик под касарь уников без вложений.. сделал другой сайт на собственном костыле, безо всяких финтифлюшек, жестко выполняющий только свои задачи, работает быстрее, не смотря что там база в 4 раза больше, ну а ДЛЕ я скорее обновлю до последней версии, и переработаю engine.php файл на запросики поинтереснее, вот только время оно всему виной, не хватает

seodude:

Вот график slow queries от мускуля. Прямая статичная нагрузка — проект веб апликуха контактовская с огромной базой (400 млн строк или 4 млрд ли, точно не помню). По той базе выполнялись запросы раз в секунду статистические и еще была обычная нарузка от запусков приложений.

Ту базу я отключил, нагрузка спала, поставил ДЛЕ ну и видно нагрузку от него в зависимости от наполнености .. она растет …

2Ikar, Да я вроде не истерю, проистерился уже
Заистерил когда увидел что на сервере где практически ничего нет, есть только длешник нагрузка на винт идет перманентная под 80 мбайт в секунду чтение и запись — вот тут поистерил

инструкции не буду приводить по причине, которую kukusa указал — чтобы потом меня школьники прокляли? спасибо, карма и так не лучшая =)

Перенесу на дле 9.5, посмотрю что будет(сейчас дле 9.3), если будет так же — даже возможно адаптирую хотя бы часть запросов под более высокоскоростные выборки, ну и выложи изменные файлы, а разработчики — лестно что ктото знает

может даже значит прислушаются и сделаю отличный в плане «быстрый старт» движек, который не падает при смешных нагрузках.

seodude:

обижусь =)

seodude:

в обещм я погорячился получается, херня не в дле возможно, а в сервере, возможн связано с ле, возможно наплывы ботов поисковых .. implicit conversion на данный момент практически никак не влияет, по крайней мере на простые запросы.

а про лимит все равно — надо их оптимизировать, они гонят когда есть выборки по нескольким полям + сортировка … тут какбы факт

у меня версия бд сервера 5.5 и на маке и на сервере. возможно фрагментация, хер его знает.

[--] Up for: 19d 12h 6m 42s (12M q [7.609 qps], 494K conn, TX: 20B, RX: 2B)
[--] Reads / Writes: 75% / 25%
[--] Total buffers: 1.4G global + 176.3M per thread (50 max threads)
[OK] Maximum possible memory usage: 10.0G (76% of installed RAM)
[OK] Slow queries: 0% (24K/12M)
[OK] Highest usage of available connections: 62% (31/50)
[OK] Key buffer size / total MyISAM indexes: 128.0M/84.8M
[OK] Key buffer hit rate: 100.0% (583M cached / 220K reads)
[OK] Query cache efficiency: 31.7% (2M cached / 9M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (97 temp sorts / 201K sorts)
[OK] Temporary tables created on disk: 8% (14K on disk / 186K total)
[OK] Thread cache hit rate: 99% (62 created / 494K connections)
[!!] Table cache hit rate: 2% (699 open / 23K opened)
[OK] Open file limit used: 0% (538/200K)
[OK] Table locks acquired immediately: 99% (121M immediate / 121M locks)
[OK] InnoDB data size / buffer pool: 682.2M/1.0G

Статистика и настройки в общем то говорят что серверу достаточно ресурсов и в общем то он пинает хуй)