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

 suomi
Индус написал скрипт для одного сайта на PHP но там все дергается из базы mysql которая 160 мегабайтов и иногда это занимает несколько секунд. Есть ли какие скрипты чтоб можно было сгенерировать статику? В mysql создается каше кверей но на сколько я понял это временые. иле еще как нибудь можно ускорить генерацию страниц?

 ibiz
если контент не обновляемый, то можно скачать сайт в статике и залить статику

 mr. snatch
ну если тебе действительно из динамического сайта нужно сделать статику, можешь просто тем же wget-ом или телепортом скачать, но от что-то мне подсказывает, что будет правильнее тому же индусу просто нормальное кэширование к движку прикрутить...

 taj
Самое простое решение

Если сайт всёже динамический, т.е. что-то нужно регулярно обновлять - можно внедрить кеширование.


З.Ы. Могу заняться - люблю оптимизировать чужие скрипты))))

 suomi
а как оно внедряется?

 Yacc
fastcgi cache или proxy cache
mysql query cache

Внедряй.

 dDan
Ну или тупо file cache стукни я посмотрю аська есть у тебя моя

 iRoot
Кеширование обычно внедряется в самую последнюю очередь, поскольку несет за собой целую кучу проблем и ограничений, а в некоторых случаях только усугубляет ситуацию.
160Мб - это детский объем, поскольку легко помещается в памяти сервера. В первую очередь нужно провести оптимизацию базы данных и запросов к ней, если там не совсем все плохо, то за несколько часов работы можно добиться результата гораздо лучше чем кеширование.

 taj
suomi писал: сейчас что-то сказать всё равно что пальцем в небо ткнуть. Нужно смотреть на пациента,

 kodek
Кстати да, 160мб для мускуля - фигня, а не база.
Не должна она так тормозить.

 taj
Я не понимаю что за глупости про объём?
Можно создать одну таблицу, накидать туда бинарных данных хоть на гиг и всё будет летать. А можно и в 50 мегабайтах структуру и связанность замутить что все запросы будут требовать по пятку джойнов))) Ну и записей по несколько кк.

 iRoot
Это не глупости. Если база данных помещается в памяти, то не требуется обращаться к HDD за ними, а он самое слабое звено обычно если конечно логика приложения не перенесена в БД.
Размер данных при выборке не важен, важно только сколько при этом эта выборка цепляет.
Например если в таблице 10 миллионов записей, а запрос обращается к 100 из них, то все будет очень быстро работать. А если 50 тысяч и все выборка обращается ко всем 50-ти тысячам, то это будет очень медленно происходить.
Еще очень часто бывает такое что создаются временные таблицы либо лишком большого размера, либо содержащие типы данных, которые нельзя хранить в MEMORY-таблице и приходится сохранять их во временную таблицу на диске.

 taj
iRoot писал: что там за сервер и сколько там памяти нам не известно, и дальше рассуждать на эту тему смысла нет.
iRoot писал: вот это как раз то о чём я говорю - не зная структуры БД, не зная логики приложения, безапелляционно говорить что 200 метров объёма это хуйня как бы не правильно.

 iRoot
Я говорю, основываясь на собственном опыте и наблюдению за поделками индусов, даже не смотря на сервер и приложение могу с высокой точностью предположить что так оно и есть. Слишком много раз я такое наблюдал.
Логика приложения самая простая в большинстве случаем - "база данных черный ящик", в который можно ложить и забирать все подряд, не задумываясь о том как оно работает, храниться и обрабатывается.
Так что думаю все верно.

 Dr.Syshalt
varnish поставить перед сайтом и настроить. Уже полегчает сильно.

 iRoot

Лечение насморка клизмой
Возможно станет легче, но не на долго и болезнь не пройдет.

 Dr.Syshalt
iRoot писал:

С чего это? Это то же самое, что "статику сгенерить". Варниш будет просто на себя всю нагрузку брать, и выдавать из кэша. Если там не требуется какое-то взаимодействие с юзером, то эффект будет 100%. Если сайт динамический - тогда другой разговор, но тогда бы и вопросов о "сделать статику" не возникало.

 iRoot
Ну оно будет работать в тестовой среде отлично, но когда его выпускают в реальный мир, то все уже не так красиво становится. У поисковиков есть дурацкая привычка - проходится по всем страницам сайта, при этом забивается вся память любой системы кеширования, а нагрузка остается очень высокой, поскольку практически каждый запрос это cache miss.
Хотя если эти 160Мб данных не представляют из себя тысячи уникальных страниц, тогда да, все будет отлично.

 Dr.Syshalt
