Скорость работы сайта. Поделитесь опытом плз.

1. Правильно индексы в БД организовать и запросы к БД правильно делать.
2. Использовать ООП в разумных пределах.
3. Хороший хостёр.

[QUOTE=mfender]2. Использовать ООП в разумных пределах.[/QUOTE]

Можно вот здесь поподробнее?

Объекты создают себя в памяти и этим создают дополнительную нагрузку на сервер. Но ИМХО лучше сервак сделать мощнее, так как разбиратся в крупном проекте написанный процедурно... Это заветное желание для своего заклятого врага.

[quote=shaelf]Объекты создают себя в памяти и этим создают дополнительную нагрузку на сервер. Но ИМХО лучше сервак сделать мощнее, так как разбиратся в крупном проекте написанный процедурно... Это заветное желание для своего заклятого врага.[/quote]
Это верно. Но сталкивался я с одним ОЧЕНЬ крупным проектом, где для каждого свойства в классе существовало минимум два метода, типа Get() и Set($Value) с единственной строкой в теле метода - return $this->FieldName или $this->FieldName = $Value. Учитывая их количество и то обстоятельство, что PHP - транслятор и разбирает все строки кода, то такой подход представляется мне чрезмерным.

[QUOTE=mfender]Это верно. Но сталкивался я с одним ОЧЕНЬ крупным проектом, где для каждого свойства в классе существовало минимум два метода, типа Get() и Set($Value) с единственной строкой в теле метода - return $this->FieldName или $this->FieldName = $Value. [/QUOTE]
Так такой подход и есть следование принципам ООП. Тогда уж или исспользовать ООП или не исспользовать, что равносильно использовать классовые конструкции не заморачиваясь на самом ООП )

Принципам - да. Но зачастую это - тупое следование. Если мне заведомо известно, что AnyObject::VarValue будет обязательно равно 5, то я объявлю поле public и банально присвою ему нужное значение без написания лишних методов. Принципы ООП в данном случае будут действовать, когда что-то из этого равенства принципиально изменится и я в классе-наследнике прикручу к установке этого свойства новый метод. Но изначально загромождать код в случае PHP - грех большой. ТОТ проект крутился на отдельном сервере и при 400 тысяч показов страниц в сутки работа страшно замедлялась из-за вот этой вот ненужной препарации всех переменных. Заверяю: там было много ненужных излишеств.

Может быть. Но это и есть ООП, за которое надо платить быстродействием, но улучшать скорость и качество разработки ))
А нарушать инкапсуляцию и целостность класса такими вещами уже отход от такой модели разработки ) Ничего не хочу сказать против вашего подхода, видимо ООП в PHP недостаточно развито, или сам инструмент не для больших разработок. Я не веб-программист. )
А в случае когда есть неизменяющиеся статические даные объекта, неужели нет никаких средств указать константную или статическую переменную инициалирированную единожды и не способную меняться?
А так, если потребуется переработка некоторая класса, и изминения метода работы с данными. Получается переделывать все во всем коде, а не только в методе SetXXX. Ведь объект должен предоставлять только свой интерфейс безо всяких деталей реализации.

Я там выше не про константы писал...
Константы в PHP есть и в PHP5 есть константы, существующие в классах, к которым можно статически обращаться также из-вне класса.

Всё правильно, потребуется. Но есть свойства, которые используются только внутри класса, причём используются "по случаю". Смысла для их установки и получения писать какие-то методы просто нет.

[quote=Scottie]Вот интересно было бы почтитать что и как думают люди по вопросу быстродействия сайтов на PHP и MySQL. Так сказать общий подход достижения успеха,помимо резвого сервера;-)
[/quote]
думаю, что не стоит замыкаться на MySQL & PHP. желательно заранее спрогнозировать масштабы проекта. и исходя из этого выбирать СУБД и язык. иначе - наваяв все на P&M придется потом все по сто раз оптимизировать, ставить более мощный сервер и т. п.

[QUOTE=squirL]думаю, что не стоит замыкаться на MySQL & PHP. желательно заранее спрогнозировать масштабы проекта. и исходя из этого выбирать СУБД и язык. иначе - наваяв все на P&M придется потом все по сто раз оптимизировать, ставить более мощный сервер и т. п.[/QUOTE]
На самом деле, PHP не так уж и плох даже для большого. Насчёт СУБД - согласен. Если проект расчитывается на стремительный рост, то MySQL - не самый лучший выбор (хотя бы из-за ограничений на количество записей). Но Zend уже позаботился об этом, сделав Zend_DB - абстрактный слой в рамках Zend Framework для свободной работы с различными БД без значительных затрат по переписыванию кода. Сыровато ещё, но оно развивается.

[QUOTE=mfender]Я там выше не про константы писал...
Всё правильно, потребуется. Но есть свойства, которые используются только внутри класса, причём используются "по случаю". Смысла для их установки и получения писать какие-то методы просто нет.[/QUOTE]
Тогда не понял, зачем делать свойство публичным если оно исспользуется только внутри класса? Оно должно быть приватным и не иметь никаких методов для установки/получения значения. И продолжать меняться так же внутри класса.

[quote=aks]Тогда не понял, зачем делать свойство публичным если оно исспользуется только внутри класса? Оно должно быть приватным и не иметь никаких методов для установки/получения значения. И продолжать меняться так же внутри класса.[/quote]
Ну это частности. Не буду же я тут описывать все случаи, в которых не буду нагружать код написанием излишних методов. Конечно, в PHP нет таких замечательных вещей, как у, например Delphi:


