TipTop

Делайте свои выводы господа и внимательней работайте с этой биржей.

Тот, кто сделал правильные выводы, работает теперь с другими биржами.

Начнем с того, что вам это вряд ли нужно для практических целей. В сутках 86400 секунд. Средний нормально написанный сайт (не друпал, не phpBB и прочий кривокод. Не Zend и не симфони) на PHP с использованием MySQL на среднем сферическом VPS в вакууме (с объемом памяти в 256 Мб) выдерживает 40-50 rps. Иногда даже он упирается не в процессор, а в ширину канала.

40-50 rps * 86 400 = примерно 1-2 млн хитов в сутки (так как нагрузка неравномерна по времени суток). Это примерно 100-200 тыс. среднеактивных посетителей (или 20-50 тыс., если речь не о блоге а о соцсети). Вряд ли у вас столько будет.

От идеи генерировать статический HTML давайте откажемся сразу: любой функционал чуть сложнее набора неизменных страниц так не сгенерируешь. Сложность кода и число зависимостей кешей будет расти в геометрических прогрессиях. Идея вставлять динамические фрагменты страниц через SSI/AJAX бесперспективна — они все равно будут вызывать запуск PHP, возможно даже увеличивая нагрузку. Лучше написать масштабируемое приложение с хорошим кешированием данных.

Хорошей идеей мог бы быть отказ от PHP в пользу Java/C++/.NET/D. Но это усложнит разработку: на этих языках все сложнее и дольше пишется.

Даже если на ваш блог ринутся все читатели Хабра, tema и еще нескольких блогов. Имея грубо написанный самопис на кривоPHP, у нас есть возможность масштабироваться раз в 10 с ростом нагрузки: ставим более мощное железо, расширяем память с 256 Мб до 64 Гб, ставим нормальный 8-ядерный процессор, нормальные диски. Тюним объем кешей MySQL, добавляем APC, начинаем понемного кешировать страницы в мемкеш. Далее, если нагрузка все равно растет, разносим код на несколько фронтендов, и, возможно, делаем мастер-слейв на MySQL. Можно скомпилировать PHP через hiphop.

Многим проектам этого хватает.

Но это тупой подход. Сделать репликацию, поставить балансировщик и нарастить память — ума много не надо. Даже обезьяна с этим справится. Гораздо лучше (и интереснее) изначально делать приложение с учетом возможности масштабироваться (что уж там стесняться) неограниченно. И куда как приятнее осознавать, что твое приложение может расти не хуже вконтакта с его отличниками и победителями математических олимпиад.

Представим, что у нас растет нагрузка и нам надо увеличиться до 1000 нод. Что касается фронтендов (в вашем случае на PHP), если не хватает мощности одного сервера, их (серверов) мы легко можем поставить хоть 1000, хоть 10000 (единственное, надо отказаться от сохранения сессий в локальных файлах, иначе никто не сможет залогиниться. Возможно, стоит перейти на REST и вообще отказаться от сессий). Перед ними ставим N балансировщиков на nginx, настраеваем round-robin в DNS (чтобы запросы валились на них поочередно).

Как работает round-robin в DNS вы можете увидеть, набрав nslookup vk.com несколько раз.

Мемкеш также (вы должны использовать мемкеш в приложении) легко масштабируется на N серверов. Лишь бы памяти было много и минимум гигабитная локальная сеть.

Раздача статики (картинки, CSS, скрипты) тоже банальна — ставим nginx на N серверов и забываем об этой проблеме. Единственная сложность — это раздача видео. Погуглите, на Хабре есть статьи про организацию CDN для видео и сопутствующие проблемы.

