Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 154
К сожаленю ничего ценного подсказать не могу, но желаю удачи ваших начинаниях.
P.S.:сайт должен быть полезным дл япользователя, а не просто демонстрацией технологий.
P.S.:сайт должен быть полезным дл япользователя, а не просто демонстрацией технологий.
"0.5 секунды при отсутствующей посторонней нагрузке" - очень много.
Да и железо, на мой дилетантский(программистский) взгляд - слабое для ской либо посещаемого проекта - особо смущает ЖД.
Да и железо, на мой дилетантский(программистский) взгляд - слабое для ской либо посещаемого проекта - особо смущает ЖД.
Улыбныло то, что осталось меньше тысячи долларов. Предлагаю закупить всем составом на эти деньги свечки, запалить их в ближайшей церкви и усиленно молиться, чтобы дело пошло сразу. Если серьезно, то весьма и весьма опрометчиво подходить к запуску стартапа со столь скромным бюджетом. По моим наблюдениям, ресурсы должны распределяться примерно 40 на 60, разработка и поддержка соответственно.
У нас просто есть надежда, что получится предпринять хорошие ходы, которые позволят поднять проект малой кровью. А какие примерно затраты для организации тысячи посетителей в день, если у нас хороший движок, но, очевидно, пустоватая база на первых порах? Какие посоветуете ходы для этого?
Именно в этом вопросе я врядли вам смогу помочь. Приходит на ум, что для будущей тысячи, необходимо как минимум создать видимость тысячи, которая уже существует! Ну и про классические методы не забывать. Реклама реклама и еще раз реклама.
Не слушай некого, у меня стартап с- $0 бюджетом (ну там $300 за хост и домейн на год) и всё прекрасно работает и продвигается. Самое главное что бы все участники проекта полностью посвятили себя своему делу.
Что так дорого? К примеру хостинг на godaddy.com обойдется для нужд Вашего ресурса — $100 год.
Ну сейчас на стадии разработки как раз на таком и сижу (IX Hosting, $95 - говно редкостное), но через месяц начнётся PR, люди начнут грузить картинки и музон, а я не хочу чтобы у людей сайт грузился 15 секунд.
100 в год? Это shared-хостинг что-ли? Да какой действительно посещаемый проект с shared-а не выкинут за излишнюю нагрузку?
а что у вас за стартап такой??? успешный???
Согласен!!!!!!!!!!
Самое простое - лупануть пару-тройку тысяч в рекламу (баннеры, контекст, сообщения в форумах/блогах и прочее - все методы хороши).
Но я думаю, что при таком количестве народа, которое уже есть в проекте - можно стартовать смело, естественно, при условии, что все работает и более-менее наполнено контентом, налажены связи с партнерами (если надо) и т. п.
Цитирую Archie: Самое главное что бы все участники проекта полностью посвятили себя своему делу
Мысль можно развивать дальше, но и так все понятно!
В результате получаем то, что надо:
1. хороший хостинг
2. сотрудники полностью отданные делу
3. МНОГО качественного и УНИКАЛЬНОГО контента!
Сейчас занимаюсь таким проектом. Принципиально: никакой рекламы, никаких рейтингов/счетчиков и т.д. Что делается: регистрация в поисковиках руками (их не много), регистрация в каталогах при помощи бесплатного пакета на 1ps.ru (но без установки каких либо кнопок и ссылок на каталоги), каждодневное наполнение контентом и разработка новых сервисов, новостная лента (уникальная) которая транслируется на ведущие новостные анрегаторы (Яндекс, Мета и ...). Результат: за пол года, конечно, не 10 тыс. посетителей в сутки (как некоторые ожидают), но своих 1 - 1,5 тыс. уникальных имеем.
Самое простое - лупануть пару-тройку тысяч в рекламу (баннеры, контекст, сообщения в форумах/блогах и прочее - все методы хороши).
Но я думаю, что при таком количестве народа, которое уже есть в проекте - можно стартовать смело, естественно, при условии, что все работает и более-менее наполнено контентом, налажены связи с партнерами (если надо) и т. п.
Цитирую Archie: Самое главное что бы все участники проекта полностью посвятили себя своему делу
Мысль можно развивать дальше, но и так все понятно!
В результате получаем то, что надо:
1. хороший хостинг
2. сотрудники полностью отданные делу
3. МНОГО качественного и УНИКАЛЬНОГО контента!
Сейчас занимаюсь таким проектом. Принципиально: никакой рекламы, никаких рейтингов/счетчиков и т.д. Что делается: регистрация в поисковиках руками (их не много), регистрация в каталогах при помощи бесплатного пакета на 1ps.ru (но без установки каких либо кнопок и ссылок на каталоги), каждодневное наполнение контентом и разработка новых сервисов, новостная лента (уникальная) которая транслируется на ведущие новостные анрегаторы (Яндекс, Мета и ...). Результат: за пол года, конечно, не 10 тыс. посетителей в сутки (как некоторые ожидают), но своих 1 - 1,5 тыс. уникальных имеем.
Вот именно "МНОГО качественного и УНИКАЛЬНОГО контента!". И вопрос откуда он у ребят на стартапе должен взяться.
Главное о чем нужно подумать, это "холодный старт" проекта. То-есть какой он будет представлять интерес для первого пользователя.
К примеру: Делисио - удобный сервис хранения закладок, даже если там нет других пользователей. На Хабре с самого начала работало с десяток авторов регулярно пишущих материалы. Думаю они и сейчас генерирую львиную долю контента.
Если этот шаг не продумать, каков бы не был "движок" и дизайн, ничего не выйдет.
Главное о чем нужно подумать, это "холодный старт" проекта. То-есть какой он будет представлять интерес для первого пользователя.
К примеру: Делисио - удобный сервис хранения закладок, даже если там нет других пользователей. На Хабре с самого начала работало с десяток авторов регулярно пишущих материалы. Думаю они и сейчас генерирую львиную долю контента.
Если этот шаг не продумать, каков бы не был "движок" и дизайн, ничего не выйдет.
Для контента и есть контент-менеджеры. Сами сидят и генерируют контент. А как по другому. Например, у меня на сайте один из разделов "Медицинская консультация" - думаете народ сам рванулся задавать вопросы? (глупость)). Сидели сами задавали/отвечали. Для примера что бы начать раздел консультации я ищу клинику, которая будет вести этот раздел, потом они сами себе (или с нашей помощью) задают 10 вопросов, отвечают на них и т.д. По моему опыту для того что бы народ начал задавать вопросы надо 10 - 15 - 20 готовых вопросов в разделе, а потом смотреть статистику разделов и искусственно подогревать отстающие.
Согласитесь, что если бы вы зашли на хабр и увидели какой он хороший и удобный, НО не увидели, что здесь народ резвится (постит, обсуждает, спорит) - вы бы никогда не стали первым писателем на таком сайте! Т.е. нужна видимость работы, которую и создадут контент-менеджеры, не важно это блог или сервис закладок.
Согласитесь, что если бы вы зашли на хабр и увидели какой он хороший и удобный, НО не увидели, что здесь народ резвится (постит, обсуждает, спорит) - вы бы никогда не стали первым писателем на таком сайте! Т.е. нужна видимость работы, которую и создадут контент-менеджеры, не важно это блог или сервис закладок.
Согласен на все 100. И именно это я и имел виду и советовал автору топика.
Единственно что - вы пишите о контентных и социальных сайтах. И Хабр является по сути таким. Но есть еще и понятие веб сервиса, который может быть полезен и без социальной составляющей. Как, к примеру, соц. закладки. На первом этапе - это просто удобный способ хранения закладок. Даже если кроме тебя никто не использует сервис. На втором - это система рекомендации контента, когда сервисом пользуется много людей.
Единственно что - вы пишите о контентных и социальных сайтах. И Хабр является по сути таким. Но есть еще и понятие веб сервиса, который может быть полезен и без социальной составляющей. Как, к примеру, соц. закладки. На первом этапе - это просто удобный способ хранения закладок. Даже если кроме тебя никто не использует сервис. На втором - это система рекомендации контента, когда сервисом пользуется много людей.
и про закладки тоже самое. для начала контент-менеджеры должны наделать закладок, как это будто реальные посетители наделали, и дальше поддерживать это. опять же не будете же вы закладывать) если до вас никто на этом сайте не закладывал (только что запущенный голый сервис) - сайт должен производить впечатление (и быть таковым) живого и работающего! в моем понимании лента постоянно добавляемых новостей на корпоративных (в первую очередь) сайтах дает посетителю понимание (не могу слова подобрать) того, что фирма действующая и к ним можно обращаться. тоже самое с сервисом. само собой разумеется, что эти, предположим, закладки, по условиям сервиса, смогу просматривать все желающие, а не только автор. Что вообще понимается под понятием соц. закладки? а то у нас сейчас все либо с окончанием 2.0, либо с приставкой Соц. Все равно же это в конечном итоге контент (содержание), т.е. буквы из которых состоят слова, а из слов предложения и т.д.
Вопрос в данном вами описании не имеет ответа в цифрах.
Хороший движок сам по-себе ником не нужен, если Вы не его продаете.
если одна из составляющих Ваших расходов контекстная реклама - то вы можете прикинуть сколько будет стоить 1000 гарантированных посетителей.
Вопрос сколько будет стоить каждый вернувшийся самостоятельно из этой 1000.
Все остальные теоретизирования на тему хватит ли миллиона, без указания темы - вода.
Хороший движок сам по-себе ником не нужен, если Вы не его продаете.
если одна из составляющих Ваших расходов контекстная реклама - то вы можете прикинуть сколько будет стоить 1000 гарантированных посетителей.
Вопрос сколько будет стоить каждый вернувшийся самостоятельно из этой 1000.
Все остальные теоретизирования на тему хватит ли миллиона, без указания темы - вода.
Все зависит еще от того насколько уникален ваш проект и интересен. Если уникален может и поднимите малой кровью. А вот если есть аналоги, то деньги на рекламу, поисковое продвижение - здесь тысячи маловато конечно.
То есть главный вопрос - вы продумали откуда возьмете посетителей?
То есть главный вопрос - вы продумали откуда возьмете посетителей?
Правильно, надежда умирает последней :) А вместе с ней умирают и идеи, возможно ошибочно принятые за идеальные, а потом и сама реализация с тяжелым вздохом и непроизвольными судорогами ложится на смертный одр... Но мы уверены, что надо давать ей лекарства, ставить клизмы...
А если серьезно, не бывает универсальных рецептов, очень многое, если не все, зависит от рынка, темы, потребителей и еще кучи вещей, которые и определяют коммерческий успех
А если серьезно, не бывает универсальных рецептов, очень многое, если не все, зависит от рынка, темы, потребителей и еще кучи вещей, которые и определяют коммерческий успех
свечки? что-то новое! обычно применяют Бубен...
С точки зрения сисадмина скажу, что распределить ресурсы лучше даже 30 к 70. Ведь первоначальная конфигурация обычно используется более-менее дефолтная, а вот в процессе настройки приходится менять довольно часто. Так что правильно сказано Ruberoid'om, что 1 тыс. хватит только на свечки.
Привет колега. Могу тебе посоветовать две вещи:
1. Используй яваскрипт для отображения страниц вместо шаблонов.
2. Оптимизируй количество запросов к БД! JOIN'ы спасут интернет :)
п.с. Я сам в этом деле относительно новичок, но то что я тебе предложил, прекрасно у меня работает.
1. Используй яваскрипт для отображения страниц вместо шаблонов.
2. Оптимизируй количество запросов к БД! JOIN'ы спасут интернет :)
п.с. Я сам в этом деле относительно новичок, но то что я тебе предложил, прекрасно у меня работает.
Минус за джойны. Да, собственно , и за джаваскрипт тоже.
Скажи это гуглу и яху ;)
Джаваскрипт и аякс всё-таки весьма существенно разгружают сервер, начиная с траффика и заканчивая нагрузкой на сервер вследствии уменьшения количества операций при обновлении единственного блока страницы.
Другое дело, что он не всегда уместен.
А без join, view и прочих "прелестей" никакого серьезного проекта не построить вообще. Имхо.
Другое дело, что он не всегда уместен.
А без join, view и прочих "прелестей" никакого серьезного проекта не построить вообще. Имхо.
По поводу разгрузки сервера, тут вы явно переусердствовали. AJAX в настоящий момент нисколько не снижает, а только увеличивает нагрузку на сервер. Тут можно дискутировать, но я спорить даже не стану.
Я не против join, view, sp и прочих "прелестей", я скорее хотел обратить внимание на то, что важна именно правильно спроектированная БД, с правильным и уместным набором индексов в зависимости от задач, четким понимаем планов выполнения запроса, толковой оптимизацией, разнесением задач на мгновенные и отложенные, кэширование. Перечисленные "прелести" ИМХО важнее.
Я не против join, view, sp и прочих "прелестей", я скорее хотел обратить внимание на то, что важна именно правильно спроектированная БД, с правильным и уместным набором индексов в зависимости от задач, четким понимаем планов выполнения запроса, толковой оптимизацией, разнесением задач на мгновенные и отложенные, кэширование. Перечисленные "прелести" ИМХО важнее.
Как именно AJAX загружает сервер простите?
AJAX — асинхронный запрос на сервер. Раз это запрос на сервер, стало быть сервер нагружается. Популярная ныне реализация - подгрузка данных в комбобокс. Раньше пользователи писали сами, без всяких подсказок и ничего жили, и справлялись со своими задачами. Сейчас это дополнительная нагрузка на сервер. Таких примеров можно привести сотни, при этом не забываем так как AJAX исключает "мерцание", это стимулирует пользователя активнее пользоваться динамическими элементами.
Может сложиться мнение что я не сторонник прогресса. Это не так. Я люблю и пытаюсь использовать AJAX, однако иногда гораздо разумнее отказаться от впечатляющей динамики в пользу производительности.
Может сложиться мнение что я не сторонник прогресса. Это не так. Я люблю и пытаюсь использовать AJAX, однако иногда гораздо разумнее отказаться от впечатляющей динамики в пользу производительности.
Ну мы тут про немного разные вещи говорим коллега. Все эти прибамбасы с комбобоксами, это так сказать - фишки (удобства). Я имел в виду другое. Вместо того что бы пхп парсил шаблоны, намного разумнее будет положить эту задачу на яваскрипт. И траффик уменьшится, и нагрузка на сервер.
Эм-м-м, и сколько же данных вы предлагаете выгружать клиенту? Скрипты для парсинга, плюс метра три кода, из которых скриптами будет сформировано 100 килобайт? Я конечно утрирую, но это как мне кажется не верно.
Я вот сейчас по работе столкнулся с задачкой. Конечный пользователь хочет видеть в браузере страницу с отчетом. Не вопрос. Проблема только в том что количество данных в отчете плэйнтекстом весит метра 2 и после формирования таблицы разворачивается на два экрана в ширину на моем вайдскрине и на черт знает сколько экранов в длинну. Так вот парсинг всего этого джваскриптом в красивый редактируемый "на месте" многостраничный интерфейс просто убьет браузер на клиенте. Пример естественно преувеличен - типичный стартап с таким не столкнется, но любителям выгружать все в клиент может стоит задуматься. Не все пользуют инет на навороченых компах. Есть еще слабые ноуты и наладонники.
Я вот сейчас по работе столкнулся с задачкой. Конечный пользователь хочет видеть в браузере страницу с отчетом. Не вопрос. Проблема только в том что количество данных в отчете плэйнтекстом весит метра 2 и после формирования таблицы разворачивается на два экрана в ширину на моем вайдскрине и на черт знает сколько экранов в длинну. Так вот парсинг всего этого джваскриптом в красивый редактируемый "на месте" многостраничный интерфейс просто убьет браузер на клиенте. Пример естественно преувеличен - типичный стартап с таким не столкнется, но любителям выгружать все в клиент может стоит задуматься. Не все пользуют инет на навороченых компах. Есть еще слабые ноуты и наладонники.
Хм...
0.2 сек экономии на нагруженном сервере - максимум пару секунд работы скрипта на слабеньком клиенте. Плюс удачное проектирование и разумный минимализм никто не отменял. Разбить на экраны, правильно спроектировать представление, чтобы сократить парсинг.
Мой опыт показывает, что при формировании страницы ява-скриптом бОльшая часть времени уходит на парсинг и динамические изменения html-содержимого браузером и представление клиенту, а не работа бизнес-логики.
0.2 сек экономии на нагруженном сервере - максимум пару секунд работы скрипта на слабеньком клиенте. Плюс удачное проектирование и разумный минимализм никто не отменял. Разбить на экраны, правильно спроектировать представление, чтобы сократить парсинг.
Мой опыт показывает, что при формировании страницы ява-скриптом бОльшая часть времени уходит на парсинг и динамические изменения html-содержимого браузером и представление клиенту, а не работа бизнес-логики.
Да я же не возражаю. Вы только не увлекайтесь, а то ведь конечному пользователю безразлично загружается у него сайт 10 секунд, потому что сервер перегружен или потому что ему на его 64к надо много чего скачать, а потом еще и сформировать это у себя в страницу. Долго - значит долго, и причины здесь уже никого не интересуют.
Я конечно и здесь утрировал (особенно на счет 64к), но все же...
Кстати, мне не совсем понятен ваш термин "удачное проектирование". На удачу я буду надеяться, когда буду в MtG играть на шестом ходу с двумя землями, а информационные системы надо проектировать умно. Понимаю, что вы не это хотели сказать, но вспоминая теорию Фрейда, закрадываются смутные подозрения относительно процесса работы ... ;)
Я конечно и здесь утрировал (особенно на счет 64к), но все же...
Кстати, мне не совсем понятен ваш термин "удачное проектирование". На удачу я буду надеяться, когда буду в MtG играть на шестом ходу с двумя землями, а информационные системы надо проектировать умно. Понимаю, что вы не это хотели сказать, но вспоминая теорию Фрейда, закрадываются смутные подозрения относительно процесса работы ... ;)
офтоп - но вот это
Уж и не знаю сколько на Хабре пользователей, знакомых с Magic the Gathering - но мне пример очень понравился :)
На удачу я буду надеяться, когда буду в MtG играть на шестом ходу с двумя землями,
Уж и не знаю сколько на Хабре пользователей, знакомых с Magic the Gathering - но мне пример очень понравился :)
Magic the Gathering - да это вообще дело штука)) Пора бы эту тему вообще куда-то отдельно вынести)
главное что знакомые с этим есть вообще :)
Действительно, замечательный пример. Правда, в такой ситуации сразу надо было муллиганиться.
Мда... Если на шестом ходу у тебя всего две земли — это значит, что удача на твоей стороне (ты ж еще жив!) :)
Для каждого дела свой инструмент. Зачем заходить в крайности? Возьмём например среднестатистический форум (таблицу): пхп генерирует масив (из бд), передаёт его яваскрипту, яваскрипт через innerHTML генерирует страницу. Очень просто и эффективно.
Представил себе бедного кодера формирующего страницу через innerHtml и свободной рукой рвущего на себе волосы, потому как принципы отделения визуализации от моделирования пошли при этом общеизвестным пешеходным маршрутом ...
ПС: Я писал выше, что не возражаю против вынесения части кода на клиент.
ПС: Я писал выше, что не возражаю против вынесения части кода на клиент.
Ну я это самый кодер, и при том волосатый как афганская овчарка :) Всё очень просто на самом деле, надо только попробовать ;)
В том то и дело, что просто, но не правильно. Хотя это скорее рекомендательно.
Более грамотным подходом, как мне кажется, если уж вы хотите JSON'овые данные распихать по странице, будет достроить нужную вам DOM-модель документа и распихать данные по ней, а не громоздить все подряд innerHTML'ом. Ибо таким образом изменения сделаные кодером могут основательно пехерить всю работу верстальщика - это раз, кодер должен делать лишнюю работу - это два, ну-у-у ... и ... так проще и удобнее оперировать документом либо его частью - это три.
Более грамотным подходом, как мне кажется, если уж вы хотите JSON'овые данные распихать по странице, будет достроить нужную вам DOM-модель документа и распихать данные по ней, а не громоздить все подряд innerHTML'ом. Ибо таким образом изменения сделаные кодером могут основательно пехерить всю работу верстальщика - это раз, кодер должен делать лишнюю работу - это два, ну-у-у ... и ... так проще и удобнее оперировать документом либо его частью - это три.
Что-то заговариваться начал, видать еще не проснулся. К сожалению комментарии не редактируются, та что последний абзац написанного выше читать так:
"При использовании заполнения страницы через innerHTML изменения сделаные кодером могут основательно пехерить всю работу верстальщика - это раз, кодер должен делать лишнюю работу - это два, так менее удобно оперировать документом либо его содержимым - это три"
"При использовании заполнения страницы через innerHTML изменения сделаные кодером могут основательно пехерить всю работу верстальщика - это раз, кодер должен делать лишнюю работу - это два, так менее удобно оперировать документом либо его содержимым - это три"
DOM много быстрее innerHTML, кстати.. Это раз.
И два, с точки зрения клиента — вот к примеру у меня излишки JS иногда имеют свойство вещать ВЕСЬ браузер. Вы скажете — это мои проблемы, я скажу — это проблемы четверти интернета (Firefox) :)
Ну и три, даже говорить уже не хочется, столько всего сказано по этому поводу. Просто, у вас универсальный движок для рендеринга на стороне клиента? Нет? А вам кошмары по поводу изменения дизайна или формата данных, и последующего переписывания движка не снятся?
И два, с точки зрения клиента — вот к примеру у меня излишки JS иногда имеют свойство вещать ВЕСЬ браузер. Вы скажете — это мои проблемы, я скажу — это проблемы четверти интернета (Firefox) :)
Ну и три, даже говорить уже не хочется, столько всего сказано по этому поводу. Просто, у вас универсальный движок для рендеринга на стороне клиента? Нет? А вам кошмары по поводу изменения дизайна или формата данных, и последующего переписывания движка не снятся?
Ну, качественное программирование ещё некто не отменял. Я когда пишу, всегда тестирую на ФФ, Опере и ИЕ. Про универсальный рендеринг что-то плохо понял. Если вопрос "работает?", то ответ "да".
Про смену дизайна вообще смешно. Во первых CSS ещё никто не отменял, а во вторых: Дизайн? Посмотри на хабру (или любой другой Веб 2.0 проект). Как ты думаешь, сколько время надо чтобы такое сделать (с нуля) и переделать полностью на яваскрипте (я про фасад)?
Про DOM. Может быть и быстрее, вопрос на сколько? На пол секунды (если учесть что мы всё ещё говорим о форуме)? Кстати, откуда данные? сцылочку на инфу пжалста, может узнаю что-то новое ;)
Про смену дизайна вообще смешно. Во первых CSS ещё никто не отменял, а во вторых: Дизайн? Посмотри на хабру (или любой другой Веб 2.0 проект). Как ты думаешь, сколько время надо чтобы такое сделать (с нуля) и переделать полностью на яваскрипте (я про фасад)?
Про DOM. Может быть и быстрее, вопрос на сколько? На пол секунды (если учесть что мы всё ещё говорим о форуме)? Кстати, откуда данные? сцылочку на инфу пжалста, может узнаю что-то новое ;)
Покурите здесь. Особенно впечатляют результаты для Оперы. И даже на самом тормозящем ИЕ имеем прирост производительности DOM.createElement над innerHTML более чем в 3 раза.
Явно что-то новое для себя вы сейчас узнаете. Да и вообще, я бы не был так категоричен на вашем месте. Не знать не стыдно - стыдно не учиться.
Явно что-то новое для себя вы сейчас узнаете. Да и вообще, я бы не был так категоричен на вашем месте. Не знать не стыдно - стыдно не учиться.
Спасибо за сцылку, очень полезная инфа!
Но опять же таки, смотрим на время обработки. Какая разница между 0.3 секунды и 0.9 секунды? А вот количество кода сокращается, а чем меньше кода, тем меньше ошибок и заморочек с дизайном (ну и вес скрипта конечно же).
ИМХО оптимизировать можно всё, вопрос надо ли?
Но опять же таки, смотрим на время обработки. Какая разница между 0.3 секунды и 0.9 секунды? А вот количество кода сокращается, а чем меньше кода, тем меньше ошибок и заморочек с дизайном (ну и вес скрипта конечно же).
ИМХО оптимизировать можно всё, вопрос надо ли?
Мне кажется, мы друг друга не понимаем. При использовании ДОМа, кодера вопросы дизайна могут вообще не волновать. Он создает нужное дерево элементов, назначает нодам классы описаные в таблице стилей и наполняет их контентом. После чего, все вопросы дизайна и редизайна ложатся на плечи верстальщика. Ну, по крайней мере, так я это себе представляю.
По объему кода не соглашусь. Разница просто смешна. А вот когда вам потребуется поработать с клиентской частью содержимого, и не только выдать "на гора" полученное от сервера на этапе загрузки, но и переформировать содержимое страницы в зависимости от действий пользователя, вы поймете что компактно и быстро это решается именно через ДОМ.
Хотя это я наверное увлекся. Мне последнее время приходится проектировать системы далекие от вебдванольных стартапов, так что в теме нашего нынешнего разговора последний абзац не столь критичен.
По объему кода не соглашусь. Разница просто смешна. А вот когда вам потребуется поработать с клиентской частью содержимого, и не только выдать "на гора" полученное от сервера на этапе загрузки, но и переформировать содержимое страницы в зависимости от действий пользователя, вы поймете что компактно и быстро это решается именно через ДОМ.
Хотя это я наверное увлекся. Мне последнее время приходится проектировать системы далекие от вебдванольных стартапов, так что в теме нашего нынешнего разговора последний абзац не столь критичен.
А оптимизировать надо ВСЕ! Вопрос только в том, какие ресурсы более критичны и требуют оптимизации. Если для нас критична загрузка сервера, то оптимизируем в этом направлении, если трафик, то соответственно в этом. А если для нас критично время, то в некотором случае будет лучше купить железо, чем тратить это самое время на оптимизацию кода.
В любом случае надо исходить из вводных данных.
В любом случае надо исходить из вводных данных.
А теперь ещё раз внимательно прочитайте страницу, на которую дали ссылку ;-)
А ещё здесь:
http://www.quirksmode.org/dom/innerhtml.…
Кстати, мне кажется, что последний тест несколько ближе к практике, если мы говорим о заполнении таблиц скриптом.
А ещё здесь:
http://www.quirksmode.org/dom/innerhtml.…
Кстати, мне кажется, что последний тест несколько ближе к практике, если мы говорим о заполнении таблиц скриптом.
Хм, читал. Что-то не так?
И вашу прочитал. Согласитесь, что 50х50х* - это, ой как далеко от практики. Реальная ячейка таблицы будет иметь еще и форматирование, события, различные виды объединений и содержимое поболе и не исключено, что с тегами. На этом как мне кажется, innerHTML и запнется.
И еще, я не нашел там кода скриптов.
И вашу прочитал. Согласитесь, что 50х50х* - это, ой как далеко от практики. Реальная ячейка таблицы будет иметь еще и форматирование, события, различные виды объединений и содержимое поболе и не исключено, что с тегами. На этом как мне кажется, innerHTML и запнется.
И еще, я не нашел там кода скриптов.
DOM нужно использовать очень аккуратно. Например много манипуляций с домом могут оказаться менее эффективны чем подстановка innerHTML. Проблема в перерисовке браузером страницы при изменении структуры документа. Поэтому рекомендуется для большого кол-ва операций с DOM-деревом создавать отдельный элемент и работать с ним, и только после завершения всех манипуляций добавлять его в документ (или заменять им существующий).
Пипец...
По-моему XSLT уже давно изобрели, и работает оно точно не через innerHTML!!!
По-моему XSLT уже давно изобрели, и работает оно точно не через innerHTML!!!
Это частная правда. Все зависит от того, для чего именно вы используете аякс.
Если для подгрузки контента - то нагрузка снижается, т.к. вы подгружаете только контент без "обертки", а если для всплывающих подсказок и подобных "дополняющих" вкусностей, то нагрузка увеличивается.
Если для подгрузки контента - то нагрузка снижается, т.к. вы подгружаете только контент без "обертки", а если для всплывающих подсказок и подобных "дополняющих" вкусностей, то нагрузка увеличивается.
Всё минусуете и минусуете. ;)
А я, к сожалению, не могу.
Спорить не станете судя по всему по той причине, что не сможете объяснить чем генерация JSON по выборке из одной таблицы/единственного целевого набора таблиц будет медленней обновления всей страницы, где добавятся запросы к бд и обработчики/обращения в кэш для всех функциональных блоков страницы.
Я не возражаю против правильности проектирования БД и считаю все описанные тезисы проектирования абсолютно верными, более того я считаю что этим должен заниматься отдельный DBE, который курил все тонкости этого дела.
Я всего лишь отметил, что джойн всегда быстрее двух последовательных запросов, на каком бы уровне они не выполнялись - бд или скрипта. А спроектировать базу таким образом чтобы ни для одной выборки не требовалось объединять данные как минимум из двух таблиц - нереально.
Мне кажется, мы с вами говорим просто о разных вещах.
А я, к сожалению, не могу.
Спорить не станете судя по всему по той причине, что не сможете объяснить чем генерация JSON по выборке из одной таблицы/единственного целевого набора таблиц будет медленней обновления всей страницы, где добавятся запросы к бд и обработчики/обращения в кэш для всех функциональных блоков страницы.
Я не возражаю против правильности проектирования БД и считаю все описанные тезисы проектирования абсолютно верными, более того я считаю что этим должен заниматься отдельный DBE, который курил все тонкости этого дела.
Я всего лишь отметил, что джойн всегда быстрее двух последовательных запросов, на каком бы уровне они не выполнялись - бд или скрипта. А спроектировать базу таким образом чтобы ни для одной выборки не требовалось объединять данные как минимум из двух таблиц - нереально.
Мне кажется, мы с вами говорим просто о разных вещах.
Скоро сможете, вы толковые вещи говорите. Ловите плюс.
Да, я абсолютно согласен. Но это уже частное решение, когда проект был криво разработан и криво функционировал до того момента, когда настала необходимость оптимизации.
Если БД построена верно - можно не бояться, а напротив, активно пользоваться джойнами там, где это нужно.
Если БД построена верно - можно не бояться, а напротив, активно пользоваться джойнами там, где это нужно.
Всё-же мы говорили об общих случаях, а не о конкретике.
Да, бывает всякое, но это уже называется тюнингом.
Generally, умная модель базы данных + джоин - это правильно.
Да, бывает всякое, но это уже называется тюнингом.
Generally, умная модель базы данных + джоин - это правильно.
Умная модель базы предусматривает умное масштабирование. А это предусматривает в свою очередь разнесение части данных на разные сервера (и, собственно, как один из путей на разные коннекты). В этом случае использовав join'ы Вы будете слегка озадачены :)
Масштабирование - это не всегда дробление базы. Напротив, несколько коннектов по идее не должны снизить нагрузку.
Дробление БД, имхо, имеет смысл только в том случае, когда самостоятельный ресурсоемкий блок выносится в отдельный модуль/приложение.
А вообще существует множество других методов.
Для конкретизации - рекомендую посмотреть на схемы работы Wikipedia, Livejournal и почитать о методах кластеризации серверов и приложений.
Я не DBE, тонкостей всех не знаю, не хочу позориться. :)
Дробление БД, имхо, имеет смысл только в том случае, когда самостоятельный ресурсоемкий блок выносится в отдельный модуль/приложение.
А вообще существует множество других методов.
Для конкретизации - рекомендую посмотреть на схемы работы Wikipedia, Livejournal и почитать о методах кластеризации серверов и приложений.
Я не DBE, тонкостей всех не знаю, не хочу позориться. :)
LJ JOIN рекомендуют не использовать.
Делить иногда надо не только по таблицам/сервисам, но и одну таблицу/сервис на несколько.
Существует всего два способа параллелизма - по функции и по данным. Вы упомянули только первый.
Делить иногда надо не только по таблицам/сервисам, но и одну таблицу/сервис на несколько.
Существует всего два способа параллелизма - по функции и по данным. Вы упомянули только первый.
Я знаком и работал только с таким типом масштабирования, когда существует несколько полных копий DB на нескольких машинах и в зависимости от загруженности серверов циска адресует запрос на наименее загруженный. Как обновляется информация между серверами - не в курсе. Но быстро. В таком случае работают все джойны и прочее.
Держать одно соединение к DB всегда эффективнее чем несколько. (а в некоторых языках вовсе придется по очереди к серверам подключаться).
Когда делится одна таблица - это какая-то недораспределенная модель, необходимо центральный сервер, который знает что и где лежит. Или я опять не понял ? :)
Вобщем, я уже говорил - я не DBE. Хотите - объясните, не хотите - не пинайте, пожалуйста, я высказываю только свои мысли. :)
Держать одно соединение к DB всегда эффективнее чем несколько. (а в некоторых языках вовсе придется по очереди к серверам подключаться).
Когда делится одна таблица - это какая-то недораспределенная модель, необходимо центральный сервер, который знает что и где лежит. Или я опять не понял ? :)
Вобщем, я уже говорил - я не DBE. Хотите - объясните, не хотите - не пинайте, пожалуйста, я высказываю только свои мысли. :)
Это самая простая схема масштабирования и ею лучше не пользоваться =)
Потому что рано или поздно наступит момент, когда обновление информации будет занимать слишком много времени.
Количество соединений никак на производительность не влияет, если измеряется десятками. Почти везде есть пулы соединений, так что соединения не устанавливаются на каждый запрос новые. Как здесь может помогать Циска, я не представляю =)
Центральный сервер нужен только тогда, когда вы готовы всё потерять одним махом =)
Единая точка отказа это плохо.
Потому что рано или поздно наступит момент, когда обновление информации будет занимать слишком много времени.
Количество соединений никак на производительность не влияет, если измеряется десятками. Почти везде есть пулы соединений, так что соединения не устанавливаются на каждый запрос новые. Как здесь может помогать Циска, я не представляю =)
Центральный сервер нужен только тогда, когда вы готовы всё потерять одним махом =)
Единая точка отказа это плохо.
из моего опыта создания динамических сайтов, где контент путешествует к клиенту _исключительно_ в виде json-a, где его собирает жаваскрипт, экономия выходит существенная.
На сервере происходят только три вещи - определение что надо делать по запросу клиента, выборка/внесение в базу соотвествующих изменений и формирование-выдача результата.
соотношение кода получается 1 к 10 (в случае пхп-жаваскрипт). При этом последний весит 30-50 килобайт и загружается один раз при заходе на сайт. Выйгрыша в скорости у клиента в большинстве случаев нет, т.к. отображение достаточно сложное. Особенно тормозит на старых машинках (этак прошлого века). но в целом подход вполне жизнеспособен, если забыть про вечные проблемы динамических сайтов ака кнопки "назад" и "добавить в закладки".
На сервере происходят только три вещи - определение что надо делать по запросу клиента, выборка/внесение в базу соотвествующих изменений и формирование-выдача результата.
соотношение кода получается 1 к 10 (в случае пхп-жаваскрипт). При этом последний весит 30-50 килобайт и загружается один раз при заходе на сайт. Выйгрыша в скорости у клиента в большинстве случаев нет, т.к. отображение достаточно сложное. Особенно тормозит на старых машинках (этак прошлого века). но в целом подход вполне жизнеспособен, если забыть про вечные проблемы динамических сайтов ака кнопки "назад" и "добавить в закладки".
Эхххх...
Молодые, горячие...
Молодые, горячие...
Оба пункта неверны.
http://highscalability.com/digg-architecture
Про join'ы (view - вообще упаси боже):
The lightweight nature of PHP allowed them to move processing tasks from the database to PHP in order to improve scaling. Ebay does this in a radical way. They moved nearly all work out of the database and into applications, including joins, an operation we normally think of as the job of the database.
Про javascript:
People often complain Digg is slow. This is perhaps due to their large javascript libraries rather than their backend architecture.
http://highscalability.com/digg-architecture
Про join'ы (view - вообще упаси боже):
The lightweight nature of PHP allowed them to move processing tasks from the database to PHP in order to improve scaling. Ebay does this in a radical way. They moved nearly all work out of the database and into applications, including joins, an operation we normally think of as the job of the database.
Про javascript:
People often complain Digg is slow. This is perhaps due to their large javascript libraries rather than their backend architecture.
1. Трафик увеличится в разы :) На сервере в данном контексте узкое место это канал передачи, а не производительность процессора ;)
2. А вы слышали как рычит литр на десяти тысячах? JOIN'ы спасут интернет от людей ими злоупотребляющими, но не более. Естественный отбор, так сказать. На многомиллионных таблицах JOIN'ы просто убивают базу. Иногда лучше сделать 2 разных запроса и потом осуществить JOIN средствами скрипта. Но это в каждом конкретном случае смотреть надо.
2. А вы слышали как рычит литр на десяти тысячах? JOIN'ы спасут интернет от людей ими злоупотребляющими, но не более. Естественный отбор, так сказать. На многомиллионных таблицах JOIN'ы просто убивают базу. Иногда лучше сделать 2 разных запроса и потом осуществить JOIN средствами скрипта. Но это в каждом конкретном случае смотреть надо.
Иногда лучше сделать 2 разных запроса и потом осуществить JOIN средствами скрипта.
Интересно. Не могли бы привести пример - когда JOIN средствами скрипта производительнее JOIN'а средствами СУБД?
Раз уж вы о масштабируемости, то только вчера у меня, при запуске крона пересчета аналитики (из базы в 30.000 элементов), оборачивалось ошибкой Bad Gateway (это своего рода ограничитель времени исполнения кода, как я понимаю, когда код работает, не думая останавливаться). Пришлось этот крон оптимизировать до предела. Переформулировал всего лишь один запрос к бд (внутри цикла), убрав из него JOINы, крон теперь работает ровно секунду. Результат тот же, время выполнения сократилось в тысячи раз. Поверьте, у меня тоже глаза сначала на лбу были.
ммм... если это мускль то своими глазами видел несколько ошибок в интерпретации им запросов, что приводили к убиению мускля...
или второй вариант - запрос был составлен неграмотно :)
или второй вариант - запрос был составлен неграмотно :)
Джойны, конечно же, будут работать долго и неправильно в том случае, если неверно спроектирована структура данных или неверно настроены индексы (о них вообще нельзя забывать).
Для примера, был у меня один проект на доделке и оптимизации (система управления бизнесом), где в сутки генерировалось порядка 10-20 тысяч строк в две таблицы логов, выборки из этих таблиц делались ежедневно, кроном, который вызывал скрипт, запросы все были с джойнами, занимало это около 10 минут (суммарно обрабатывалось около 1 миллиона записей - из двух таблиц логов, каждая таблица по 4-5 миллионов записей и таблиц пользователей/вспомогательных таблиц, уже точно не помню сути, но минимум 5-7 таблиц участвовали в выборке).
После правильной расстановки индексов время этой выборки сократилось до 0.8 секунды и решено было кнопочку "сгенерировать статистику" перенести в вэб-интерфейс. Это при том, что изначально неверная структура БД переработана не была.
Для примера, был у меня один проект на доделке и оптимизации (система управления бизнесом), где в сутки генерировалось порядка 10-20 тысяч строк в две таблицы логов, выборки из этих таблиц делались ежедневно, кроном, который вызывал скрипт, запросы все были с джойнами, занимало это около 10 минут (суммарно обрабатывалось около 1 миллиона записей - из двух таблиц логов, каждая таблица по 4-5 миллионов записей и таблиц пользователей/вспомогательных таблиц, уже точно не помню сути, но минимум 5-7 таблиц участвовали в выборке).
После правильной расстановки индексов время этой выборки сократилось до 0.8 секунды и решено было кнопочку "сгенерировать статистику" перенести в вэб-интерфейс. Это при том, что изначально неверная структура БД переработана не была.
Еще раз. А вы слышали как рычит литр на десяти тысячах?
Попробуйте сделать join 2х таблиц по 50М записей в каждой, да хотя бы по 5М.
http://www.habrahabr.ru/blog/startup/245… Тут достаточно развернутый теоретический ответ. Я сталкивался только на практике.
Пример - форум. Таблица сообщений и таблица пользователей. 30K пользователей и порядка 1М сообщений, что, впринципе, нормально для хорошо развитого форума. На одной странице отображается порядка 20 сообщений. Джойнить эти две таблицы, чтобы потом из join'a вытащить 20 записей, достаточно жестоко. СУБД может хорошо оптимизировать запросы, но все равно в определенных ситуациях может очень хорошо призадуматься и отожрать памяти.
Пример2. Искуственный, но на реальных данных и с реальными цифрами.
Имеем 2 таблицы по 200К записей в каждой. Одной записи из первой таблицы соответствует одна запись из второй. Очень простая ситуация :)
Выборка 5 первых записей из каждой занимает 0 секунд. Из середины и с конца тоже 0 сек.
Выборка 5 первых записей из простого join'a этих таблиц занимает 0.2 сек. Из середины - 2.36. С конца - 3.30.
Это на 4х головом сервере, таблицы проиндексированы.
Запросы выполнялись к "холодной" базе. Второй раз результат запроса БД берет из кеша, тут конечно выигрыш и не малый, но стоит изменить таблицу, и на запрос опять уйдет лишняя секунда...
Выбрать скриптом 5 записей из каждой таблицы, как видно, ничего не стоит. Сделать с ними join средствами скрипта тоже ничего не стоит. Итого можно выиграть до 3х секунд в данном конкретном примере.
Попробуйте сделать join 2х таблиц по 50М записей в каждой, да хотя бы по 5М.
http://www.habrahabr.ru/blog/startup/245… Тут достаточно развернутый теоретический ответ. Я сталкивался только на практике.
Пример - форум. Таблица сообщений и таблица пользователей. 30K пользователей и порядка 1М сообщений, что, впринципе, нормально для хорошо развитого форума. На одной странице отображается порядка 20 сообщений. Джойнить эти две таблицы, чтобы потом из join'a вытащить 20 записей, достаточно жестоко. СУБД может хорошо оптимизировать запросы, но все равно в определенных ситуациях может очень хорошо призадуматься и отожрать памяти.
Пример2. Искуственный, но на реальных данных и с реальными цифрами.
Имеем 2 таблицы по 200К записей в каждой. Одной записи из первой таблицы соответствует одна запись из второй. Очень простая ситуация :)
Выборка 5 первых записей из каждой занимает 0 секунд. Из середины и с конца тоже 0 сек.
Выборка 5 первых записей из простого join'a этих таблиц занимает 0.2 сек. Из середины - 2.36. С конца - 3.30.
Это на 4х головом сервере, таблицы проиндексированы.
Запросы выполнялись к "холодной" базе. Второй раз результат запроса БД берет из кеша, тут конечно выигрыш и не малый, но стоит изменить таблицу, и на запрос опять уйдет лишняя секунда...
Выбрать скриптом 5 записей из каждой таблицы, как видно, ничего не стоит. Сделать с ними join средствами скрипта тоже ничего не стоит. Итого можно выиграть до 3х секунд в данном конкретном примере.
По примеру 2:
Конечно выборка пяти записей не с начала джойна занимает время - ведь СУБД надо построить весь результат джойна до нужных строк. Но ведь база даёт возможность сделать тоже самое, что и вы в скрипте - уменьшить количество джойненных строк до 5, а потом результат сджойнить с 200К.
Кстати, по поводу джойна средствами скрипта 5-и строк с 200К - это точно ничего не стоит? Или библиотеки Perl'a умеют хранить индексы к полученным рекордсетам (как ADO.NET 3)?
По примеру 1:
Ну, в общем-то, тоже что и выше - что мешает ограничить таблицу сообщений до 20 используя where. Или, если о юзере знать кроме имени ничего не надо - можно пойти на небольшую денормализацию.
Конечно выборка пяти записей не с начала джойна занимает время - ведь СУБД надо построить весь результат джойна до нужных строк. Но ведь база даёт возможность сделать тоже самое, что и вы в скрипте - уменьшить количество джойненных строк до 5, а потом результат сджойнить с 200К.
Кстати, по поводу джойна средствами скрипта 5-и строк с 200К - это точно ничего не стоит? Или библиотеки Perl'a умеют хранить индексы к полученным рекордсетам (как ADO.NET 3)?
По примеру 1:
Ну, в общем-то, тоже что и выше - что мешает ограничить таблицу сообщений до 20 используя where. Или, если о юзере знать кроме имени ничего не надо - можно пойти на небольшую денормализацию.
Кстати, по поводу джойна средствами скрипта 5-и строк с 200К - это точно ничего не стоит?
А зачем нам загружать все 200К? У нас есть условие on, из которого мы можем точно определить какие строки нам нужны и запросить именно их. В приведенном примере их будет 5. Из проиндексированной таблицы они к нам прилетят в момент. Таким образом база лишена удовольствия "построить весь результат джойна до нужных строк".
Или библиотеки Perl'a умеют хранить индексы к полученным рекордсетам (как ADO.NET 3)?
О каких индексах вы говорите? Я не понял :)
что мешает ограничить таблицу сообщений до 20 используя where
Может быть limit?
Честно говоря, я до конца не разобрался как MySQL оптимизирует свои запросы, но что-то мне подсказывает, что если в join используется where, то не всегда БД понимает, что строить весь join не обязательно.
Тут конечно можно поспорить, но я этого не хочу, т.к. рискую потерять много времени безрезультатно. Если у Вас есть какие-нибудь проверенные сведения на этот счет, я непременно выслушаю.
Иногда, кстати, оказывается очень полезным заменить JOIN подзапросом.
Что-то я так и не понял за что мне поставили -7, вроде некого не оскорблял, оффтоп не писал, фигню не порол...
(почесав затылок попёрся дальше)
(почесав затылок попёрся дальше)
Судя по всему, у вас нет руководителя проекта. Навскидку я вижу сразу несколько пунктов, о которых бы он, если бы был, подумал.
Собственно, я об этом и пытаюсь подумать. Иначе и топика небыло б ) Но это мой первый проект, в котором я выступаю в роли руководителя и в роли ведущего программиста, поэтому не все сразу 100% идеально. Но я стараюсь )
Дело в том, что раньше меня интересовало юзабилити и позиционирование. Вроде бы разобрались. А теперь вот дальше идем.
Вас интересовало позиционирование и вы умудрились не задуматься обо всем остальном маркетинге? И даже не знаете примерную аудиторию своего проекта? Вот и я про это.
Нас интересовало создание интересного продукта для данной целевой аудитории. То есть набор возможностей. тематика, подача.
А маркетинг - отдельно.
- Купишь вагон валенок за 100 тысяч бакосв?
- Куплю.
И разошлись. Один - искать вагон валенок, второй - 100 тысяч штук.
Вначале ведь надо позаботиться о том, что продавать, и быть уверенным что продукт есть. То есть заняться производством. А потом уже заниматься делами, которые обслуживают производство. На мой взгляд, схема, в которой вначале решаются вопросы маркетинга, не подходит начинающим студиям. Ведь вначале надо научиться дело делать, а потом уже продавать его. Или я не прав?
А маркетинг - отдельно.
- Купишь вагон валенок за 100 тысяч бакосв?
- Куплю.
И разошлись. Один - искать вагон валенок, второй - 100 тысяч штук.
Вначале ведь надо позаботиться о том, что продавать, и быть уверенным что продукт есть. То есть заняться производством. А потом уже заниматься делами, которые обслуживают производство. На мой взгляд, схема, в которой вначале решаются вопросы маркетинга, не подходит начинающим студиям. Ведь вначале надо научиться дело делать, а потом уже продавать его. Или я не прав?
маркетинг - в первую очередь, а не отдельно :о) как вы заинтересуете эту аудиторию? как аудитория узнает о проекте? как вы планируете стимулировать аудиторию к активным действиям на сайте? и еще куча разных вопросов.
это все надо обдумывать ДО запуска проекта.
это все надо обдумывать ДО запуска проекта.
А анекдот-то очень правильный.
Маркетинговый подход как раз и заключается в том что бы:
1. найти Товар вас купят (Тут просто задается прямой вопрос прямой вопрос о "вагоне валенок", т.е. поиск методом "тыка").
2. узнать за какие деньги (Цена) вы сможете продать продукт (100 тысяч баксов, вопрос ценообразования оставлен за скобками).
3. узнать выгодно ли будет продавать Товар по Цене
и только потом приступать к производству (идти искать валенки).
Согласитесь, не очень договидно покупать (производить) вагон валенок если его некому покупать или затраты на производство не окупятся.
----
Это не значит что интуитивный подход (ну продукт-то хорош) обречен на провал, просто вероятность провала существенно меньше, если провести исследование и только потом бросаться в омут с головой.
Маркетинговый подход как раз и заключается в том что бы:
1. найти Товар вас купят (Тут просто задается прямой вопрос прямой вопрос о "вагоне валенок", т.е. поиск методом "тыка").
2. узнать за какие деньги (Цена) вы сможете продать продукт (100 тысяч баксов, вопрос ценообразования оставлен за скобками).
3. узнать выгодно ли будет продавать Товар по Цене
и только потом приступать к производству (идти искать валенки).
Согласитесь, не очень договидно покупать (производить) вагон валенок если его некому покупать или затраты на производство не окупятся.
----
Это не значит что интуитивный подход (ну продукт-то хорош) обречен на провал, просто вероятность провала существенно меньше, если провести исследование и только потом бросаться в омут с головой.
1. Время генерации слишком большое. Действительно, СЛИШКОМ. Оптимальное время генерации для среднего сайта - около 0,05-0,1 с. Это без кеширования. Не найдейтесь что на мощном сервере будет работать быстрее, особенно если возлагаете настройку сервера на хостера.
2. Сисадмина (можно не постоянного, а "по вызову", главное - грамотного и адекватного) и SEOшника, желательно еще на этапе проектирования.
Всё остальное, имхо, зависит от сути и направленности проекта.
2. Сисадмина (можно не постоянного, а "по вызову", главное - грамотного и адекватного) и SEOшника, желательно еще на этапе проектирования.
Всё остальное, имхо, зависит от сути и направленности проекта.
Несколько тысяч человек - это 5`000-8`000. Возьмем 10`000
Каждый пользователь сделает 20 запросов - это 2`000`000 запросов к серверу, что составляет 23 запроса в секунду. Коеффициент дневной перегрузки к среднесуточной равен 2-3. Плюс запас. Итого 100 запросов в секунду сервер должен держать, что бы не выстраивалась очередь.
Но это в теории.
На практике же, с увеличением количества запросов linux и mysql дружно позаписывают в кеш много всего интересного, что ускорит работу. SQL запрос на "холодной" базе может выполняться и 0.1 сек, но после первого же попадения в кеш этот же запрос обработается за 0.003
По-хорошему, нужно устроить DOS-атаку вторым сервером, эмулирующим действия пользователя. Тогда и можно замерять реальную производительность
Каждый пользователь сделает 20 запросов - это 2`000`000 запросов к серверу, что составляет 23 запроса в секунду. Коеффициент дневной перегрузки к среднесуточной равен 2-3. Плюс запас. Итого 100 запросов в секунду сервер должен держать, что бы не выстраивалась очередь.
Но это в теории.
На практике же, с увеличением количества запросов linux и mysql дружно позаписывают в кеш много всего интересного, что ускорит работу. SQL запрос на "холодной" базе может выполняться и 0.1 сек, но после первого же попадения в кеш этот же запрос обработается за 0.003
По-хорошему, нужно устроить DOS-атаку вторым сервером, эмулирующим действия пользователя. Тогда и можно замерять реальную производительность
У нас абсолютно нет специалистов по рекламе, продвижению
Вот это настораживает. Вы задумывались, что будет после того, как проект запустите? Сделать хороший продукт мало, надо его еще раскрутить.
не видя проекта, невозможно написать ничего про раскрутку
современные социальные сервисы раскручиваются с помощью так называемых «программ лояльности» — специальных приёмов приглашения на сайт других пользователей, публикацию виджетов и сниппетов, постоянную нотификацию и т.д. если вам это подходит — изучайте интернет, там уже всё написано на эту тему... ну а если в вашем проекте нет социальности, то идите обычным путём: поисковая оптимизация, контекстная реклама, покупка трафика, отслеживание конверсии и т.д.
современные социальные сервисы раскручиваются с помощью так называемых «программ лояльности» — специальных приёмов приглашения на сайт других пользователей, публикацию виджетов и сниппетов, постоянную нотификацию и т.д. если вам это подходит — изучайте интернет, там уже всё написано на эту тему... ну а если в вашем проекте нет социальности, то идите обычным путём: поисковая оптимизация, контекстная реклама, покупка трафика, отслеживание конверсии и т.д.
насколько я знаю, хотя могу и ошибаться, если это так - развейте мои заблуждения
при подключении библиотек тратится исключительно реальное время - процессорное задействовано по-минимуму. Поэтому подобная оптимизация не повлияет на загрузку сервера в целом, но ускорит выдачу контента конечному пользователю.
при подключении библиотек тратится исключительно реальное время - процессорное задействовано по-минимуму. Поэтому подобная оптимизация не повлияет на загрузку сервера в целом, но ускорит выдачу контента конечному пользователю.
Хороший топик. Полезный.
Немного тяжело писать, не имея представления о том, что за проект.
Я предположил что вы делаете какой-нибудь среднестатистический w2.0 сайт. Ну например социальную сеть или букмарки какие-нибудь.
Тогда:
1. Результат медленный + имхо, очень неправильный метод проверки. Попробуйте протестировать это при большой нагрузке. Напишите скрипт, который имитирует действия пользователя и форкните 2-3 тысячи таких скриптов одновременно. Замерьте сколько времени берут различные действия и оптимизируйте самые трудоёмкие.
Простое тестирование и замерение действий для одного юзера - не очень правильная стратегия. Когда на сайт одновременно идут множество запросов, возникают дополнительные расходы на lock/unlock файлов, таблиц в базе и т.д.
Измерение просто времени загрузки страницы - слишком приблизительный параметр, имхо.
2. Опять же, ХЗ что вы запускаете, но зачем вам юрист?
Если вы хотите сэкономить на рекламе + быстрей поднять проект, вам сразу же нужен человек, который сможет писать обзоры сервиса и отправлять их в различные веб2.0 направленности блоги (если проект расчитан и на буржуев то должен быть отличный английский). Фактически, сейчас любой мало-мальский привлекательный проект получает свои 15 минут славы, когда его выход освещает блогосфера.
Дальше зависит от того, на что какую аудиторию вы расчитываете. Если проект на английском и вы целитесь на запад - _отличный_ администратор обязателен - он должен будет выжать из вашего сервера всё возможное! Потому как, _имхо_ единственный сейчас шанс быстро раскрутить ресурс без особых вложений - это привлечь ту аудиторию которая придёт из блогов, когда о вас напишут. Трафик с techcrunch или digg при плохих настройках уложит ваш сервер за минуты, а второго шанса может и не быть.
Если вы пишете для рунета - тут админ менее критичен. В конце-концов bobrdobr, который упал с самого начала, сейчас нормально живёт и достаточно популярен.
3. Хостинг. Если вы будете платить за трафик, то прикиньте сколько вы съедите за первые несколько месяцев, а потом утройте эту сумму.
4. Продумайте о том, какие ходы для пиара вы будете делать через месяц, два и полгода чтобы подогреть интерес к сервису. Уже сейчас вы можете сделать какие-то ходы, которые помогут вам позже. Например, выход сервиса в бета-версии это не только какая-то легитимация для возможных ошибок, но и повод для блогов написать о вас ещё раз, когда вы зарелизитесь окончательно.
Возможно стоит убрать какие-то менее необходимые фичи и открыться в минимальной конфигурации, а потом через 2-3 недели добавить их, дав опять же повод о вас говорить.
Ну и тому подобные вещи...
Ух. Много букв написал.
Удачи, BTW ;)
Немного тяжело писать, не имея представления о том, что за проект.
Я предположил что вы делаете какой-нибудь среднестатистический w2.0 сайт. Ну например социальную сеть или букмарки какие-нибудь.
Тогда:
1. Результат медленный + имхо, очень неправильный метод проверки. Попробуйте протестировать это при большой нагрузке. Напишите скрипт, который имитирует действия пользователя и форкните 2-3 тысячи таких скриптов одновременно. Замерьте сколько времени берут различные действия и оптимизируйте самые трудоёмкие.
Простое тестирование и замерение действий для одного юзера - не очень правильная стратегия. Когда на сайт одновременно идут множество запросов, возникают дополнительные расходы на lock/unlock файлов, таблиц в базе и т.д.
Измерение просто времени загрузки страницы - слишком приблизительный параметр, имхо.
2. Опять же, ХЗ что вы запускаете, но зачем вам юрист?
Если вы хотите сэкономить на рекламе + быстрей поднять проект, вам сразу же нужен человек, который сможет писать обзоры сервиса и отправлять их в различные веб2.0 направленности блоги (если проект расчитан и на буржуев то должен быть отличный английский). Фактически, сейчас любой мало-мальский привлекательный проект получает свои 15 минут славы, когда его выход освещает блогосфера.
Дальше зависит от того, на что какую аудиторию вы расчитываете. Если проект на английском и вы целитесь на запад - _отличный_ администратор обязателен - он должен будет выжать из вашего сервера всё возможное! Потому как, _имхо_ единственный сейчас шанс быстро раскрутить ресурс без особых вложений - это привлечь ту аудиторию которая придёт из блогов, когда о вас напишут. Трафик с techcrunch или digg при плохих настройках уложит ваш сервер за минуты, а второго шанса может и не быть.
Если вы пишете для рунета - тут админ менее критичен. В конце-концов bobrdobr, который упал с самого начала, сейчас нормально живёт и достаточно популярен.
3. Хостинг. Если вы будете платить за трафик, то прикиньте сколько вы съедите за первые несколько месяцев, а потом утройте эту сумму.
4. Продумайте о том, какие ходы для пиара вы будете делать через месяц, два и полгода чтобы подогреть интерес к сервису. Уже сейчас вы можете сделать какие-то ходы, которые помогут вам позже. Например, выход сервиса в бета-версии это не только какая-то легитимация для возможных ошибок, но и повод для блогов написать о вас ещё раз, когда вы зарелизитесь окончательно.
Возможно стоит убрать какие-то менее необходимые фичи и открыться в минимальной конфигурации, а потом через 2-3 недели добавить их, дав опять же повод о вас говорить.
Ну и тому подобные вещи...
Ух. Много букв написал.
Удачи, BTW ;)
Проведите полное тестирование: функциональное, нагрузочное, производительности итп. По возможности автоматизируйте и прогоняйте по тестам каждую сборку, при сравнении результатов можно будет увидеть в какую сторону вы двигаетесь.
По поводу раскрутки - советую очень хорошо продумать этот пункт сейчас.
По поводу раскрутки - советую очень хорошо продумать этот пункт сейчас.
По поводу технических моментов связанных с быстродействием движка – обычно основные проблемы с быстродействием связаны с работой с БД. Конечно было бы замечательно предусмотреть кэширование запросов (и даже не обязательно через допустим Memcache – даже самописное кэширование в файлы запросов может очень сильно помочь). Так же самое простое и элементарное при работе с БД – но часто об этом забывают – убедитесь, что ко всем полям таблиц в БД по которым производиться поиск, добавлен индекс.
И хотя действительно трудно что то сказать конкретное, не видя проекта (или хотя бы примерного не представляя области его деятельности и его организации).
Но если в общем:
Каждый проект в своем развитии проходит через ряд этапов – и в каждом этапе основные моменты, на которые нужно обращать внимание – разные. Их конечно можно держать в голове – но решать их надо по мере наступления соответствующего этапа.
Первый этап – разработка – как я понимаю, Вами почти пройден. Это хорошо – так как в большинстве случаев важно как можно быстрее запустить проект, пусть даже ограниченным по функциональности.
На второй стадии – стадии запуска – основной вопрос это привлечение пользователей. Нужно сконцентрироваться на рекламе, продвижении, поисковой оптимизации и т.д.
Вы продумали эти вопросы? На этом этапе проблемы связанные с оптимизаций быстродействия движка не актуальны – не стоит распылять на это силы. То есть нужно думать не «Сегодня посещаемость 500 уников – а завтра вдруг будет 2000 – как движок справиться?», а «Сегодня посещаемость 500 – как сделать что бы завтра посещаемость была 600?».
Третья стадия – стадия стабильного роста/развития – когда проект подберется близко к расчетным показателям посещаемости. Только тогда нужно думать об оптимизации производительности. Но так как обычно на этой стадии проект начинает генерировать прибыль - эти вопросы решаются в рабочем порядке
Некоторые финансовые вопросы, о которых нужно помнить –
Очень важно позаботиться о некой критической точке, через которую проходят многие стартапы – период когда первоначально вложенные средства исчерпаны – но проект еще не начал приносить прибыль. Подавляющее большинство проектов, проходящих через эту точку – в ней и погибают. Соответственно – важно позаботиться о некотором страховом запасе средств.
Еще важный момент – наличие оборотных средств - связанный с особенностями бизнес циклов. То есть на примере – по окончании месяца нужно платить за хостинг, выдавать зарплату, оплачивать рекламу на будущий месяц и т.д. – а доходы с проекта за прошедший месяц поступает в середине следующего месяца. То есть – какая то сумма, который будет расходоваться, а через некоторое время пополняться – должна быть.
И конечно – желаю удачи, верных пользователей и щедрых рекламодателей! :)
И хотя действительно трудно что то сказать конкретное, не видя проекта (или хотя бы примерного не представляя области его деятельности и его организации).
Но если в общем:
Каждый проект в своем развитии проходит через ряд этапов – и в каждом этапе основные моменты, на которые нужно обращать внимание – разные. Их конечно можно держать в голове – но решать их надо по мере наступления соответствующего этапа.
Первый этап – разработка – как я понимаю, Вами почти пройден. Это хорошо – так как в большинстве случаев важно как можно быстрее запустить проект, пусть даже ограниченным по функциональности.
На второй стадии – стадии запуска – основной вопрос это привлечение пользователей. Нужно сконцентрироваться на рекламе, продвижении, поисковой оптимизации и т.д.
Вы продумали эти вопросы? На этом этапе проблемы связанные с оптимизаций быстродействия движка не актуальны – не стоит распылять на это силы. То есть нужно думать не «Сегодня посещаемость 500 уников – а завтра вдруг будет 2000 – как движок справиться?», а «Сегодня посещаемость 500 – как сделать что бы завтра посещаемость была 600?».
Третья стадия – стадия стабильного роста/развития – когда проект подберется близко к расчетным показателям посещаемости. Только тогда нужно думать об оптимизации производительности. Но так как обычно на этой стадии проект начинает генерировать прибыль - эти вопросы решаются в рабочем порядке
Некоторые финансовые вопросы, о которых нужно помнить –
Очень важно позаботиться о некой критической точке, через которую проходят многие стартапы – период когда первоначально вложенные средства исчерпаны – но проект еще не начал приносить прибыль. Подавляющее большинство проектов, проходящих через эту точку – в ней и погибают. Соответственно – важно позаботиться о некотором страховом запасе средств.
Еще важный момент – наличие оборотных средств - связанный с особенностями бизнес циклов. То есть на примере – по окончании месяца нужно платить за хостинг, выдавать зарплату, оплачивать рекламу на будущий месяц и т.д. – а доходы с проекта за прошедший месяц поступает в середине следующего месяца. То есть – какая то сумма, который будет расходоваться, а через некоторое время пополняться – должна быть.
И конечно – желаю удачи, верных пользователей и щедрых рекламодателей! :)
поделюсь опытом (без лишней скромности, он у меня не маленький)
>
Но по ночам не спится, все ли мы правильно делаем? Меня как руководителя проекта, волнует несколько вопросов.
Будьте на 100 % уверены, что-то сделали не правильно. Главное, не увлекаться процессом разработки, ради разработки - смириться с "достаточным" уровнем качества, и открывать проект.
>
1. Не слишком ли наш движок медленный?
На локальной машине p4 2.8GHz/1 Gb DDR-400 dual/ATA-100 с последними apache, php и mysql с практически дефолтными настройками время генерации страницы от 0.05 до 0.5 секунды при отсутствующей посторонней нагрузке. При этом время сборки кода без выполнения команд - 0.03 секунды. Какой хостинг нам понадобится для обслуживания нескольких тысяч посетителей в сутки?
Не думаю, что на данном этапе оптимизация кода - это кратчайший путь к решению проблемы производительности. Я бы рекомендовал для начала оптимизировать "среду" и правильно настроить сервер (сбалансировать по нагрузке).
Битрикс(оиды) довольно много рассказывают про это (http://www.1c-bitrix.ru/performance/webserver.php) + QSOFT выложил соответствующие конфигурационные файлы по последнему их тестированию (внизу страницы: http://www.1c-bitrix.ru/performance/testing_reports.php) ..
Не суть важно битрикс / не битрикс, но методы которые там используются для настройки сервера помогут Вам на порядки поднять производительнось (а главное) стабильность машины. Если проект "заживет", то сначала нарастите железа (это проще и дешевле, чем код колупать), а уже потом будете думать над оптимизацией запросов
>
2. Каких специалистов не хватает в команде?
На данный момент у нас есть программист, несколько специалистов по юзабилити, по аналитике, несколько контент-менеджеров. У нас абсолютно нет специалистов по рекламе, продвижению, нет юристов и нет администратора сервера, то есть мы пока полагаемся на хостера. Кого необходимо пригласить прямо сейчас, и кто потребуется сразу после запуска?
Если кратко, то "Быстрых". На данном этапе не суть важна специализация членов команды (хотя конечно один сильный технический специалист необходим). Важно, чтобы Вы могли положиться на членов, своей команды, могли доверить им разные задачи, от которых зависит судьба Вашего проекта. Они должны уметь быстро переключаться, быстро решать поставленные задачи, делать максимум за отведенное время.
>
3. Какие непредвиденные денежные затраты повлечет запуск проекта?
На данный момент у нас решен вопрос с оплатой труда, но на сам проект остается не так уж и много - всего меньше тысячи долларов. Нужно ли привлекать дополнительные деньги? Чем грозит попытка стартовать, опираясь на такую сумму?
4. О чем мы не подумали, и какие ходы необходимо предпринять еще?
Думайте о команде! Сейчас не важны деньги, не важен код, не важен дизайн и юзабилити - Вам сейчас нужны команда и время. У вас очень мало времени, потому что даже самая воодушевленная команда рано или поздно потеряет веру в проект, если он не начнет приносить ожидаемых результатов. Поэтому, надо на всем экономить время и быстрее - быстрее двигаться к первым видимым для всех плодам (пользователям / признанию / деньгам / ...)
>
Но по ночам не спится, все ли мы правильно делаем? Меня как руководителя проекта, волнует несколько вопросов.
Будьте на 100 % уверены, что-то сделали не правильно. Главное, не увлекаться процессом разработки, ради разработки - смириться с "достаточным" уровнем качества, и открывать проект.
>
1. Не слишком ли наш движок медленный?
На локальной машине p4 2.8GHz/1 Gb DDR-400 dual/ATA-100 с последними apache, php и mysql с практически дефолтными настройками время генерации страницы от 0.05 до 0.5 секунды при отсутствующей посторонней нагрузке. При этом время сборки кода без выполнения команд - 0.03 секунды. Какой хостинг нам понадобится для обслуживания нескольких тысяч посетителей в сутки?
Не думаю, что на данном этапе оптимизация кода - это кратчайший путь к решению проблемы производительности. Я бы рекомендовал для начала оптимизировать "среду" и правильно настроить сервер (сбалансировать по нагрузке).
Битрикс(оиды) довольно много рассказывают про это (http://www.1c-bitrix.ru/performance/webserver.php) + QSOFT выложил соответствующие конфигурационные файлы по последнему их тестированию (внизу страницы: http://www.1c-bitrix.ru/performance/testing_reports.php) ..
Не суть важно битрикс / не битрикс, но методы которые там используются для настройки сервера помогут Вам на порядки поднять производительнось (а главное) стабильность машины. Если проект "заживет", то сначала нарастите железа (это проще и дешевле, чем код колупать), а уже потом будете думать над оптимизацией запросов
>
2. Каких специалистов не хватает в команде?
На данный момент у нас есть программист, несколько специалистов по юзабилити, по аналитике, несколько контент-менеджеров. У нас абсолютно нет специалистов по рекламе, продвижению, нет юристов и нет администратора сервера, то есть мы пока полагаемся на хостера. Кого необходимо пригласить прямо сейчас, и кто потребуется сразу после запуска?
Если кратко, то "Быстрых". На данном этапе не суть важна специализация членов команды (хотя конечно один сильный технический специалист необходим). Важно, чтобы Вы могли положиться на членов, своей команды, могли доверить им разные задачи, от которых зависит судьба Вашего проекта. Они должны уметь быстро переключаться, быстро решать поставленные задачи, делать максимум за отведенное время.
>
3. Какие непредвиденные денежные затраты повлечет запуск проекта?
На данный момент у нас решен вопрос с оплатой труда, но на сам проект остается не так уж и много - всего меньше тысячи долларов. Нужно ли привлекать дополнительные деньги? Чем грозит попытка стартовать, опираясь на такую сумму?
4. О чем мы не подумали, и какие ходы необходимо предпринять еще?
Думайте о команде! Сейчас не важны деньги, не важен код, не важен дизайн и юзабилити - Вам сейчас нужны команда и время. У вас очень мало времени, потому что даже самая воодушевленная команда рано или поздно потеряет веру в проект, если он не начнет приносить ожидаемых результатов. Поэтому, надо на всем экономить время и быстрее - быстрее двигаться к первым видимым для всех плодам (пользователям / признанию / деньгам / ...)
По теме уже много написали, мне лично добавить нечего. Пожалуй скажу лишь, что лучше потратить денег еще на сервер, чем излишне нагружать клиента только из-за уменьшения нагрузки на сервер.
А хотел лишь пожелать удачи!:) Это вы о http://trashbox.ru/ пишете?..
А хотел лишь пожелать удачи!:) Это вы о http://trashbox.ru/ пишете?..
1. Я думаю, что Вам однозначно нужно выбрать быть ли ведущим программистом либо руководителем проекта. Не уверен, что это можно совмещать. Так как руководительствовать нужно не номинально, а реально, то есть решать очень обширный круг задач.
2. Я думаю, что в современном мире, где очень большое наличие различных продуктов, без рекламы не обойтись. Вы можете это сделать сам, если есть опыт и талант, но лучше все-таки иметь в команде профессионала, который умеет "продавать".
3. Если Вы хотите быстрых темпов, Вам нужно увеличивать бюджет для "послестарта" (затраты на оплату труда рекламиста + рекламный бюджет).
4. Могу успокоить - все, кто делает проекты, по ночам не спят и их волнует получится ли сделать дело. :)
2. Я думаю, что в современном мире, где очень большое наличие различных продуктов, без рекламы не обойтись. Вы можете это сделать сам, если есть опыт и талант, но лучше все-таки иметь в команде профессионала, который умеет "продавать".
3. Если Вы хотите быстрых темпов, Вам нужно увеличивать бюджет для "послестарта" (затраты на оплату труда рекламиста + рекламный бюджет).
4. Могу успокоить - все, кто делает проекты, по ночам не спят и их волнует получится ли сделать дело. :)
Админа, срочно админа на сервак =) если нагрузка будет расти быстро, а она будет расти быстро, если проект стоящий, только грамотный сисадмин сможет вовремя предупредить, когда надо ставить еще сервера и создать небольшой буфер времени на реализацию и настройку сервера.
По поводу генерации, 0.5 цифра не маленькая, но существует же мемкеш =) Опять же, нормальный админ обязательно поставит прослойку мемкеша. Хотя все зависит от локального сервера. Если там винда, тесты можно выкинуть и тестить на нормальном сервере =)
Вообще процесс тестирования на нагрузку не так уж и сложен, тем более что в наше время есть уже куча бенчмарков.
По поводу генерации, 0.5 цифра не маленькая, но существует же мемкеш =) Опять же, нормальный админ обязательно поставит прослойку мемкеша. Хотя все зависит от локального сервера. Если там винда, тесты можно выкинуть и тестить на нормальном сервере =)
Вообще процесс тестирования на нагрузку не так уж и сложен, тем более что в наше время есть уже куча бенчмарков.
По скорости - 0,05 ещё куда ни шло, но 0,5 без нагрузки - это ни в какие ворота не лезет.
Перед запуском обязательно проверьте сервер на устойчивость к нагрузкам, например с помощью http_load.
Что сделать, чтобы было быстрее - ну, я отсюда только пальцем в небо могу тыкать... Сейчас пишу один проект, самые сложные страницы у меня генерируются 0,02 (1/50) секунды, на них выполняется пара простых запросов к БД, для остальных страниц нормальная скорость 1/80-1/120 (120 - главная страница, обычно самая посещаемая) секунды, на стандартной для хостеров конфигурации ПО, на серверах примерно равным вашему. Достигается это благодаря кэшированию данных, запрашиваемых из БД, уменьшению include'ов и т.д.
ИМХО, если проект будет популярен и вы надеетесь с него жить - админ нужен обязательно, хотябы "по вызову", но такой, чтобы он был в курсе всей жизни сервера, а не пришел один - подкрутил, пришел другой - подкрутил.
Перед запуском обязательно проверьте сервер на устойчивость к нагрузкам, например с помощью http_load.
Что сделать, чтобы было быстрее - ну, я отсюда только пальцем в небо могу тыкать... Сейчас пишу один проект, самые сложные страницы у меня генерируются 0,02 (1/50) секунды, на них выполняется пара простых запросов к БД, для остальных страниц нормальная скорость 1/80-1/120 (120 - главная страница, обычно самая посещаемая) секунды, на стандартной для хостеров конфигурации ПО, на серверах примерно равным вашему. Достигается это благодаря кэшированию данных, запрашиваемых из БД, уменьшению include'ов и т.д.
ИМХО, если проект будет популярен и вы надеетесь с него жить - админ нужен обязательно, хотябы "по вызову", но такой, чтобы он был в курсе всей жизни сервера, а не пришел один - подкрутил, пришел другой - подкрутил.
Рекомендую опробовать Web Application Stress Tool.
Она может помочь обнаружит слабые места, и заодно "подосить" проект.
Пару месяцев назад пытался завалить движок своего проекта, но не удалось, зато нашли ошибку в железе :)
Она может помочь обнаружит слабые места, и заодно "подосить" проект.
Пару месяцев назад пытался завалить движок своего проекта, но не удалось, зато нашли ошибку в железе :)
мне показалось, что многие сразу после hello world начинают писать web2.0 проекты
при этом никто не удосужится ознакомиться с существующими практиками и теориями программирования..
давайте рассмотрим пример.
есть сайт.куча посетителей.все крутится-работает.
но в определенный момент понимаем что надо предоставить доступ к сайте людям с мобильных телефонов...
а там на многих телефонах нет полной поддержки Html, в лучшем случае xhtml, а то и вообще wml...
и что мы будем делать?! перелопачивать тонны джава скрипта? для xtml и для wml отдельно?
как уже выше говорилось правильное проектирование и применение хотя бы элементарных шаблонов программирования AKA patterns (в данном случае MVC) поможет очень сильно упростить и улучшить работу(саппорт,добавление новых сервисов и т.п.) всего проекта в дальнейшем. и проще будет искать bottlenecks.
а сервер будет дешевле проапгрейдить :)
при этом никто не удосужится ознакомиться с существующими практиками и теориями программирования..
давайте рассмотрим пример.
есть сайт.куча посетителей.все крутится-работает.
но в определенный момент понимаем что надо предоставить доступ к сайте людям с мобильных телефонов...
а там на многих телефонах нет полной поддержки Html, в лучшем случае xhtml, а то и вообще wml...
и что мы будем делать?! перелопачивать тонны джава скрипта? для xtml и для wml отдельно?
как уже выше говорилось правильное проектирование и применение хотя бы элементарных шаблонов программирования AKA patterns (в данном случае MVC) поможет очень сильно упростить и улучшить работу(саппорт,добавление новых сервисов и т.п.) всего проекта в дальнейшем. и проще будет искать bottlenecks.
а сервер будет дешевле проапгрейдить :)
Ребята-разработчики!
- Запускайте проект, не ждите! Есть что полезного для людей - начинайте.
Опыт приходит с ошибками. Запустите в онлайн, протестируйте с пользователями, сделайте работу над ошибками. Пользователи - это не поисковые роботы, у них есть эмоции. Интересный сервис, но есть недочеты, и вы хотите их исправить - они поймут. Разработчики ОС Windows не ждут 10 лет, чтобы сделать "вообще" идеальную систему, они запускают. Иначе они бы до сих пор тестировали первые окна. Учитесь у великих.
- О деньгах. Хорошая идея стоит большего чем чемодан денег. Пока вы молоды, экспериментируйте.
- Нанимайте юристов, если необходима авторская защита вашего сервиса, иначе гиганты вас сожрут.
Good luck.
- Запускайте проект, не ждите! Есть что полезного для людей - начинайте.
Опыт приходит с ошибками. Запустите в онлайн, протестируйте с пользователями, сделайте работу над ошибками. Пользователи - это не поисковые роботы, у них есть эмоции. Интересный сервис, но есть недочеты, и вы хотите их исправить - они поймут. Разработчики ОС Windows не ждут 10 лет, чтобы сделать "вообще" идеальную систему, они запускают. Иначе они бы до сих пор тестировали первые окна. Учитесь у великих.
- О деньгах. Хорошая идея стоит большего чем чемодан денег. Пока вы молоды, экспериментируйте.
- Нанимайте юристов, если необходима авторская защита вашего сервиса, иначе гиганты вас сожрут.
Good luck.
этих денег на раскрутку (самое главное) сервиса вам может не хватить.
1. По железу - советую сразу взять виртуальный выделенный сервак. На нём поднять memcache м какой-нибудь http демон для раздачи статики (nginx,lighthttpd). Если, конечно, ещё не поздно включить поддержку всех этих вещей в ваш движок.
Зачем это делать?
1.1. При большой нагрузке хостер вас по стандартным тарифам держать не будет. А судя по вашим словам у вас большая нагрузка наступит при 10 одновременных коннектах. Выделенный сервак вас жёстко будет держать в рамках конкретной производительности и доп. расходов по этой графе не будет.
1.2. Почему не свой железячный сервак? Это несколько дороже по ежемесячным расходам + сам сервак нужно ещё купить (а денег а вас не много). + виртуальный сервак легче поднимать в кризисных ситуациях - всегда можно сделать полный откат всей системы. + железячная часть вопроса вас не касается - если что-то горит или ломается, то это проблемы хостера.
1.3. Почему не простой хостинг (который дешевле)? Потому что в случае со своим сервером у вас появится возможность настроить систему под ваш движок. Поднять демонов, настроить веб-сервера, оптимизировать натройки сервера БД.
1.4. Трифик. Не знаю как там у вас, но в Киеве при нормальном отношении вход/выход (1/4) за трафик для серваков бабло не взымают. (я не говорю про все площадки, но най ти такое предложение не проблема)
2. Люди. Вам для начала нужен интернет-продвигальщик ресурса. Он же пресс-секретарь. Он же менеджер по продаже рекламы. (Можно взять троих людей но для начала лучше делегировать эти функции какому нибудь энтузиасту из тима)
3. Сразу после старта вам будет нужна критическая масса аудитории - чтобы проект был скорее жив , чем мёртв. Если аудитории не будет хватать, то её прийдется покупать. Или имитировать второе дешевле, но морально сложнее.
Желаю вам удачи, уверен что у вас всё получится.
Зачем это делать?
1.1. При большой нагрузке хостер вас по стандартным тарифам держать не будет. А судя по вашим словам у вас большая нагрузка наступит при 10 одновременных коннектах. Выделенный сервак вас жёстко будет держать в рамках конкретной производительности и доп. расходов по этой графе не будет.
1.2. Почему не свой железячный сервак? Это несколько дороже по ежемесячным расходам + сам сервак нужно ещё купить (а денег а вас не много). + виртуальный сервак легче поднимать в кризисных ситуациях - всегда можно сделать полный откат всей системы. + железячная часть вопроса вас не касается - если что-то горит или ломается, то это проблемы хостера.
1.3. Почему не простой хостинг (который дешевле)? Потому что в случае со своим сервером у вас появится возможность настроить систему под ваш движок. Поднять демонов, настроить веб-сервера, оптимизировать натройки сервера БД.
1.4. Трифик. Не знаю как там у вас, но в Киеве при нормальном отношении вход/выход (1/4) за трафик для серваков бабло не взымают. (я не говорю про все площадки, но най ти такое предложение не проблема)
2. Люди. Вам для начала нужен интернет-продвигальщик ресурса. Он же пресс-секретарь. Он же менеджер по продаже рекламы. (Можно взять троих людей но для начала лучше делегировать эти функции какому нибудь энтузиасту из тима)
3. Сразу после старта вам будет нужна критическая масса аудитории - чтобы проект был скорее жив , чем мёртв. Если аудитории не будет хватать, то её прийдется покупать. Или имитировать второе дешевле, но морально сложнее.
Желаю вам удачи, уверен что у вас всё получится.
Вообще, звучит все обескураживающе несерьезно. 1000 долларов... один программист... отсутствие рекламной стратегии... Даже не представляю, что можно в такой ситуации посоветовать. Ваш единственный шанс - инновационность. Не будет последней, просто набьете себе шишку. Шишки, порой, важнее успеха.
Сейчас самое время задуматься над продвижением ресурса.
Если ваш ресурс не уникален (а по содержанию топика складывается именно такое мнение), то вам однозначно необходим человек, который будет заниматься медиапланированием.
Для выполнения производственный функций (скупка ссылок, оптимизация, работа с аккаунтами в контексте) можно привлечь сторонних специалистов, но для руководства проектом продвижения вам необходим человек в штате.
По-поводу 1K$ - на продвижение этого мало.
Даже не зная специализации вашего проекта, я уверен в этом на 100%.
С 1K$ можно провести неплохую кампанию на директе и бегуне, но для тотального покрытия вам необходимо использовать и такие методы, как вирусный маркетинг, партизанщина, может быть флеш-мобы, ну и, естественно, обычная медийка на тематических сайтах.
Нужен бум. Пусть он будет кратковременным и частота контакта будет минимальная, но покрытие должно быть максимальным. Вы не йогуртами торговать собираетесь, поэтому 1, 2-х контактов будет вполне достаточно. Заинтересованная публика обязательно посетит ваш сайт. И, если проект окажется интересным, то вы получите постоянного посетителя.
Вообще, очень много нюансов, которые складываются из специфики конкретного проекта, и, естественно, что их учесть я не могу, так как просто не знаю - о чём идет речь. (я имею в виду такого рода проекты, как "одноклассники" и "в контакте", где основную роль в продвижении сыграл вирусный маркетинг).
Если ваш ресурс не уникален (а по содержанию топика складывается именно такое мнение), то вам однозначно необходим человек, который будет заниматься медиапланированием.
Для выполнения производственный функций (скупка ссылок, оптимизация, работа с аккаунтами в контексте) можно привлечь сторонних специалистов, но для руководства проектом продвижения вам необходим человек в штате.
По-поводу 1K$ - на продвижение этого мало.
Даже не зная специализации вашего проекта, я уверен в этом на 100%.
С 1K$ можно провести неплохую кампанию на директе и бегуне, но для тотального покрытия вам необходимо использовать и такие методы, как вирусный маркетинг, партизанщина, может быть флеш-мобы, ну и, естественно, обычная медийка на тематических сайтах.
Нужен бум. Пусть он будет кратковременным и частота контакта будет минимальная, но покрытие должно быть максимальным. Вы не йогуртами торговать собираетесь, поэтому 1, 2-х контактов будет вполне достаточно. Заинтересованная публика обязательно посетит ваш сайт. И, если проект окажется интересным, то вы получите постоянного посетителя.
Вообще, очень много нюансов, которые складываются из специфики конкретного проекта, и, естественно, что их учесть я не могу, так как просто не знаю - о чём идет речь. (я имею в виду такого рода проекты, как "одноклассники" и "в контакте", где основную роль в продвижении сыграл вирусный маркетинг).
опыт, вот что самое ценное :)
ну а в целом мой прогноз скорее печальный, чем радужный ) хотя загадывать не стоит :)
ну а в целом мой прогноз скорее печальный, чем радужный ) хотя загадывать не стоит :)
o. Apache, mysql – хорошо. php – странный выбор (игрушки всё это. что сказали юзабилисты?!).
o. Системного администратора вам надо (как правильно кто-то сказал(и)). ох, как он вам пригодиться.
o. Оплата труда - не принципиально (на начальном этапе!). главное – идея. кто не согласен – идет искать другие стартапы.
o. Первый проект – плохо. Желательно иметь живой некоммерческий проект (там всё основное и усвоите).
o. Юрист нужен, но на пару-тройку консультаций (трудно подсадить юриста на идею/зарплату).
o. PR – да. SEO (- зло) – полезная вещь. Нужен грамотный специалист.
o. Системного администратора вам надо (как правильно кто-то сказал(и)). ох, как он вам пригодиться.
o. Оплата труда - не принципиально (на начальном этапе!). главное – идея. кто не согласен – идет искать другие стартапы.
o. Первый проект – плохо. Желательно иметь живой некоммерческий проект (там всё основное и усвоите).
o. Юрист нужен, но на пару-тройку консультаций (трудно подсадить юриста на идею/зарплату).
o. PR – да. SEO (- зло) – полезная вещь. Нужен грамотный специалист.
> На данный момент у нас есть программист
У нас в группе были барабаны, гитары и клавиши. Три. Две черных и одна белая. :)
Вам точноне хватает программистов.
У нас в группе были барабаны, гитары и клавиши. Три. Две черных и одна белая. :)
Вам точноне хватает программистов.
По первому вопросу: возьмите любую стресс утилиту Например тот же Web Application Stress Tool от Microsoft (http://www.microsoft.com/downloads/detai…) [он бесплатный]
Если не позволяет религия брать Microsoft то возьмите какой нибудь другой стресс тест. Погоняйте на нагрузке так 30 ежемоментных пользователей.
1.1 Если увидели что не справляется, подумайте о кешировании (хотя специфика контента может вам не позволить так себя спасти).
2. Попробуйте спрогнозировать посещаемость. Я бы рекомендовал в зять аренду у хостера сервер (самый простой) и пусть хостер его настроит и поддерживает первый месяц. Хостеру обязательно озвучьте прогнозируемый трафик. И сразу ищите администратора. В принципе за $250-$300 в месяц можно найти человека который вас поддержит на первых порах (2-3 месяца). (если что - обращайтесь, есть специалист на примете на первое время).
3. Заранее продумайте действия на случай неожиданного наплыва посетителей (или dos атаки). Какая у вас будет стратегия и что вы выведете в качестве сообщение об ошибке.
вот вроде все советы. Чем мог, помог.
Если не позволяет религия брать Microsoft то возьмите какой нибудь другой стресс тест. Погоняйте на нагрузке так 30 ежемоментных пользователей.
1.1 Если увидели что не справляется, подумайте о кешировании (хотя специфика контента может вам не позволить так себя спасти).
2. Попробуйте спрогнозировать посещаемость. Я бы рекомендовал в зять аренду у хостера сервер (самый простой) и пусть хостер его настроит и поддерживает первый месяц. Хостеру обязательно озвучьте прогнозируемый трафик. И сразу ищите администратора. В принципе за $250-$300 в месяц можно найти человека который вас поддержит на первых порах (2-3 месяца). (если что - обращайтесь, есть специалист на примете на первое время).
3. Заранее продумайте действия на случай неожиданного наплыва посетителей (или dos атаки). Какая у вас будет стратегия и что вы выведете в качестве сообщение об ошибке.
вот вроде все советы. Чем мог, помог.
Дерзайте! Смелее! И ищите партнёров! Придумывайте свои фишки! Свои сериалы;) Мобильный контент? придумайте предисторию, 5 вариантов развития, снабдите бешенной графикой и заинтригуйте продолжением:) в таком случае сарафанное радио вам подспорье;)
а ещё предложите новому челу взглянуть на всё свежим взглядом, протестить юзабилити и вообще: "а на фиг мне ваш сайт"
удачи!
а ещё предложите новому челу взглянуть на всё свежим взглядом, протестить юзабилити и вообще: "а на фиг мне ваш сайт"
удачи!
Не, ну вы вот тут конечно много всякого наговорили, а с бухгалтерией-то что? С налоговой? Форма налогообложения? Как вам наш налоговый кодекс? Впечатлил? Образцы договоров уже составили? Юристу дали посмотреть?
А вдруг все получится - завтра придет человек с чемоданом денег (можно аналог в виде банковского счета) - вы можете со 100% уверенностью сказать, как вы у него эти деньги брать будете? и как оформлять?
Есть, конечно, бухгалтерские, юридические, налоговые, и прочие центры, которые могут снять с вас часть нагрузки. А могут и не снять. Специалист такого центра - делает свою работу, а не вашу. И на что-то может совершенно спокойно не обратить вашего внимания. Поэтому - доверяй, но проверяй, хотя бы на начальных этапах. А для этого нужны знания.
99% дальше разговоров не уходят. 99% процентов ушедших дальше - не доходят до оформления. 99% дошедших до оформления - банкротятся.
В любом случае - удачи вам.
А вдруг все получится - завтра придет человек с чемоданом денег (можно аналог в виде банковского счета) - вы можете со 100% уверенностью сказать, как вы у него эти деньги брать будете? и как оформлять?
Есть, конечно, бухгалтерские, юридические, налоговые, и прочие центры, которые могут снять с вас часть нагрузки. А могут и не снять. Специалист такого центра - делает свою работу, а не вашу. И на что-то может совершенно спокойно не обратить вашего внимания. Поэтому - доверяй, но проверяй, хотя бы на начальных этапах. А для этого нужны знания.
99% дальше разговоров не уходят. 99% процентов ушедших дальше - не доходят до оформления. 99% дошедших до оформления - банкротятся.
В любом случае - удачи вам.
http://avaload.ru/2007/08/31/gorkaja_pravda_o_setevom_proekte_v_kontakteru.html
Никто не читал про стартап соц сети Вконтакте? Не укладываются у меня в голове такие цифры...
Никто не читал про стартап соц сети Вконтакте? Не укладываются у меня в голове такие цифры...
Это смешно. Там основные расчеты сделаны исходя из строчек
created: 2006.10.01
paid-till: 2008.10.01
А это лишь означает то, что _домен_ проплачен на два года вперед. Но не хостинг.
Кроме того, цифры смешные - профиль 200 кб. Профиль - текстовые записи. 200 кб - половина книги. Откуда? Даже при идиотском проектировании БД трудно достичь такого чудовищного размера.
Да и со стоимостью размещения объема данных автор приврал.
Итого - на каждом этапе по несколько порядков. Плюс дата, которая вовсе не говорит о проплате всего хостинга.
Недоброжелатели.
created: 2006.10.01
paid-till: 2008.10.01
А это лишь означает то, что _домен_ проплачен на два года вперед. Но не хостинг.
Кроме того, цифры смешные - профиль 200 кб. Профиль - текстовые записи. 200 кб - половина книги. Откуда? Даже при идиотском проектировании БД трудно достичь такого чудовищного размера.
Да и со стоимостью размещения объема данных автор приврал.
Итого - на каждом этапе по несколько порядков. Плюс дата, которая вовсе не говорит о проплате всего хостинга.
Недоброжелатели.
Александр, хотим пригласить Вас и Вашу команду выступить у нас в "Start-up Coffee" на ближайшей High-Tech вечеринке. Рассказать о Вашем проекте, услышать отзывы и комментарии. Подробная информация о нас здесь: http://start-up-coffee.blogspot.com/
Напишите нам на e-mail: startup@siteheart.com или позвоните +38 098 505-56-06, +38 (056) 370-98-73,
iсq 440767735.
Напишите нам на e-mail: startup@siteheart.com или позвоните +38 098 505-56-06, +38 (056) 370-98-73,
iсq 440767735.
Правильно то, что создали этот топик.
Всякое медиапланирование и позиционирование можно делать лишь в общих чертах, т.к. просчитать все слагаемые успеха невозможно. Самое главное - это готовность меняться, это залог успеха.
Социологические опросы, фокус-группы и т.п. по карману большим конторам, а маленьким стартапам нужно больше общаться (что Вы и делаете), думать, изобретать.
Отсутствие рекламщика можно восполнить грандиозностью нововведений, которые станут обсуждаться. Надо создавать яркие новости: "мы открылись", "стартап стал самым быстрорастущим", и т.п. Естественно, со скандалами в рекламе надо быть аккуратнее.
Всякое медиапланирование и позиционирование можно делать лишь в общих чертах, т.к. просчитать все слагаемые успеха невозможно. Самое главное - это готовность меняться, это залог успеха.
Социологические опросы, фокус-группы и т.п. по карману большим конторам, а маленьким стартапам нужно больше общаться (что Вы и делаете), думать, изобретать.
Отсутствие рекламщика можно восполнить грандиозностью нововведений, которые станут обсуждаться. Надо создавать яркие новости: "мы открылись", "стартап стал самым быстрорастущим", и т.п. Естественно, со скандалами в рекламе надо быть аккуратнее.
Контент? Как юзер придет на пустой сайт. Ищите копирайтеров, пусть пишут качественный контент. Даже на хабре есть нанятые люди которые пишут контент. Если бюджет так мал, то урежьте свои зарплаты, но пустой сайт без рекламы и контента, это все равно что сказать сотне программеров — вот вам 100 компов с любыми операциоками и средами разработки, напишите мне мега продукт. Первоначальный контент должен задать генеральную линию движения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Начинаем. Все правильно?