Тут я могу обращаться к методам прямиком через значение свойства (и наоборот). В PHP такого, конечно нет. Это вносит определённые затруднения, если вдруг понадобится кардинально менять код.

[QUOTE=mfender]MySQL - не самый лучший выбор (хотя бы из-за ограничений на количество записей)[/QUOTE]
Насколько я понимаю эти ограничения настраиваются самим провайдером. Существуют ли какие-то ограничения самого MySQL?

[QUOTE=mfender]Ну это частности. Не буду же я тут описывать все случаи, в которых не буду нагружать код написанием излишних методов. Конечно, в PHP нет таких замечательных вещей, как у, например Delphi:
[/QUOTE]
Ну не знаю насчет замечательных - по мне так довольно вредная фича. Поскольку вносит путаницу в код и приучает к дурному стилю )

Я просто о другом маленько. Ведь помоему вполне очевидные правила разработки классов:
При исспользовании объекта не видно никаких внутренних данных объекта и деталей реализации. Есть только интерфейс в виде публичных методов, через которые собственно и управляется объект и описывается его поведение. Работа со служебными переменными так же полностью замкнута внутри класса, и никак не передается наружу. Это все вытекает из одной из основ ООП и впринципе не вижу случая когда это целесообразно нарушать.

[QUOTE=shine]Насколько я понимаю эти ограничения настраиваются самим провайдером. Существуют ли какие-то ограничения самого MySQL?[/QUOTE]
Конечно есть: что-то вроде полмиллиона рядов на таблицу. А провайдеры ограничивают количество одновременно выполняемых запросов.

[quote=aks]Ну не знаю насчет замечательных - по мне так довольно вредная фича. Поскольку вносит путаницу в код и приучает к дурному стилю )[/quote]
:eek: Чего ж в этом дурного?

[quote=aks]Я просто о другом маленько. Ведь помоему вполне очевидные правила разработки классов[/quote]
Да кто ж спорит?

[QUOTE=mfender]Конечно есть: что-то вроде полмиллиона рядов на таблицу. А провайдеры ограничивают количество одновременно выполняемых запросов.[/QUOTE]

Хм....интересно. что же если будет больше записей...то капут?
Там выше был совет по тому как давать правильные индексы. А нет ли какого нить манула небольшого,чтобы понять что я делаю правильно,что нет. не охота большие книги листать)

а может влиять не очень хорошая врестка? я,например, в дизайне по минимуму использую с картинки. еще иногда тяжелова-то CSS подгружаются.


а к дисскусии об ООП. я вот пишу не используя этого(классов и тд),понимаю,конечно что это не очень хороший стиль и людям в этом сложнее разобраться наверно. С точки зрения быстродействия этот подход тоже пройгрышный?

[quote=Scottie]Хм....интересно. что же если будет больше записей...то капут?
Там выше был совет по тому как давать правильные индексы. А нет ли какого нить манула небольшого,чтобы понять что я делаю правильно,что нет. не охота большие книги листать)[/quote]
Больше просто не втавитсо в таблицу.
Почитать лучше всего ТУТ

[quote=Scottie]а может влиять не очень хорошая врестка? я,например, в дизайне по минимуму использую с картинки. еще иногда тяжелова-то CSS подгружаются.[/quote]
Тут разговор, кажется, о быстродействии сайтов, а не о скорости их передачи в браузер... Хотя, могу ошибаться.

[quote=Scottie]а к дисскусии об ООП. я вот пишу не используя этого(классов и тд),понимаю,конечно что это не очень хороший стиль и людям в этом сложнее разобраться наверно. С точки зрения быстродействия этот подход тоже пройгрышный?[/quote]
С т.з. быстроодействия может и не проигрышный, но с точки зрения удобства/правильности/скорости разработки объектно-ориентированный подход наиболее правильный. Если, конечно, это не сайт, состоящий из двух скриптов.

[QUOTE=mfender]Больше просто не втавитсо в таблицу.
Почитать лучше всего ТУТ
[/QUOTE]
спасибо за ссылочку.


а вот только проверил на пятой версии MySQL у меня уже больше 500 тыс записей!

[QUOTE=mfender]
Тут разговор, кажется, о быстродействии сайтов, а не о скорости их передачи в браузер... Хотя, могу ошибаться.
[/QUOTE]

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

Чтобы HTML грузился в браузер быстрей и жрал меньше траффика, следует его сжимать gzip'ом. У меня традиционная страница 80-90кБ приходит к браузеру в виде 15-20кБ. Выйгрыш значительный. Картинки нужно правильно оптимизировать. Но, зачастую, следует ещё учитывать аудиторию сайта: для некоторых сайтов можно не особо экономить на графических элементах, т.к. те, кто их смотрит пользуются исключительно высокоскоростными соединениями. :)

И во многом это зависит от толщины и загруженности каналов от сервера к браузеру.

[QUOTE=mfender]Конечно есть: что-то вроде полмиллиона рядов на таблицу. А провайдеры ограничивают количество одновременно выполняемых запросов.[/QUOTE]
Ну это ты перегнул. MySQL конечно г**вно, но не настолько.

http://dev.mysql.com/doc/refman/5.0/en/table-size.html