|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Sergey Tkachuk 2:5040/33.50 25 Mar 2001 13:58:00
To : Andrew Evdokimov
Subject : Re: Хoчу заделать WebServer
--------------------------------------------------------------------------------
21 Мар 01 09:07, you wrote to me:
ST>> Какую полезную информацию, кроме заказов, может дать для
ST>> бэк-офиса веб-сайт? Или статистику ты тоже относишь к back
ST>> office? Да и то, все что им надо - логи.
AE> Статистика кому нужна? Маркетологам, например. Давать им читать логи?
AE> Они их не поймут. Если поймут - могут узнать многое, что им знать не
AE> нужно. Логи нужно обрабатывать и приводить в удобоваримый вид. С
AE> другой стороны, некоторые вещи возможно считать в автоматическом
AE> режиме, основываясь на статистике. Кто это, по-твоему, должен считать?
AE> Front-офис? Ему есть чем заняться.
А я тебе о чем говорю? Связи между ними очень мало. Все, что есть - несколько
тоненьких ручейков (товары/заказы/логи).
AE>>> Да не в трафике же дело, е-мое! Дело в сложности back-офиса как
AE>>> программного продукта.
ST>> Кто-то спорит? Речь о том, что бэк-офис - вещь, малосвязанная с
ST>> сайтом. В принципе, веб-сайт мало чем отличается от обычного
ST>> торгового места. Или ты в каждый кассовый аппарат тоже по
ST>> back-офису пихать предложишь? :-)
AE> Каждый кассовый аппарат должен быть включен в единую сеть продаж и
AE> передавать всю информацию о транзакциях на центральный сервер.
Можно и так. Если есть возможность. В подавляющем количестве случаев такой
возможности нет :-)
Ты сам прекрасно показал, что веб-сайт, back-office и статистика - вещи
малосвязанные. Кипучая деятельность внутри каждой части совершенно незаметна в
других. Более того, отсутствие любой из этих частей практически никак не влияет
на работу остальных.
ST>>>>>> Hу и нафига при листании нужны транзакции?
AE>>>>> Дело не в транзакциях, дело в сложности запроса. Отображение 1
AE>>>>> страницы каталога в моем случае - это вложенный запрос, внутри
AE>>>>> которого join'ы из 6, если не изменяет память, таблиц.
ST>>>> И чем тут плох MySQL? Подзапросов, конечно, не хватает, но это
ST>>>> не смертельно.
AE>>> Дело в нагрузке на сервер.
ST>> И чем тут плох MySQL? Речь ведь не идет о миллионах посетителей
ST>> в день?
AE> Hесколько раз падал оракл из-за перегрузки. Hесколько десятков тысяч
AE> посетителей в день достаточно.
Ты хочешь сказать, что оракл настолько плох? Hи за что не поверю.
Я тут наблюдаю писюк (P3/733Mhz/256Mb/Linux/Apache/PHP с кешем/MySQL), который
без какого-либо напряжения (LA не поднимается больше 1.5 даже в пиковые часы)
держит около 400-600 тысяч обращений, каждое из которых выливается в 5-10 плохо
оптимизированных SQL-запросов, 2-3 из которых - апдейты.
Homer
---
* Origin: WWW.LOVEHATE.RU - ВЫСКАЖИСЬ! (2:5040/33.50)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
