А вы вообще статью читали?
Или действительно не видите разницы между цепочкой связанных экранов в винфо и раздельными самостоятельными экранами с боковым глобальным меню, вызываемым кнопкой или жестом, описанным в статье?
Битрикс — это вообще клоака, которую я бы не стал рассматривать в качестве примера (по крайней мере положительного) =))
тонкая настройка производительности нужна далеко не каждому проекту, но это не значит, что их нужно растрачивать направо и налево не задумываясь
Тут спор, можно сказать, извечный) Кеширование решает, но я считаю, что это — «крайний этап оптимизации». Т.е. производительность на всех этапах должна быть высокой, а кеширование — это финальный штрих.
Ведь то же кеширование применимо отнюдь не всегда. Иногда данные нужно получать без задержек. И тут уже эти ваши 800 запросов на каждый клиент уложат сервер бд на раз-два, как туда зайдет несколько десятков человек.
Собственно, возможно, это мой фетиш.
Я не использую ORM вообще как раз потому что они жутко медленные. Я и тяжелые фреймворки, вроде симфони или зенда, не люблю. Делаю все на кодигнайтере, который обладает великолепным балансом функциональности, удобства и производительности.
Но все же с WHERE IN поиграйтесь — он очень сильно сэкономит ресурсы. А перебор по массивам в пхп — быстрый.
Кореляция не прямая, но есть.
Можно нагородить такой запрос, который будет медленнее 2—3 простых.
Но очень вряд ли вы сможете нагородить такой запрос, который будет медленнее 10 и более простых — накладные расходы просто перевесят. ну, у меня, по крайней мере, так никогда не получалось )))
Даже сложные запросами с кучей джойнов, юнионами, конкатенациями и прочими приблудами получаются быстрее.
Чем больше запросов — тем больше накладных расходов, они и пожирают время и ресурс.
Ну 1000 это в качестве примера (хотя и такое случается, когда, например аггрегируешь френдленту, как вконтакте — фотографии, лайки, комментарии, это все собирается, группируется и т.п. — данных очень много).
Даже если 100 или 50 (что случается часто) — на каждую строку делать еще 3—4 запроса это кощунство.
Нет, тут уж каждому свое, но я люблю когда все работает быстро и мне выносит мозг, когда на генерацию страницы уходит по 60—100 запросов.
* не дописал
Так вот.
Если вы выбираете 1000 строк с 3—4 ключами в каждой — вам прийдется сделать 3—4 тысячи запросов.
Какой бы не особо быстрый WHERE IN не был, он в любом случае будет быстрее.
Да и вообще, делать больше 5 (ну максимум 10) запросов в базу на страницу я считаю ужасным, за исключением редких, особо сложных случаев.
»»запросы по ключам тянут по 1 записи
— это ужасно.
я бы сделал (да и часто так делаю) — после получения данных из основной таблицы, пройтись по результатам, собрать нужные айдишники и через WHERE IN их повыдергивать, потом собрать в цикле.
тогда кол-во запросов сокращается до кол-ва ключей, а не равняется кол-ву ключей, помноженному на кол-во записей.
Я, на самом деле, делал все очень просто и практически в лоб:
Один из нюансов — нужно было разбивать карту на секторы по размеру иконки фотогрфии на карте и внутри этого сектора вывести фото с самым высоким рейтингом — т.е. запросы на заполнение секторов получаются не максимально простые и, соответственно, не максимально быстрые.
Я привязывался к координатам тайлов яндекс.карт и для каждого тайла на разных масштабах делелась отдельная выборка с простейшим ln y и т.п.
А затем складывал в кеш по номеру тайла и масштабу. Всё.
В моем случае был обычный кеш (хватало, т.к. охват только страны), если нужно больше (по миру) можно класть в Redis или вообще Tokio/Cabinet или что-то такое супер-быстрое.
Затем при загрузке яндекс.карт вытягиваем масштаб и номера видимых тайлов и запрашиваем. При перемещении кары — дозапрашиваем тайлы, которые проявились.
Практика показала, что работает такой подход очень замечательно. Запросов в базу самый минимум, издержки на получение тайла по номеру — ессно минимальные.
В общем, просто и быстро
Я для iloveukraine.com.ua тоже делал размещение большого кол-ва фотографий на карте, как у Panoramino.
Все никак не выкрою время статью написать об этом.
Спасибо, что напомнили об этой теме, нужно в график воткнуть несколько часов на это дело :)
Или действительно не видите разницы между цепочкой связанных экранов в винфо и раздельными самостоятельными экранами с боковым глобальным меню, вызываемым кнопкой или жестом, описанным в статье?
Фейсбук создал тренд и ничего обещнго с обрезками в винфо он не имеет
тонкая настройка производительности нужна далеко не каждому проекту, но это не значит, что их нужно растрачивать направо и налево не задумываясь
Тут спор, можно сказать, извечный) Кеширование решает, но я считаю, что это — «крайний этап оптимизации». Т.е. производительность на всех этапах должна быть высокой, а кеширование — это финальный штрих.
Ведь то же кеширование применимо отнюдь не всегда. Иногда данные нужно получать без задержек. И тут уже эти ваши 800 запросов на каждый клиент уложат сервер бд на раз-два, как туда зайдет несколько десятков человек.
Собственно, возможно, это мой фетиш.
Я не использую ORM вообще как раз потому что они жутко медленные. Я и тяжелые фреймворки, вроде симфони или зенда, не люблю. Делаю все на кодигнайтере, который обладает великолепным балансом функциональности, удобства и производительности.
Но все же с WHERE IN поиграйтесь — он очень сильно сэкономит ресурсы. А перебор по массивам в пхп — быстрый.
Можно нагородить такой запрос, который будет медленнее 2—3 простых.
Но очень вряд ли вы сможете нагородить такой запрос, который будет медленнее 10 и более простых — накладные расходы просто перевесят. ну, у меня, по крайней мере, так никогда не получалось )))
Даже сложные запросами с кучей джойнов, юнионами, конкатенациями и прочими приблудами получаются быстрее.
Чем больше запросов — тем больше накладных расходов, они и пожирают время и ресурс.
Даже если 100 или 50 (что случается часто) — на каждую строку делать еще 3—4 запроса это кощунство.
Нет, тут уж каждому свое, но я люблю когда все работает быстро и мне выносит мозг, когда на генерацию страницы уходит по 60—100 запросов.
Так вот.
Если вы выбираете 1000 строк с 3—4 ключами в каждой — вам прийдется сделать 3—4 тысячи запросов.
Какой бы не особо быстрый WHERE IN не был, он в любом случае будет быстрее.
Да и вообще, делать больше 5 (ну максимум 10) запросов в базу на страницу я считаю ужасным, за исключением редких, особо сложных случаев.
— это ужасно.
я бы сделал (да и часто так делаю) — после получения данных из основной таблицы, пройтись по результатам, собрать нужные айдишники и через WHERE IN их повыдергивать, потом собрать в цикле.
тогда кол-во запросов сокращается до кол-ва ключей, а не равняется кол-ву ключей, помноженному на кол-во записей.
© из уже упомянутого Лабиринта Отражений
»»отдельная выборка с простейшим ln y и т.п.
в общем, вхождение координат в границы тайла, простым больше-меньше
Один из нюансов — нужно было разбивать карту на секторы по размеру иконки фотогрфии на карте и внутри этого сектора вывести фото с самым высоким рейтингом — т.е. запросы на заполнение секторов получаются не максимально простые и, соответственно, не максимально быстрые.
Я привязывался к координатам тайлов яндекс.карт и для каждого тайла на разных масштабах делелась отдельная выборка с простейшим ln y и т.п.
А затем складывал в кеш по номеру тайла и масштабу. Всё.
В моем случае был обычный кеш (хватало, т.к. охват только страны), если нужно больше (по миру) можно класть в Redis или вообще Tokio/Cabinet или что-то такое супер-быстрое.
Затем при загрузке яндекс.карт вытягиваем масштаб и номера видимых тайлов и запрашиваем. При перемещении кары — дозапрашиваем тайлы, которые проявились.
Практика показала, что работает такой подход очень замечательно. Запросов в базу самый минимум, издержки на получение тайла по номеру — ессно минимальные.
В общем, просто и быстро
Все никак не выкрою время статью написать об этом.
Спасибо, что напомнили об этой теме, нужно в график воткнуть несколько часов на это дело :)