А вот с БД мы получаем затык. Даже если мы настроим мастер-слейв с несколькими слейвами, объем данных на запись на мастер от 1000 PHP-ных фронтендов положит любой сервер. Несмотря на то, что MySQL в сферической конигрурации на среднем сервере в вакууме легко делает 1-5 тысяч выборок по PKEY в секунду, на запись она работает гораздо хуже. Потому, раз уж мы делаем хайлоад сервис, то база тоже должна масштабироваться. Во-первых, можно разнести разные таблицы на разные сервера. Это мало. во-вторых, можно порезать таблицы на куски и разнести на разные сервера. Это то, что надо. То есть, допустим, в соцсети юзеры с ид 1-10000 хранятся на первом сервере в таблице users_1, юзеры 10000-20000 на втором сервере в таблице user_2, и так далее. Распределение записей и таблиц по серверам должно быть не намертво вбитое, а конфигурируемое, чтобы можно было переносить пачки записей с одного сервера на другой, уравновешивая нагрузку. Для этого придется написать небольшое приложение, показывающее распределение нагрузки и позволяющее переконфигурировать шарды.

Из такой схемы построения БД вытекают очевидные правила: запросы к БД не должны использовать JOIN (так как это невозможно при разнесенных таблицах, и дждойны плохо работают), должны использовать выборку только по индексам, лучше всего по PKEY (так как без индексов слишком медленно) и должны быть как можно проще. Они должны иметь небольшой LIMIT. Также, стоит пользоваться денормализацией данных: например, чтобы получить список фотографий пользователя, мы берем сериализованный список id этих фото, затем выбираем фото по id, а НЕ используем выборку по полю user_id в таблице photos (так как такая выборка не шардится и не масштабируется).

В общем, запросы должны быть тупыми как пробка и сводиться к SELECT… WHERE id IN (1, 2, 3). Кстати, как дополнительный плюс, такие запросы легко кешировать и очищать такой кеш.

Для сервисов типа поиска пользователей (как вконтакте) при такой схеме придется писать отдельные приложения на C++, которые будут индексировать БД и хранить данные в памяти. Увы, PHP тут не справится.

Вы можете почитать про архитектуру высоконагруженных проектов тут: www.insight-it.ru/highload/

А да, все. что написано выше, лишь теоретические рассуждения. Подумайте 10 раз, прежде чем применять это на практике.

Ответ теоретический, вне контекста php:

1. В общем случае, хранить все в .html — не быстрее.

1. 1 Если их мало и можно все хранить в ОП, то нет необходимости хранить кучи мелких файлов. Но сериализация нужна (на случай перезагрузки).

1. 2. Если файлов намного больше, чем можно впихнуть в ОП, то хранение всего в файлах, будет менее эффективно, чем другие методы. Дело в том, что таким файлам свойственно иметь большой процент общей информации. По сути в каждом файле .html может быть от 0% до 100% уникальной информации, для упрощения выкладки, припустим что это значение равно 50%. Тогда, вами используемые средства, делают на 50% больше операций чтения/записи на файловой системе, которая, кстати, является самым слабым звеном производительности, в большинстве случаев.

Если вы храните 50% общей информации (html-шаблоны) в ОП (что в большинстве случаев возможно), то вы на 50% снижаете нагрузку с файловой системы. Если быть точным, то не 50%, а вроде чуть больше, но это уже другой вопрос с «глубоким углублением».

Если 50% уникальной информации, сложны в построении (что маловероятно), либо строятся (вычисляются / считываются) не оптимальным образом, то стоимость их построения может быть выше, чем двукратная стоимость операций на файловой системе, и тогда ваш метод эффективней, но это только по отношению к операциям чтения.

Операция записи в вашем случае, в среднем будет иметь более 95% избыточности, в случае полной перезаписи. Этого можно избежать если в файле перезаписывать только то, что изменилось, но в общем случае, с учетом устройства файловых систем, это очень сложно с точки зрения системного и алгоритмического программирования.

Таким образом, у вас сильно увеличивается нагрузка на файловую систему, что сделает ваш сайт менее эффективным, по сравнению с разработками НИИ.

2. Рекомендую использовать БД. Каждая современная СУБД, крайне не эффективна, и делает то, что вам не нужно (и не один раз). Но чтобы сделать что-то лучше, конкретно для своего проекта, потребуется очень много времени.

