- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Еще есть связка MSSQL+C (C++/C#) - тоже с тяжелыми задачами справляется хорошо. Работал с этим - тянуло обработку платежей моб.операторов, услуг от множества сетей плат.терминалов в реальном времени, с отчетами, статистикой, анализом через веб-сервисы.
Такая связка немного шустрее засчет копилируемости C/C# и удобнее в создании (я про .net framework) - много вещей уже готово, только все равно мозги нужны, а то viewstate порой у людей в десятки килобайт получаются :)
MSSQL будет значительно шустрее MySQL только уж на очень специфических задачах.
как строится высоконагруженное приложение?
обычно, нагруженное приложение - это система, работающая по следующему принципу
1. index.php через htaccess получает все запросы вида http://example.com/ru/news/2009/03/04/
2. в index.php создается объект класса Router, в котором анализируется URL ru/news/2009/03/04/ и смотрится, какой класс дальше использовать для построения страницы
А каким боком это касается HI LOAD solutions?
BoyStav добавил 06.03.2009 в 16:17
Также я советую отказаться от MySQL и смотреть в сторону MSSQL и Oracle.
MySQL валится уже на 100 запросах в секунду.
Кроме того, нужно строить индексы в базах данных, и по возможности не использовать джойн запросов по выбору из нескольких таблиц.
Плюс к этому вы можете использовать ядро, написанное не на пхп, но это существенной скорости не даст.
спасибо посмеялся, особенно понравились характеристика мускула и высказывание про запросы!
BoyStav добавил 06.03.2009 в 16:23
скажите, если из mysql данные кэшировать таким способом:
1. мюскул запрос
2. сохранение файла мд5(запрос);
3. проверка при вызове этого запроса, если тру то выводить данные из файла "мд5(запрос)"
скажите на сколько такая система кэширования мюскула удобна, нагрузку на мускул снижает но что будет например при тех же 500 запросах в сеукнду? может как то по другому кэш хранить?
кеширование данных из мускула в файлы - бред, пользы не будет, память да, файлы нет!
BoyStav добавил 06.03.2009 в 16:25
если на запрос тратится 20 мсек - то в секунду будет всего 50 страниц, а не 500 ;)
а вы пробовали мыслить в категориях паралельной обработки?
да на один запрос тратиться 20 милисикунд, но за эти 20 милисекунд может быть обработанна не одна тысяча запросов.
BoyStav добавил 06.03.2009 в 16:28
Такая связка немного шустрее засчет копилируемости C/C# и удобнее в создании (я про .net framework) - много вещей уже готово, только все равно мозги нужны, а то viewstate порой у людей в десятки килобайт получаются :)
MSSQL будет значительно шустрее MySQL только уж на очень специфических задачах.
не любой PHP кешер решает проблему постоянной интерпретации, насчет компиляции это да, АСП.НЕТ компилиться раз. Но и байткод PHP достаточно быстр.
Насчет фреймвока, так есть zend framework, посмотрите на досуге, продукт достойный.
MSSql будет быстрее только на действительно сложных запросах.
А каким боком это касается HI LOAD solutions?
BoyStav добавил 06.03.2009 в 16:17
спасибо посмеялся, особенно понравились характеристика мускула и высказывание про запросы!
BoyStav добавил 06.03.2009 в 16:23
кеширование данных из мускула в файлы - бред, пользы не будет, память да, файлы нет!
BoyStav добавил 06.03.2009 в 16:25
а вы пробовали мыслить в категориях паралельной обработки?
да на один запрос тратиться 20 милисикунд, но за эти 20 милисекунд может быть обработанна не одна тысяча запросов.
BoyStav добавил 06.03.2009 в 16:28
не любой PHP кешер решает проблему постоянной интерпретации, насчет компиляции это да, АСП.НЕТ компилиться раз. Но и байткод PHP достаточно быстр.
Насчет фреймвока, так есть zend framework, посмотрите на досуге, продукт достойный.
MSSql будет быстрее только на действительно сложных запросах.
зенд совершенно не подойдет для нагруженного сайта.. надеюсь, кто захочет понять почему - разберется :)
что касается роутера - я привел как пример реализации хайлоада с mvc... а ваш пост является обычным флеймом, к сожалению... никакой конкретики
я привел как пример реализации хайлоада
пример с роутером нисколько не относится к хайлоадам.
скорее даже наоборот - вы сервер ещё и реврайтом нагружаете. ;)
не любой PHP кешер решает проблему постоянной интерпретации, насчет компиляции это да, АСП.НЕТ компилиться раз. Но и байткод PHP достаточно быстр.
Спору нет :)
У самого где надо eAccelerator включен :)
Это вы таки точно мне? ;)
Именно это и я писал. 🍻
То, что "продвинутые" возможности у MSSQL намного выше - это понятно, только вот как много людей юзают тот же OLAP?
зенд совершенно не подойдет для нагруженного сайта.. надеюсь, кто захочет понять почему - разберется :)
что касается роутера - я привел как пример реализации хайлоада с mvc... а ваш пост является обычным флеймом, к сожалению... никакой конкретики
не хочу вас расстраивать, но зенд не только подойдет, он вовсю используется...
мой пост является опровержением говна которого навалили в теме, вполне конкретным опровержением.
П.С. я не проф ПХП программист, я больше по микрософтовским технологиям, но просто не могу пройти мимо такой насущьной темы. особенно когда какие то дети (с точки зрения разработки) пытаются ищущему навязать ложное представление о мире!
BoyStav добавил 07.03.2009 в 02:43
Это вы таки точно мне? ;)
Именно это и я писал. 🍻
То, что "продвинутые" возможности у MSSQL намного выше - это понятно, только вот как много людей юзают тот же OLAP?
1) да я откуда знаю, кто то заявил мол у ДН ФВ все уже есть, я поправил, что у ЗФВ тоже все есть :)
2) ну собственно ОЛАП редко кому нужен при разработке веб приложений, а вот развитые механизмы встраивоемой логики это да!
кеширование данных из мускула в файлы - бред, пользы не будет, память да, файлы нет!
А если страница полностью ложится в кеш? В этом же случае, я думаю, проблем меньше будет. Конечно, учитывая, что в некоторых случая уже сам кеш будет создавать нагрузку на файловую систему, тем более если всё хранить в одной папке.
если всё хранить в одной папке.
Какая разница где хранить... файловые системы не очень-то оптимизированы для произвольного доступа к данным небольших размеров. К ним более другие требования предъявляются...
файловые системы не очень-то оптимизированы для произвольного доступа к данным небольших размеров
А ReiserFS, ну или Reiser4? Если отбросить неопределённое будущее этой файловой системы?
А ReiserFS, ну или Reiser4? Если отбросить неопределённое будущее этой файловой системы?
Ну возьмите десяток тысяч страниц и проведите эксперимент - ReiserFS против MySQL