Здравствуйте друзья, у меня есть сайт http://promote-it.ru
Так вот, такие типы сайта, оч грузят базу, ибо показывают очень много вещей в реальном времени...
поэтому я подумал, а почему бы собственно не грузить данные только один раз, а патом при переходе выводить данные из сессии?
Все бы было хорошо НО, браузер виснет и сайт не грузится после перехода через пару страниц! 
Все же стоит использовать текстовый документ для снижения нагрузки на сервер/базу ?

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

сайт нечего не подгружает, и вообще статичный. Но оптимизации требует, хотя бы вот эти моменты:


N-ое количество повторений одного и того же, вынеси во ф-цию

Сайт напоминает анекдот

"Мадам, оставьте сессии масло - смените машину"

MoLeX, Не забывайте что вы видите только результат, гоно на самом деле в цикле с базы берет!

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

а что за memory_limit ?

Мне как бы нужна такая схема работы

If Session !=1
значит мол обращаемся к базе
else (если уже посещал страницу и где то данные сохраняются)
то грузим с места сохранения

НО если посмотреть сейчас на BIG Бонус, где я даю пользователям собирать бонусы и сайты там по циклу идут, то я там использую массив!
причем как для капчи. которая очень приколньая однако.... и для ссылок рекламных

Вот что я так сказать изабрел...


Это сообщение отредактировал(а) Muerto - 21.2.2010, 10:46

В цикле из базы??? Кто же учил так разрабатывать?!
Оптимизируй запрос к базе, чтобы был один-два ну пять (это уже много!) запросов на эти баннера, но уж никак не в цикле. 
Решать же костыли, написанные в одном месте, кешированием, это неправильно.

smartov, 
Ну представте что у меня в базе 22 записи, где вычисляется если заказали мини баннер или нет..
Я бы был рад каким то другим оброзом их читать...


Но не забываем что это не 5 запросов и не 20, а всего один
SELECT * FROM
а затем уже идет просот 
while(fetch...

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

Это сообщение отредактировал(а) Muerto - 21.2.2010, 10:50

Пол секунды генерация такой страницы - жесть. Браузер от сессий не виснит кстати.

Хочу немного повредничать



Поддержу ка я smartov'a

awers, А сейчас сессий нету... я их снес...
Меня кстати безопасность моей капчи немного волнует...

И кстати пол секунды это много?
Я пока не оптимизировал запросы могло быть и все 20=-)
Дело в том что там рандомация идет... например для "текстовый баннер"

Это сообщение отредактировал(а) Muerto - 21.2.2010, 11:06

это как 50 лет 



Это дело можно и бд решить .. select * from banners where active = 1 and .... order by rand();


Такие проекты надо отстреливать а не отлаживать :(

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

Muerto, 

уважаемый. Вы свои мысли с трудом формулируете на форуме. Может рановато программировать? 

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

awers, в данном случае не согласен, order by rand() при tысачи записей делать пытались 
smartov, я в россии уже лет 16 не живу а мне всего 21, не красиво судит мои интелект по граматике

Muerto, да, только что потестил на 60к записей - действительно не айс.
Но опять же, это 60к а не 22 

В качестве кеша могу посоветовать Memcached, гораздо быстрее чем на файлах.

maximus666,   
Ага, на шаред-хостинге.

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



Вам подсказать как оптимизировать запрос на псевдо-рандомизацию?

smartov, мне подскажи, пожалуйста.
Что-то вроде: имеем 1кк записей, надо выбрать разных 10 типов с наименьшим значением одного из полей и случайным образом отсортировать эти записи. На лету.

http://jan.kneschke.de/projects/mysql/order-by-rand/

IZ@TOP, дополнительным псевдо-рандомным полем которое обновляется раз в сутки, например.
Вот тут описывается один из вариантов
http://habrahabr.ru/blogs/mysql/55864/

Случай, когда нужно получить слишком много записей по условию, и ВСЕ ИХ после выборки расставлять их в рандомном порядке не рассматривается в виду либо явного просчета проектирования.

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

О просчетах проектирования готов послушать.

1. Имеем связанные данные, которые получаем из нескольких источников.
2. Данные в нормализованном виде сохраняем в базу.
3. Предположим, что выходит две сущности (таблицы), связанных одна ко многим. Т.е. запись в первой таблице связана с неопределенным количеством записей в другой.

Задача.
Выбрать данные по следующему условию:
1. Записи из таблицы "одна ко многим" должны соответствовать условию поле1=значение.
2. Записи из таблицы "многие к одному" должны соответствовать нескольким условиям, вроде поле1-2=значение1-2, должны быть отсортированы по поле3, связаны с таблицей "одна ко многим" по полю поле4.
3. Данные должны быть сгруппированы по поле4 и случайным образом выбраны 20 записей из полученного результата.

Требования: оригинальные данные сохранить в нормализованном виде, при денормализации и синхронизации, денормализованные данные не должны расходиться с оригинальной версией.

Мне тут видится один самый простой вариант реализации. Но, если есть идеи - готов выслушать.

Любопытно, и в итоге этих манипуляций получается 1кк записей?
Что за данные там лежат, если не секрет?

IZ@TOP, 

Насколько я вижу твою задачу этот банальный вариант с денормализацией вполне тебя устраивает. "Случайные" 20 записаей вполне могут быть получены этим методом. Поправь меня если я что-то не так понял

smartov, все верно. Меня все устраивает, тем более, что это было временной необходимостью вызванной восполненным сознанием руководства  Просто подумалось, может я чего не знаю и все можно было сделать проще? Но это так, риторический вопрос.

Fortop, база данных вроде market.yandex.ru.

Нет, сорри, тайным знанием не владею   
Да и вообще просветить я рвался автора топика, который явно не знает о вещах, которые тебе кажутся банальными   

smartov, надеюсь мы его совместными усилиями хоть немного просветили   Диалог всегда полезен.

awers, а в 22 нет никакой рандомации ,рандомация идет в объявлениях и ротаторах=-)

Добавлено @ 18:49
IgorIV, У меня VDS причем не хилый, а не шард хост...

А насчет рандомации,
Order by rand самый поршивый метод,
после него есть функция которая по поиску допустим можете найти, как мол получить random value, но она опять же вас разочарует если у вас таблица по ID не по порядку, как у меня например...

Я вот пользуюсь функцие которая как бы берет все записи, присваиваем им ID и затем уже рандомирует, решая при этом проблему пропуска
А скорость очень высокая

Это сообщение отредактировал(а) Muerto - 25.2.2010, 18:51

Linux?

IgorIV, Да CentOS стоит

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