Latest post of the previous page:
Вы просто не в теме.Система на коленке - это не так плохо. Намного лучше чем отсутствие системы.
Latest post of the previous page:
Вы просто не в теме.С этим не спорю. Но когда есть прекрасный образец, почему его не использовать?Система на коленке - это не так плохо. Намного лучше чем отсутствие системы.
Поясню. Вот Вы запускаете сайт - сразу появляется нагрузка (Вам еще предстоит узнать что нагрузку дают не только пользователи, но и живых людей будет не мало). Наличие репозитария популярность Far приподнимет - нагрузка вырастет еще. Далее сайт начнет притормаживать - удобство использования снижается - пользователи уходят.Каким?
1. Если речь идет о моем plagring'e (а других вроде не видно) - то его исходники открыты. Хотите помочь - возьмите их, посмотрите, дайте советы по оптимизации, если будут.Demiurg wrote:И еще - я не стремлюсь с Вами воевать, не надо мои слова воспринимать враждебно (это я на всякий случай). Я Вам предлагаю помощь.
Ну, положим, начинающий я только в PHP. С базами я работаю уже лет 20.Demiurg wrote:1. Исходники я посмотрел. Хотя я на PHP и не пишу, но грабли у начинающих одни и те же )
И? Вы полагаете это будет быстрее чем выбрать запись из базы по первичному ключу? Нафига бы тогда человечество вообще придумало DBMS?Demiurg wrote: Так что с оптимизации и начнем - Вы при запросе страницы плагина лезете в базу (функция db_read_plugin_by_id) потом генерируете блок с описанием для страницы. Однако как часто меняется эта информация? Есть ли нужда её постоянно брать из базы? Конечно нет. Достаточно один раз сгенерировать этот блок и сохранить в кэш (самое простое - на диск). Далее этот блок генерировать только при отсутствии его в кэше, и при обновлении информации о плагине в БД очищать кеш.
Для разработки мне достаточно локального компьютера. Я не собираюсь хостить альтернативный плугринг. Либо он станет официальным, либо умрет.Demiurg wrote:Еще Вы тут жаловались на хостинг - могу предоставить доступ к своему серверу, для разработки.
Смотрю. И что? Если вы посоветуете, как _легко_ сделать так, чтобы форма с GET не формировала пустых параметров, я поправлю. Но вряд ли это повлияет на быстродействие.Demiurg wrote:И еще, посмотрите на это: /plugins?category=%FD&name=&author=&tag=&tag=&tag=&updated=&sortby=1
Возможно. У меня нет опыта общения с монстроузными CMS.Demiurg wrote:2. 500 плагинов автоматом дают 1000 файлов (x86 и x64)
3. Я про MySQL знаю достаточно, и то что можно положить базу на таблице в 1000 строк - совсем не фантастика
Разумеется. Статика всегда отдается быстрее чем динамика и требует меньше ресурсов.И? Вы полагаете это будет быстрее чем выбрать запись из базы по первичному ключу?
А Вы подумайте - почему во всех веб-проектах обращения к БД стараются заменить на обращения к кешу (например к memcached)?Нафига бы тогда человечество вообще придумало DBMS?
Входные параметры нужно проверятьСмотрю. И что?
Да при чем здесь статика/динамика? Вопрос в эффективности доступа к данным. Для БД хранить сотни тысяч/миллионы записей - вообще не проблема. Как у вас будет работать кэш с 100K файлов?Demiurg wrote:Разумеется. Статика всегда отдается быстрее чем динамика и требует меньше ресурсов.И? Вы полагаете это будет быстрее чем выбрать запись из базы по первичному ключу?
У меня есть гипотезы по этому поводу, но я их, пожалуй, озвучивать не буду. А вот Вы подумайте - почему во всех _не_ WEB проектах DBMS как то справляются с нагрузкой, а в WEB вдруг такая проблема. В чем же такая специфика WEB проектов?Demiurg wrote:А Вы подумайте - почему во всех веб-проектах обращения к БД стараются заменить на обращения к кешу (например к memcached)?Нафига бы тогда человечество вообще придумало DBMS?
Так они и проверяются. Сайт не сломался, вы получили собщение об ошибке, что Вам еще надо?Demiurg wrote:Входные параметры нужно проверять
У меня тупорылый безиндексный поиск "по всем полям по всем (200+) таблицам" с динамическим построением запроса к каждой таблице на полгигабайте данных на пеньке 3! лолшто, который, ко всему прочему, обслуживает еще несколько моих не менее тупорылых SMPP и HTTP сервисов и раздает интернет/почту на офис - выполняется мгновенно. Городить огород с кешированием, индексацией по частым запросам итд там, где и так все работает молнеиносно - это ж чистой воды онанизм, не? Возникнут проблемы - появится и решение.Max Rusov wrote:Да при чем здесь статика/динамика? Вопрос в эффективности доступа к данным. Для БД хранить сотни тысяч/миллионы записей - вообще не проблема. Как у вас будет работать кэш с 100K файлов?
Прекрасно будет работать. Как работает хэш-таблица? Вот именно так и будет работать. К тому же это могут быть и не файлы, а memcached.Как у вас будет работать кэш с 100K файлов?
Интересный вопрос. Я даже призадумался. То, что БД в WEB узкое место у меня сомнения не вызывает, как и у многих других WEB-разработчиков. Но вот ПОЧЕМУ?В чем же такая специфика WEB проектов?
А зачем пользователю это сообщение?Сайт не сломался, вы получили собщение об ошибке, что Вам еще надо?
А дисковое пространство - оно бесплатное? Не жирно ли удваивать/утраивать объем базы данных? Еще раз повторю - БД _не_медленная_. Если кто-то не умеет писать эффективные SQL запросы - не стоит делать из этого далекоидущие выводы. А вообще - разговор какой-то академический. К плугрингу то это все каким боком? Вон старый Plugring - вообще на FoxPro. Как то выжил.Demiurg wrote:Интересный вопрос. Я даже призадумался. То, что БД в WEB узкое место у меня сомнения не вызывает, как и у многих других WEB-разработчиков. Но вот ПОЧЕМУ?
Как мне кажется, тут всё дело в цене. Т.е. можно сделать достаточно быструю СУБД (с кластеризацией и т.п.), но вот какова будет цена такого решения? Чую, намного дешевле поставить быстрый кеш на memcached и запрашивать данные из относительно медленной БД только один раз.
А зачем пользователь полез ручками править URL запроса? Ну, полюбуйся на это:Demiurg wrote:А зачем пользователю это сообщение?
Ладно, это отложим.К плугрингу то это все каким боком? Вон старый Plugring - вообще на FoxPro. Как то выжил.
Чтобы сломать сайт, сделать дефейс и показывать это друзьям школьникам.А зачем пользователь полез ручками править URL запроса?