iRoot писал:

Гиг под кыш на диске и TTL в 60 минут, или сколько там надо, всем страницам. Оно ж настраивается, причем легко

 iRoot
А данных-то всего 160Мб и пока этот "кыш" будет забиваться (разогреваться) данными сервак будет лежать. Про целостность информации на сайте я вообще молчу, она будет никакой, особенно при частом обновлении.
Это не выход, это костыль, который не решает проблему, а только создает новые.

 taj
iRoot писал: это нормальное решение проблемы, просто его нужно уметь готовить

Dr.Syshalt прав. Для начала нужно найти самые тормозные места, оценить проблему, посмотреть на интенсивность использования "тормозных" данных, частоту их изменения, в соответствии с этим подобрать live-time для кеша.

iRoot писал: Опять же проблема конкретного повара ) Я не вижу проблемы обновить кеш при апдейте и/или при первом запросе к новым данным.

 iRoot
taj писал:
Это не решение проблемы, это уменьшение проявления симптомов. Потому что имеем тормозящее приложение - это симптом. Почему тормозит? Потому что БД используется неправильно - это проблема, так вот ее и нужно решать.
taj писал:
А я вижу много проблем в этом:
- нужно выделить гораздо больше памяти под кеш, поскольку одни и те же данные будут кешироваться многократно
- нужно добавлять в бизнес-логику систему сохранения, удаления, обновления данных из кеша
- приложение все равно будет тормозить при первом запросе к стренице
- сервер будет продолжать испытывать высокую нагрузку
- решение временное, наступит момент, когда симптомы усилятся снова
Альтерантива:
- использовать базу данных правильно

 taj
iRoot писал: Вот откуда ты знаешь что БД используется неправильно? Думаю ты догадывешься что существуют запросы которые выполняются не за 0.01 секунду. И которые просто не возможно выполнить за такое время без полного рефакторинга базы или запуска sql на сервере быстродействие которого уходит в бесконечность.
iRoot писал:
Прокомментирую:
- память стоит копейки. Держать всё в мемкеше глупо, только самые тормозные вещи или наиболее часто используемые. Остальное на диск. Они вообще стоят смешных денег. Даже на виртуалах - хочешь 10гигов, хочешь 20. Про дедики даже и не говорю. Меньше чем 250 там не бывает сейчас, по моему.
- зарефакторить базу+само приложение будет проще и дешевле?
- будет относительно долго отдавать первый результат без попадания в кеш. Но только ОДИН раз. Что сделать чтобы в него попадать чаще я писал в предыдущем посте
- на то он и сервер что бы работать) А если серьёзно, например, на сервер идёт 100к запросов в час (пол часа,10 минут не важно) и часть этих запросов "тормозит" - внедряем кеш, и вместо этих 100к до базы будут доходить может быть считанные тысячи запросов. Это не облегчит жизнь серверу?
Ну конечно, переписать всё, и слать их в таком же количестве более рациональное решение))
- зарефакторить всё, и всё равно наступит момент когда ты будешь внедрять кеш, потому что начнёт заваливаться база, процессор.

 iRoot
Запросы существуют разные, время его выполнения и создаваемая нагрузка на сервер связаны нелинейно, это не показатель.
Кэш это очень хорошо и правильно, только он должен внедряться только после оптимизации приложения и базы данных, иначе толку от него будет очень мало и оно не стоит тех проблем, которые прийдется решать.
В большенстве случаев решить проблемы с производительностью рефакторингом приложения гораздо быстрее, дешевле и, что самое главное, эффективнее чем кеширование. Бывают конечно исключения, не спорю. Вот недавно работал на проекте, который был написан на Perl-е в конце 90-ых, пришлось все переписывать заново. Тогда я понял смысл пословицы:
Цитата:
Тут конечно без комментариев даже. Но все же вера живет, что хотя бы этот проект написан человеком.

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

 taj
iRoot писал: Ну я и сказал что тормозит всего лишь часть из них.
iRoot писал: В очень сложных проектах (скорее даже не сложных, а написанных через одно место) возможно и возникнут большие проблемы. Чаще всего, всё крайне просто.
iRoot писал: Очень сомнительно утверждение, но думаю это тема для отдельного топика и не на этом форуме
iRoot писал: думаю стоит учесть что абсолютное большенство проектов так никогда и не получают ту нагрузку (пользователей) которую хотели бы получить хозяева и для проектов, скажем, 500к хитов в сутки статика прекрасно отдаётся с "дохлых" виртуалов)
Ну и про ssd забывать не стоит)