Новая тема   Ответить

 Dr.Syshalt
iRoot писал:

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

А так, что писать надо изначально не жопой, думаю, все согласны и никто возражать не станет - речь-то о конкретном случае. Я просто прикидываю соотношение, сколько будет оплатить много часов работы программера или полчаса работы админа.

 iRoot
Я не в первый раз участвую в в спорах на тему что лучше - сделать все правильно или хоть бы как, а кеширование все исправит. Зачастую они ни к чему не приводили, все оставались при своих мнениях, время все расставляло по своим местам.
Индус конечно баклан, но кеширование - это таблетка от головы, после которой начинает болеть жопа.
Да, оно будет работать и будет (внешне) работать отлично, все будут счастливы пока не наступает день, когда hit-rate кеша падает ниже критического уровня, обогие запросы к БД вырабатывают весь IO жесткого диска (SSD не панацея, on-disk temporary tables его приговорят довольно быстро) и происходит "завал производительности" примерно до нуля.

 taj
Ты ведь согласен что любое приложение, даже "сделанное правильно" рано или поздно упрётся в производительность базы/диска/проца, и что-то нужно будет менять. Вот у нас оно уже упёрлось) Даже если сейчас вложить прилично денег и всё зарефакторить, во первых не факт что это вообще даст большой выигрыш в производительности (кода мы не видели и судить не можем), а во вторых не факт что ростом нагрузки на хх процентов всё не вернётся на свои места и не нужно будет опять что-то придумывать (кеш, очередной редизайн базы и т.д)

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

 iRoot
Оптимизация - это непрерывный процесс, ее стоит производить постоянно, это часть цикла разработки программного обеспечения.
У всего есть вилка производительности. Для реляционной базы данных это, как ни странно, количество добавлений/изменений/удалений записей в секунду, польку этот показатель не масштабируется, только через шардинг, но тогда вся реляционность пропадает и смысл теряется держаться за это решение.
Application-сервера замечательно масштабируются горизонтально, практически линейно, поэтому ни в коем случае нельзя переносить бизнес-логику в БД для веб-приложений. Тут все просто.

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

 JM
Покаж запрос к mysql
1. 99% его можно переписать более оптимально
2. В базе индексы есть, тоже если добавить можно ускорить?

tmp_table_size = 512M
max_heap_table_size =512M

 suomi
JM писал:

нету.. это я сразу заметил. И потом там еще несколько order by которые создают темп таблицы..
а так вроде обыкновеные селект. завтра на другом сервере попробую. тут наверно еще дествительно железо слабое.

 JM
тупо в пхпадмине добавь индексы для тех полей что в после where и ордер бай... увидиш сразу разницу думаю ;) без нового железа и т.п. ;)

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