zhitov: До этого термина я еще не доучился ;)
В принципе, под мою задачу подходит:
прохожу циклом по исходному массиву -> запросом к БД выбираю нужное значение и дальше эту пару обрабатываю.
Или лучше пойти узнать - что есть сериализация? :)
Лучше получить из массива только нужные данные (регулярки и пр. помогут), а потом запросом получить данные из базы.
LEOnidUKG: Почему?!
БД придумана для того чтобы её напрягать запросами, если не справляется настраивать и менять железо. Если её не напрягать, зачем она нужна? Можно и в файлике похранить данные.
Если расставленны индексы, то запросы выполнятся в доли секунды.
А ноги - чтобы ходить. Только не говорите, что не ездите на транспорте, не летаете на самолетах и т.д. Так и тут: база создана для хранения и обработки данных, но это совсем не значит, что ее обязательно грузить на 100%
donriga: 1. Переписал запросы, в основном убирал условия в where, использовал join.
2. Используя explain создал нужные индексы.
Лучше разбейте большие запросы на несколько мелких, собирайте результат в php и кешируйте. Часто помогает.
donriga: 3. Сделал кеширование запросов на уровне веб-приложения, serialize, unserialize. Разделил часто выполняемые запросы, установил время хранения кеша для разных элементов страницы.
Немного не понятно, что именно кешируете. Я всегда кеширую данные, многие знакомые - блоки html. У них явно быстрее строится страница, но мне такой подход не нравится.
donriga: 4. Поставил связку nginx+apache+mysql
Осталось правильно настроить эту связку. Например, можно через nginx отдавать сохраненный html всей страницы, а если его нет - отправлять запрос в php.
Ну и самое главное, что Вам уже сказали - вы оптимизировали генерацию страницы (да и то не полностью: где eaccelerator? где мемкеш? почему используются where/join? почему вообще используется mysql? =)))). А вот время загрузки страницы зависит от других параметров: размера страницы, количества и размера медиафайлов, количества и размера js и css и пр.
До этого термина я еще не доучился ;)
В принципе, под мою задачу подходит:
прохожу циклом по исходному массиву -> запросом к БД выбираю нужное значение и дальше эту пару обрабатываю.
Или лучше пойти узнать - что есть сериализация? :)
Лучше получить из массива только нужные данные (регулярки и пр. помогут), а потом запросом получить данные из базы.
Почему?!
БД придумана для того чтобы её напрягать запросами, если не справляется настраивать и менять железо. Если её не напрягать, зачем она нужна? Можно и в файлике похранить данные.
Если расставленны индексы, то запросы выполнятся в доли секунды.
А ноги - чтобы ходить. Только не говорите, что не ездите на транспорте, не летаете на самолетах и т.д. Так и тут: база создана для хранения и обработки данных, но это совсем не значит, что ее обязательно грузить на 100%
1. Переписал запросы, в основном убирал условия в where, использовал join.
2. Используя explain создал нужные индексы.
Лучше разбейте большие запросы на несколько мелких, собирайте результат в php и кешируйте. Часто помогает.
3. Сделал кеширование запросов на уровне веб-приложения, serialize, unserialize. Разделил часто выполняемые запросы, установил время хранения кеша для разных элементов страницы.
Немного не понятно, что именно кешируете. Я всегда кеширую данные, многие знакомые - блоки html. У них явно быстрее строится страница, но мне такой подход не нравится.
4. Поставил связку nginx+apache+mysql
Осталось правильно настроить эту связку. Например, можно через nginx отдавать сохраненный html всей страницы, а если его нет - отправлять запрос в php.
Ну и самое главное, что Вам уже сказали - вы оптимизировали генерацию страницы (да и то не полностью: где eaccelerator? где мемкеш? почему используются where/join? почему вообще используется mysql? =)))). А вот время загрузки страницы зависит от других параметров: размера страницы, количества и размера медиафайлов, количества и размера js и css и пр.
один уже захотел за 500wmz. Есть желающие еще???
Соглашайтесь!!!! Правда, все-равно не доделает за эти деньги...
Заипали своими предворидельными блицами, уже не раз обсуждалось...
по теме: тоже урл глянул бы...
Класс! А ничего, что хотелось купить сайт с такими параметрами, но предварительно посмотрев его?
По теме - продавец просто проигнорил ставку и сообщение, что мягко говоря не хорошо...
Предварительно - блиц, хочется увидеть подопечного.
happy-joker, все уже давно ее видят, погуглите.
http://counter.yadro.ru/hit?t27.1;uhttp://domain.com - это имеете в виду?
http://counter.yadro.ru/values?site=site.ru - оно?
не всем, мне, например, нравится BSD или MIT :))
Я ТС говорил про это, не помогло =). Но движок действительно не плохой...
Если все еще интересно - постучите в личку, дам все контакты по rapidshare.ru.
Забрал пару доменов, все отлично.