3. Если стоит задача сделать безопасный, быстрый, надежный сайт то, я думаю, php, asp.net, python, ruby, node.js никоим образом не сравнятся с системным программированием на С/С++/Delphi (внезапно да, даже Делфи).

4. То, что вы предлагаете — светлая инженерная мысль, удачи вам.

я в дропбокс кидаю симлинки нужных мне директорий, файлов и он синхронизирует по ним их содержимое

прикол в том что мой старый контракт содержал пункт о неразглашении условий найма :)
а вообще — не хотите не говорите, а можете задать встречный вопрос — какая вилка по зарплате у них есть.

Озвучьте свою предполагаемую зарплату на новом месте, +20%, какие проблемы?
Либо работодатель согласится ( вам плюс ), либо будет торговаться, а у вас есть 20% запаса

поддерживаю! Koss The Plug, но сейчас затычки от Panasonic, которые уже второй год не убить :( а я ведь стараюсь…

Для меня фаворитом остаются: Koss The Plug

У меня навенорное проклятие какое то. Спустя 2 года в гугле ищу такую же проблему но уже с AIR и попадаю на свой же вопрос…

Поддерживаю dual boot.

Сам недавно вернулся на Win 7 с Arch Linux. Основная причина — бесит KDE, GNOME, XFCE…, а aero просто шикарен. Что касается LibreOffice уже ответили, Qt Creator для с++ — лучше MS Visual Studio 2010 во всех отношениях, кроме как дебага.
Wine — очень крутая и сильная штука, но пока что умеет не все, и бывают глюки. Windows 7 — рядом, в dual boot — очень рекомендую.

программирование в компьютерных системах ассоциируется с Python,
прикладная информатика в экономике — с Excel и написанием бота для любой торговой площадки, причем, язык не важен.

— программирование в компьютерных системах (ПКС);
Только низкоуровневые, которые дают представление о внутреннем устройстве ПК, его функционировании, типах данных и т.д. Си, Паскаль, да хоть Бейсик, нет разницы

— прикладная информатика в экономике (ПИ).
VBA, потому что экономист без экселя — экономист-инвалид

Если бы я обучался хотел бы осваивать ruby или python.
IDE jetbrains (по выбору).

1. Delphi, C++ (visual studio / qt)
2. VBA, 1C (?)

Если есть хорошая идея, и вы ищите людей которые могли бы реализовать ее за долю прибыли — остановитесь, ваша идея фигня полная и никто никогда не будет ее реализовывать.

Программисты, дизайнеры, художники, верстальщики — инженеры, никогда не ценят идеи (почти все, поголовно так сказать).

Другое дело — если вы и сами инженер и готовы тратить и свое время, и ваше время дорогого стоит (инженер высокого уровня), тогда и я готов выслушать.

В рунете куча площадок «биржи стартапов», форумы программистов всякие… одного большого ресурса по этому делу нет. поисковик вам поможет, а не конкретный сайт.

Я не специалист, но если руководствоваться здравым смыслом, то ниша сильно влияет. Ноутбуки востребованы, но конкуренция на рынке слишком большая. Вам придется изрядно постараться что бы привлечь покупателей. Обычно это какие-то акции, более качественный сервис за ту же сумму и т.д. С другой стороны если выбрать более специализированную нишу, количество клиентов будет сильно ограниченным. Но если конкуренция не большая, шанс на большую прибыль выше.

Думаю, найдутся из 100 человек 82 с торентами в автозагрузке и никакой йоты не хватит. Лучше всего каждому выдать по модему отдельному. Договориться с местными сетями о скидке-промо акции, а участникам «дарить», включив в стоимость билета.

Сам несколько раз сидел в офисе с йоты, хоть и было четверо, было ужасно, хотя это может быть загруженность сети в принципе для центра москвы в рабочее время. с билайн вай фай было лучше, но все равно плохо, теперь вместо офиса арендуем квартиру с выделенной домашней линией.

Хотя йота вчера обновила сети. Не знаю, как сейчас. Я рекомендую каждому по модему дать.