Сейчас нет - нет необходимости (это же для моего собственного сайта)
Но для "старых броузеров" или для всяких IE6 без ActiveX создаётся тэг script с аттрибутом src - это и есть способ для кроссдоменных запросов.
Да это не то, чтобы проблема. Она если и появится, то очень не скоро - покупку нового сервера ещё никто не отменял =)
Файлы очень маленькие (размер - до 10Кб). Для формирования средней страницы нужно около тысячи обращений к файлам. Так получилось после наворотов админки для верстальщика - ему стало удобно и количество файлов начало расти как снежный ком =)
Через nfs уже работает.
У нас есть сервер, где лежат оригиналы файлов. Есть каталог, в котором в обшей сложности около 20 тысяч файлов. Есть несколько рабочих серверов с Apache+PHP. Для формирования любой страницы сайта нужно произвести очень много операций чтения из этого каталога.
По сути ответом на Ваш вопрос будет "очень хочется минимизировать количество файловых операций (чтобы было не через сеть + чтобы было не с физического диска". Если внедрить подобное "зеркалирование", то производительность очень возрастёт (это факт) + не нужно будет ничего переделывать.
Притворюсь, что мы с тобой этого не обсуждали и всё равно тут напишу:
В запросе
SELECT `records`.`id` , `records`.`name` FROM `records` , `user_references` WHERE `records`.`public` =0 AND `records`.`us_id` = `user_references`.`us_id` AND `records`.`access` & `user_references`.`mask` AND `user_references`.`cor_id` =$us_id UNION SELECT `records`.`id` , `records`.`name` FROM `records` WHERE `public` =1
Нет ни дополнительного условия WHERE, ни ORDER BY, ни LIMIT. Если их добавить к запросу, то имхо, для обработки UNION будет использоваться filesort (а это не есть гуд)
Мне кажется, что если чел не помнит какую-то мелочь (синтаксис или название функции), и знает где и как это найти, то можно считать, что он знает матчасть.
Скорее решение этой задачи покажет как чел умеет оптимизировать MySQL (а ему нужно сообразить, что рекурсивно эту задачу делать нельзя и исходя из этого соображения он должен придумать правильную структуру таблицы с коментами) + конечно, он должен придумать как это дерево хранить в массиве и как заполнять этот массив =)
Когда я принимал людей я, в качестве одной из тестовых заданий, давал задачу на построение дерева коментариев + генератор N коментариев и отпускал домой. Когда чел приходил, я увеличивал N на 3 порядка и спрашивал почему тормозит =) В процессе общения выяснялось что это за чел
ЗЫЖ Кстати, я бы не решил бы задачу номер 2 (я смог бы только угадать правильный ответ =) За 6 лет ini_set мне ни разу не пригодилась
Это просто удобно (по крайней мере мне при работе в FAR-е). Сейчас посчитал: в моём текущем проекте 26 спец.файла, 145 файлов js и 28 css. Если использовать первый способ, то они все просто не уберутся в GET запрос, не нужно менять весь путь к файлу, если в проект добавляется сразу много файлов, да и просто для разделения сущностей: в один каталог кладём ядро, в другой - абстрактные классы, в третий - реализации абстрактных классов.
где изменим?
В шаблонах. В нашей админке мы просто меняем одну константу и все файлы для всех пользователей становятся "как будто бы новыми"
JS Builder не решает третью задачу, точнее превращает её решение в проблему, а вторая задача полностью ложится на плечи разработчиков (т.е. это не автоматическое решение).
FrontEnd (nginx) настроен так, что если файл есть, то он его и отдаёт + в заголовках посылает броузеру команду "закэшировать файл навсегда" + он может сжимать файлы (у нас правда они не сжимаются - были какие-то проблемы с IE6)
Если файла нет, то nginx передаёт управление в BackEnd (Apache+PHP). PHP анализирует $REQUEST_URI и соединяет файлы /ver/1.1.js и /habr/1.js и записывает из на диск чтобы при следущем запросе его подхватил nginx
Если нужно подцепить сразу несколько файлов, то на FTP кладётся специальный файлик со списком нужных файлов. Например, http://www.moskva.com/jas/ver,1.1.js;hab… сформирован из 2-х файлов.(/habr/1.js и /habr/2.js)
Для отладки к URL`у добавляется специальный параметр - он даёт команду PHP "не записывать результат на диск"
В процессе разработки никто не жаловался - всем нашим нравится такая система =)
ЗЫЖ Наша реализация - это переделка вот этого решения <- так как там сделано делать нельзя =)
Ставим\включаем mod_deflate или mod_gzip для apache и всё! весь ваш контент будет сжат автоматом (почти :) ).
Лучше всего не заставлять апач выполнять лишнюю работу - его задача сгенерить динамику, быстро отдать лёгкому проксирующему серверу! Чем быстрее он это сделает, тем легче будет серваку.
nginx может сжимать файлы по Content-Type: text/html можно жать всегда, а для css и js где-то толи в доках, толи в поставляемых файлах есть пример использования (там IE6 иногде не понимает сжатый контент)
Если не учитывать экономической составляющей, то +1
Я бы сказал "Не изобретай велосипед, если нужно сделать стандартные вещи, и сделать это нужно очень быстро"
Prototype.js очень распространён, поэтому самый главный бонус - это "всё, что может придумать заказчик уже реализовано до нас" - осталось это найти и начать использовать (я даже не говорю про миллион раз оттестированный код и тучу полезных функций работы с массивами, строками, DOM и т.д.)
Опытным путём, конечно всё можно сделать =) Но ведь аргумент про уменьшение приемников является основой всех размышлений. И только в случае когда эффект от уменьшения намного превысит недостатки метода, его стоит повсеместно использовать.
Кстати, а зачем оптимизировать onclick ? Ведь человек мышкой кликает с гораздо меньшей скоростью, чем работает программа =)
Интересно, а чем подкреплён агрумент "Чем меньше приемников событий прикреплено к документу, тем лучше. Они все загружаются в память и в чрезвычайных случаях могут сильно замедлить работу браузеров." ? И как определить то количество приемников, которое действительно будет тормозить броузер ? (один приемник не тормозит, два не тормозит... А сто приемников ? А десять тысяч приемников ?)
Допустим, что тысяча приемников событий действительно тормозят броузер и возьмём какую-нибудь страницу с функциональностью gmail.com. Тогда последний приведённый код внесёт в код как минимум неразбериху и нечитаемость кода =(
Плюс к тому: представьте себе в функции MMNav.init тысячу разных алгоритмов обработки событий в одном месте. Конструкции типа "если объект такой-то, то делаем это иначе если..." не только не ускорят обработку событий, но и начисто подвесят любой броузер.
Мы как-то раз пробовали использовать этот метод (немного его доработав):
1) Для удобства разработки разбили css и js файлы на маленькие части
2) В оригинале массив файлов формировался из запроса, у нас - из сформированного массива PHP, в котором все маленькие части и собирались.
Хочу сказать, что это была ошибка =( Когда Apache начинал тормозить (по разным причинам), файлы js и css грузились очень по долгу, от чего страница визуально вообще не отображалась.
Проблему решили так:
1) В .htaccess настроили mod_rewrite: если файла нет, передавать $REQUEST_URI в PHP
2) В PHP файле (в нашем варианте combine.phps) добавили создание статичного файла чтобы он был доступен по запрашиваемому URLу
3) Настроили nginx: если нет файла, передавать запрос дальше в Apache
4) Сжатие через nginx делать не стали - были проблемы с некоторыми версиями IE6
Но для "старых броузеров" или для всяких IE6 без ActiveX создаётся тэг script с аттрибутом src - это и есть способ для кроссдоменных запросов.
Файлы очень маленькие (размер - до 10Кб). Для формирования средней страницы нужно около тысячи обращений к файлам. Так получилось после наворотов админки для верстальщика - ему стало удобно и количество файлов начало расти как снежный ком =)
У нас есть сервер, где лежат оригиналы файлов. Есть каталог, в котором в обшей сложности около 20 тысяч файлов. Есть несколько рабочих серверов с Apache+PHP. Для формирования любой страницы сайта нужно произвести очень много операций чтения из этого каталога.
По сути ответом на Ваш вопрос будет "очень хочется минимизировать количество файловых операций (чтобы было не через сеть + чтобы было не с физического диска". Если внедрить подобное "зеркалирование", то производительность очень возрастёт (это факт) + не нужно будет ничего переделывать.
В запросе
Нет ни дополнительного условия WHERE, ни ORDER BY, ни LIMIT. Если их добавить к запросу, то имхо, для обработки UNION будет использоваться filesort (а это не есть гуд)
ЗЫЖ Кстати, я бы не решил бы задачу номер 2 (я смог бы только угадать правильный ответ =) За 6 лет ini_set мне ни разу не пригодилась
Это просто удобно (по крайней мере мне при работе в FAR-е). Сейчас посчитал: в моём текущем проекте 26 спец.файла, 145 файлов js и 28 css. Если использовать первый способ, то они все просто не уберутся в GET запрос, не нужно менять весь путь к файлу, если в проект добавляется сразу много файлов, да и просто для разделения сущностей: в один каталог кладём ядро, в другой - абстрактные классы, в третий - реализации абстрактных классов.
В шаблонах. В нашей админке мы просто меняем одну константу и все файлы для всех пользователей становятся "как будто бы новыми"
Пойду пну админа по этому поводу.
JS Builder не решает третью задачу, точнее превращает её решение в проблему, а вторая задача полностью ложится на плечи разработчиков (т.е. это не автоматическое решение).
Мы сделали по своему. И я так думаю, что мы справились со всеми тремя задачами на 100%. Вот ссылка:
http://www.moskva.com/jas/ver,1.1.js;hab…
В процессе разработки никто не жаловался - всем нашим нравится такая система =)
ЗЫЖ Наша реализация - это переделка вот этого решения <- так как там сделано делать нельзя =)
Лучше всего не заставлять апач выполнять лишнюю работу - его задача сгенерить динамику, быстро отдать лёгкому проксирующему серверу! Чем быстрее он это сделает, тем легче будет серваку.
nginx может сжимать файлы по Content-Type: text/html можно жать всегда, а для css и js где-то толи в доках, толи в поставляемых файлах есть пример использования (там IE6 иногде не понимает сжатый контент)
nginx или lighttpd гораздо эффективнее справляются с этой задачей.
Я бы сказал "Не изобретай велосипед, если нужно сделать стандартные вещи, и сделать это нужно очень быстро"
Кстати, а зачем оптимизировать onclick ? Ведь человек мышкой кликает с гораздо меньшей скоростью, чем работает программа =)
Допустим, что тысяча приемников событий действительно тормозят броузер и возьмём какую-нибудь страницу с функциональностью gmail.com. Тогда последний приведённый код внесёт в код как минимум неразбериху и нечитаемость кода =(
Плюс к тому: представьте себе в функции MMNav.init тысячу разных алгоритмов обработки событий в одном месте. Конструкции типа "если объект такой-то, то делаем это иначе если..." не только не ускорят обработку событий, но и начисто подвесят любой броузер.
Мы как-то раз пробовали использовать этот метод (немного его доработав):
1) Для удобства разработки разбили css и js файлы на маленькие части
2) В оригинале массив файлов формировался из запроса, у нас - из сформированного массива PHP, в котором все маленькие части и собирались.
Хочу сказать, что это была ошибка =( Когда Apache начинал тормозить (по разным причинам), файлы js и css грузились очень по долгу, от чего страница визуально вообще не отображалась.
Проблему решили так:
1) В .htaccess настроили mod_rewrite: если файла нет, передавать $REQUEST_URI в PHP
2) В PHP файле (в нашем варианте combine.phps) добавили создание статичного файла чтобы он был доступен по запрашиваемому URLу
3) Настроили nginx: если нет файла, передавать запрос дальше в Apache
4) Сжатие через nginx делать не стали - были проблемы с некоторыми версиями IE6