Уважаемые разработчики DLE

[terminatorxp 1]

Вы чо курите? Тяжело тестировать двиг перед выпуском? Ваша лень в написании SQL запросов приводит сервера к краху.

Желающим сравнить. Есть например запрос написанный в «стиле дле».

SELECT SQL_NO_CACHE date FROM dle_post WHERE approve AND allow_main ORDER BY 1 DESC LIMIT 18765,15;

+---------------------+

| date |

+---------------------+

| 2011-05-15 13:57:11 |

| 2011-05-15 13:57:09 |

| 2011-05-15 13:57:07 |

| 2011-05-15 13:55:17 |

| 2011-05-15 13:52:38 |

| 2011-05-15 13:50:49 |

| 2011-05-15 13:48:46 |

| 2011-05-15 13:25:09 |

| 2011-05-15 13:21:48 |

| 2011-05-15 13:08:48 |

| 2011-05-15 13:01:00 |

| 2011-05-15 12:55:08 |

| 2011-05-15 12:51:24 |

| 2011-05-15 12:51:06 |

| 2011-05-15 12:48:16 |

+---------------------+

15 rows in set (3.08 sec)

Время выполнения заметьте.

И сравните если подписать к интовым полям =1 (разработчики ленятся это делать, либо считают что это «круто», возможно даже неебически круто)

SELECT SQL_NO_CACHE date FROM dle_post WHERE approve=1 AND allow_main=1 ORDER BY 1 DESC LIMIT 18765,15;

+---------------------+

| date |

+---------------------+

| 2011-05-15 13:57:11 |

| 2011-05-15 13:57:09 |

| 2011-05-15 13:57:07 |

| 2011-05-15 13:55:17 |

| 2011-05-15 13:52:38 |

| 2011-05-15 13:50:49 |

| 2011-05-15 13:48:46 |

| 2011-05-15 13:25:09 |

| 2011-05-15 13:21:48 |

| 2011-05-15 13:08:48 |

| 2011-05-15 13:01:00 |

| 2011-05-15 12:55:08 |

| 2011-05-15 12:51:24 |

| 2011-05-15 12:51:06 |

| 2011-05-15 12:48:16 |

+---------------------+

15 rows in set (0.01 sec)

У меня выделенный сервер кушает ресурсов и IO загоняет в полную жопу всего лишь на 30 тыс постов.

Если меня услышит случайно или неслучайно их тимлид – рекомендую отвесить люлей вашим разработчикам за подобную халатность.

Сейчас как дурак сижу и переписываю сотни запросов, спасибо вам!

Не говоря уже о вашем методе «множественные категории», вы про EAV не слышали?

Пиздец одним словом.

Источник http://seodude.ru/blog/2011/07/10/%D1%83%D0%B2%D0%B0%D0%B6%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B8-dle/

[white-master 14]

Вы удивлены? Я нет.

[WebSet 74]

Мне интересен ответ администрации.

Будут ли внесены изменения в будущем?

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

[celsoft 6 077]

Мне интересен ответ администрации.

ответ на что на мат? Так его можно не ждать, администрация не комментирует чьи либо личные высказывания.

Будут ли внесены изменения в будущем?

Все сообщения о возможных оптимизациях в коде и запросах всегда тщательно проверяются и по результатам проверки уже принимается решение в ту или иную сторону. Например на небольших БД то что реализовано в DLE сейчас как минимум в два раза быстрее чем предлагается. На больших БД нужно протестировать еще тщательно, результатов тестирования по большим БД пока нет. Часто бывает что с ростом БД результаты скорости меняются. Поэтому каких либо решений по данному вопросу пока нет. Покажет тестирование положительный рост скорости, значит будут изменения если нет то нет. Подобные синтетические тесты не объективны, т.к. запросы в DLE отличаются от этих двух и тестировать нужно на реальных запросах, и реальных серверах работающих с большими БД.

[prikindel 255]

очень даже субъективный тест, который кстати, у меня не подтвердился

запустил по 3 раза каждый запрос, результаты такие:

1

Отображает строки 0 - 14 (15 всего, запрос занял 0.0555 сек.)

Отображает строки 0 - 14 (15 всего, запрос занял 0.0531 сек.)

Отображает строки 0 - 14 (15 всего, запрос занял 0.0580 сек.)

2

Отображает строки 0 - 14 (15 всего, запрос занял 0.0901 сек.)

Отображает строки 0 - 14 (15 всего, запрос занял 0.0670 сек.)

Отображает строки 0 - 14 (15 всего, запрос занял 0.0697 сек.)

и вообще, может там у него майскл иначе настроен или сервак левый..

я тестировал на серваке в час пик, на серваке 1 сайт, БД пол гига, около 30к уников в сутки

для чистоты эксперимента надо и условия одинаковые.

[Wanderers 17]

В случае approve=1 используется индекс, при approve на небольшом количестве записей простое сканирование всех записей, что оказывается даже чуть быстрее так как нет доп. расходов на использование индекса, надо смотреть на большом количестве записей...

approve=1 Применяется метод объединения по индексу 0,005s

approve Выполнено сканирование дерева индексов для каждой комбинации строк 0,069s

на таблице в 180 000 записей, разница в порядок

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

Изменено 12 июля 2011 пользователем Wanderers

[seodude 0]

каюсь, была какая то херня. все в порядке, насчет оптимизации и так мега быстрого движка все равно можно подумать) лишним это не бывает никогда :-)

если разберусь в чем было дело - расскажу если не забуду

[WWW.ZEOS.IN 1 161]

если разберусь в чем было дело - расскажу если не забуду

Было бы интересно почитать

[seodude 0]

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