Не переживайте за нас, никого не уволили.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
1. Есть ли гарантии, что мы не забудем раздать всем сестрам по серьгам всем нужным юзерам?
2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
А смысл? Подключение таким образом скрипта всё равно, как правило, из другого файла. А для него и счетчик сойдет.
Тем более, что в этом файле наверняка подключается несколько разных скриптов/файлов стилей, так что для каждого будет свой номер.
Вот пример с одного из моих проектов: />
<script type="text/javascript" src="/js102/common.js"></script>
<script type="text/javascript" src="/js112/context_help.js"></script>
<script type="text/javascript" src="/js116/complaint_script.js"></script>
<script type="text/javascript" src="/js034/plugin_fly.js"></script>
Эээ? В указанном подходе Вам будет достаточно менять то, что находится вместо звездочки.
Увеличивайте ручками на единицу и не заморачивайтесь.
При наличии нормального шаблонизатора это делается ровно в одном месте и занимает порядка 3 секунд.
Какой-то ппц пятничный.
Всё описанное реализуется одной строкой кода в каком-нить акселераторе типа 0w или nginx'а и использованием нормального шаблонизатора.
Да не надо в базе аватары хранить. И даже пути к ним — не надо. Головой думать надо.
данный [способ]… не создает лишней нагрузки.
На сервер — практически не создает, да. На сеть и клиента — создает. Второе даже более критично. Юзер будет ждать пока загрузятся несуществующие аватары (открою секрет — они не могут грузиться браузером все одновременно, существуют ограничения на соединения с одним хостом). Считайте это законом сохранения нагрузки — если где-то нагрузки убывает, значит где-то ее прибывает. Вы и перекладываете с больной головы на здоровую.
Уважаемый И.Сысоев писал о том, что nginx сопобен выдержать 10 000 запросов в секунду
Тут ко мне на собеседование приходил один товарищ, утверждал, что написал софт, который выдерживает до 70 тысяч запросов в секунду… А еще я слышал, что Петя Зайцев Мускулом Оракл порвал… Дальше-то что? По-любому, если нгинксу надо выдерживать не N запросов, а 10*N, то эт несколько хуже. Даже если не отражается на нагрузке.
Опираясь на ваш коммент, вы знаете 2 способа
Эт я Вам по доброте душевной два рассказал. Могу больше. Консультации оплатите?
напиши хоть один положительный коммент, а лучше пост, подчеркну, положительный. Достал плакаться.
Положительные посты — это не ко мне.
О своих успехах я не распространяюсь, а ближнего пнуть на путь истинный — милое дело.
Мой способ не юзает базу, работает отдельно, по сути не требует её наличия
В Вашем способе, как и в способах, предложенных в этом топике, присутствует хранилище. Хоть база, хоть мемкеш, хоть файловая система — суть одно. Эффективность доступа к любому из них будет разная в разных проектах. И выбирать конкретный метод — дело архитектора.
Приведу пример.
Если сервис изначально целиком динамический, кеширование применяется незначительно, за данными постоянно нужно ходить в базу, то заложив при проектировании одно поле в таблицу юзеров для различных флагов (а наличие аватара — всего лишь флаг), можно прекрасно обойтись без излишних запросов, выводя где нужно аватар, где его нет — дефолтную картинку, прекрасно кешируемую в браузере. $flags & 0x1 — очень быстрая операция сравнения.
Второй пример.
Сайт — практически статика (или хорошо кешированная динамика), в базу решено ходить по минимуму, мемкеш не нужен, ибо особо нечего там держать, да и лишняя прослойка. Тогда вариант решения — переложить логику отдачи аватаров на быстрый акселератор (например, nginx), повесить его на отдельный ip, врубить небольшой кип-элайв и отдавать аватары в рамках одной TCP-сессии. И всё-таки отправлять команду их кешировать. Хотя бы на среднее время ежедневной жизни на сайте среднего пользователя проекта.
Вы упираетесь в один метод.
Я — знаю несколько методов и могу заранее выбрать подходит ли мне какой-то из них.
Мой подход — правильней.
Сравнивая одни и те же вещи в разных СУБД, очень заметно как сильно уступает Мускул Постгресу и Ораклу.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
Но только, если уже был сделан DROP процедуры, в этом списке этой процедуры не будет.
Особенно, в части работы с перлом.
1. Есть ли гарантии, что мы не забудем раздать
всем сестрам по серьгамвсем нужным юзерам?2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
В крайнем случае, замена счетчика в N файлах — одна строка на bash с использованием find + grep + sed + awk
Тем более, что в этом файле наверняка подключается несколько разных скриптов/файлов стилей, так что для каждого будет свой номер.
Вот пример с одного из моих проектов:
/>
<script type="text/javascript" src="/js102/common.js"></script>
<script type="text/javascript" src="/js112/context_help.js"></script>
<script type="text/javascript" src="/js116/complaint_script.js"></script>
<script type="text/javascript" src="/js034/plugin_fly.js"></script>
Достигается ровно то же самое, что предложили Вы, но без излишнего кода.
Можете писать в шаблонах хоть /css/001/style.css, хоть /js002/button.js
Увеличивайте ручками на единицу и не заморачивайтесь.
При наличии нормального шаблонизатора это делается ровно в одном месте и занимает порядка 3 секунд.
Всё описанное реализуется одной строкой кода в каком-нить акселераторе типа 0w или nginx'а и использованием нормального шаблонизатора.
На сервер — практически не создает, да. На сеть и клиента — создает. Второе даже более критично. Юзер будет ждать пока загрузятся несуществующие аватары (открою секрет — они не могут грузиться браузером все одновременно, существуют ограничения на соединения с одним хостом). Считайте это законом сохранения нагрузки — если где-то нагрузки убывает, значит где-то ее прибывает. Вы и перекладываете с больной головы на здоровую.
Тут ко мне на собеседование приходил один товарищ, утверждал, что написал софт, который выдерживает до 70 тысяч запросов в секунду… А еще я слышал, что Петя Зайцев Мускулом Оракл порвал… Дальше-то что? По-любому, если нгинксу надо выдерживать не N запросов, а 10*N, то эт несколько хуже. Даже если не отражается на нагрузке.
Эт я Вам по доброте душевной два рассказал. Могу больше. Консультации оплатите?
О своих успехах я не распространяюсь, а ближнего пнуть на путь истинный — милое дело.
В Вашем способе, как и в способах, предложенных в этом топике, присутствует хранилище. Хоть база, хоть мемкеш, хоть файловая система — суть одно. Эффективность доступа к любому из них будет разная в разных проектах. И выбирать конкретный метод — дело архитектора.
Приведу пример.
Если сервис изначально целиком динамический, кеширование применяется незначительно, за данными постоянно нужно ходить в базу, то заложив при проектировании одно поле в таблицу юзеров для различных флагов (а наличие аватара — всего лишь флаг), можно прекрасно обойтись без излишних запросов, выводя где нужно аватар, где его нет — дефолтную картинку, прекрасно кешируемую в браузере. $flags & 0x1 — очень быстрая операция сравнения.
Второй пример.
Сайт — практически статика (или хорошо кешированная динамика), в базу решено ходить по минимуму, мемкеш не нужен, ибо особо нечего там держать, да и лишняя прослойка. Тогда вариант решения — переложить логику отдачи аватаров на быстрый акселератор (например, nginx), повесить его на отдельный ip, врубить небольшой кип-элайв и отдавать аватары в рамках одной TCP-сессии. И всё-таки отправлять команду их кешировать. Хотя бы на среднее время ежедневной жизни на сайте среднего пользователя проекта.
Вы упираетесь в один метод.
Я — знаю несколько методов и могу заранее выбрать подходит ли мне какой-то из них.
Мой подход — правильней.
А кунфу сильнее, угу.
А Вас я поправил исключительно для того, чтобы те, кто будет читать всё это, не повторяли Ваших ошибок. И читали мануалы.