lock12 - это твое сообщение от гостя?

_____________

Ох и холиварная вышла тема. Фрем или не фрейм, mysql или oracle. Если нет желания или умения то написать плохо можно и на фрейме и без него. Как по мне надо просто понимать какие плюсы и какие минусы и самому выбирать, при этом проинформировав и заказчика. Мол мил человек, если писать с нуля, то можно написать что будет работать на N % быстрее, но зато писать мы будем на N дней/месяцев/лет дольше и не факт что то что мы в результате напишем сможет поддерживать кто-то кроме нас, т.к. там будут километры кода, в которых обычно программисту при использовании фрейма вникать не нужно.

А что касательно по теме то я могу от себя выделить следующие меры по повышению устойчивости к нагрузкам:

1. Первое и самое главное это правильно спроектировать систему, если спроектировать не верно, то все остальное это костыли.

2. MySQL - идексы это понятно, но я бы еще настоятельно рекомендовал уходить от нормализации БД . Постараюсь объяснить что я имею ввиду - по статистике самые частые запросы это запросы на выборку посему структуру БД нужно проектировать так что бы запросы на выборку выполнялись очень быстро. Например у вас есть какая-то таблица со списком чего бы то нибыло и вам по ней нужно делать статистические выборки, скажем узнать количество каких-то записей сгруппированных по каким-то параметрам и если этот запрос будет выполнятся часто, то лучше сделать отдельную таблицу в которой вести подсчет записей по этим параметрам и обновлять данные в ней при изменении в основной таблице, что не сложно сделать при помощи триггеров. Да, работы тут выйдет больше и будет некоторая избыточность данных, зато запрос на выборку будет очень прост и быстр.

3. И снова MySQL. Я бы порекомендовал уходить от любых JOIN в сторону IN. Т.е. если к данным в одной таблице надо при выборке добавить данные из другой по ID, то сперва выбираем строки из главной, собираем нужные ID и делаем запрос к подчиненной вставляя список ID в IN. Этот метод даст возможность в будущем разнести большие таблицы по разным БД/серверам.

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

5. Статика - тоже очень интересный момент как и где хранить статические файлы, имеется ввиду все что не скрипты. Я вот сейчас разрабатываю серьезный проект где будет много картинок и иконок, к которым будут частые запросы. Сделал сразу отдельный класс, через который заливаю все картинки и этот класс кроме сохранения картинок на текущем сервере еще может разбрасывать их с таким же именем на другие сервера. Т.е. мы получаем разбросанные по нескольким серверам файлы с одним и тем же именем и можем строить потом балансировщики как на движке системы, атк и с помощью HTTP серверов.
Еще могу дать один совет по поводу сохранения файлов - при любых изменениях имя файла должно меняться. Это даст возможность легко кешировать файлы на стороне клиента и в дальнейшем легко реализовать подключение CDN, если до этого дойдет.

Ну так на скорую руку у меня все

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

Странно, что никто не вспомнил о кешировании байт-кода, APC, Xcache, eAccelerator и т.п.

killer8080
Люди не палят свои секреты

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

twin

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

Твин не такую уж крамольную фразу сказал.
Конечно, сегодня без кеша почти никуда.
Например apc, о которым приложение вообще не знает. Или redis, с которым приложение должно активно "сотрудничать". Или связка varnish+ESI... да мало ли...
Ер если приложение очень большое, то инвалидировать кеш не всегда просто. И это может стать проблемой.


_____________
Свои мозги еще никто не отменял.
Телепатов нету.

waldicom