Как сделать статические страницы из динамических?

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

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

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

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

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


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

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

fastcgi cache или proxy cache
mysql query cache

Внедряй.

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

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

suomi писал:

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

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

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

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

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

iRoot писал:

Это не глупости. Если база данных помещается в памяти, то не требуется обращаться к HDD за ними, а он самое слабое звено обычно если конечно логика приложения не перенесена в БД.

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

iRoot писал:

Размер данных при выборке не важен, важно только сколько при этом эта выборка цепляет. Например если в таблице 10 миллионов записей, а запрос обращается к 100 из них, то все будет очень быстро работать. А если 50 тысяч и все выборка обращается ко всем 50-ти тысячам, то это будет очень медленно происходить.

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

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

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

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

iRoot писал:

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

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

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

iRoot писал:

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

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

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

iRoot писал:

Это не выход, это костыль, который не решает проблему, а только создает новые.

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

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

iRoot писал:

Про целостность информации на сайте я вообще молчу, она будет никакой, особенно при частом обновлении.

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

taj писал:

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

Это не решение проблемы, это уменьшение проявления симптомов. Потому что имеем тормозящее приложение - это симптом. Почему тормозит? Потому что БД используется неправильно - это проблема, так вот ее и нужно решать.

taj писал:

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

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

iRoot писал:

Это не решение проблемы, это уменьшение проявления симптомов. Потому что имеем тормозящее приложение - это симптом. Почему тормозит? Потому что БД используется неправильно - это проблема, так вот ее и нужно решать.

Вот откуда ты знаешь что БД используется неправильно? Думаю ты догадывешься что существуют запросы которые выполняются не за 0.01 секунду. И которые просто не возможно выполнить за такое время без полного рефакторинга базы или запуска sql на сервере быстродействие которого уходит в бесконечность.

iRoot писал:

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

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

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

Цитата:

If you put a million monkeys at a million keyboards, one of them will eventually write a Java program. The rest of them will write Perl programs. Like this one — Go -f>@+?*<.-&'_:$#/%!

Тут конечно без комментариев даже. Но все же вера живет, что хотя бы этот проект написан человеком.

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

iRoot писал:

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

Ну я и сказал что тормозит всего лишь часть из них.

iRoot писал:

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

В очень сложных проектах (скорее даже не сложных, а написанных через одно место) возможно и возникнут большие проблемы. Чаще всего, всё крайне просто.

iRoot писал:

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

Очень сомнительно утверждение, но думаю это тема для отдельного топика и не на этом форуме

iRoot писал:

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

думаю стоит учесть что абсолютное большенство проектов так никогда и не получают ту нагрузку (пользователей) которую хотели бы получить хозяева и для проектов, скажем, 500к хитов в сутки статика прекрасно отдаётся с "дохлых" виртуалов)
Ну и про ssd забывать не стоит)