В связи с этим мне интересно — разработчики не используют какую-нибудь хитрую стратегию запуска нескольких процессов для обхода данного ограничения на 32-х битных платформах?
Наверно, секрет кроется между строк «на серверах, которые я админю». Я вот тоже удивлён тем, что люди испытывают какие-то затруднения с генту, но богатый опыт решения человеческих затруднений с виндой подсказывает — простые неопытные пользователи ухитряются находить баги похлеще матёрых тестеров.
К сожалению — были хорошие статьи об архитектуре Яндекса — что-то вроде «научно популярных» объяснений, но я сейчас совершенно не могу их найти :-( Было бы очень неплохо, если бы информация об архитектуре тактих систем была из первых рук — нужно будет всё-таки засесть в поисковик, найти и надёжно перепрятать в закладки :-)
Разумеется, я не отрицаю, что что-то в Яндексе и Гугле таки сохраняется на диск. Но в целом — для большинства задач это им не нужно, хранение в памяти более чем достаточно и более чем удобно и надёжно.
И конечно эти тезисы про надёжность и удобство не относятся к системам работающим на одной-двух locost машинах — здесь совсем другие реалии.
Существует целый класс баз данных, которые работают исключительно с памятью. Подобный подход применяется далеко не только упомянутыми монстрами веба, но и в энтерпрайзе.
Не было выполнено — поскольку «работает» без доработок лишь частично: оно работает хуже и с ошибками. И эти баги исправлять — задача на порядки более сложная.
Я не использую чужие модули таким образом. Обычно идёт значительный оверхед, поскольку пишется на все случаи жизни.
Я нахожу подходящий модуль или похожий проект, смотрю как он реализован и реализую в контексте своей задачи. В крайнем случае включаю в свой проект нужные мне классы — как-то так оно получается.
Разумеется, есть исключения — вроде того же geoip, который можно использовать только как цельное дополнение к движку php, либо такие вещи как фреймворки — если проект построен на ZF — там уже в комплекте столько всего, что искать что-то ещё обычно не приходится. ZF вообще некоторые называют «PEAR для Enterprise».
Так что, можно посмотреть в сторону Zend Framework или Symphony — там очень много всего и многие комоненты можно использовать отдельно, не внедряя фреймворк в свой проект целиком.
Я о том, что нет никакой проблемы — на массе движков сессии создаются автоматом и не являются бутылочным горлышком.
Файловая система также кешируется — это не проблема. До тех пор пока проект живёт на одной машине этот кеш работает исключительно великолепно.
10к человек в день — это ещё даже не нагрузка. В среднем 7 человек в минуту и при учёте разности плотности посещений в 3 раза — в пике один человек в три секунды. Здесь ещё огромный запас на то, чтобы количество хитов на каждого человека было порядка полусотни на не самом дорогом хостинге.
10к человек, которые ломятся на сайт одновременно? Это уже совсем другой разговор и другие технологии. 99,9% сайтов не испытывают подобной нагрузки.
Хорошо, попробую объяснить свою точку зрения на практическом примере: великолепный проект repl.it/#
Возьмём питон. Вот он транслированный в javascript: raw.github.com/replit/empythoned/master/dist/python.opt.js
Задача: впилить сюда интеграцию с браузером и DOM страницы.
Теперь Вы понимаете разницу между портировать и просто транслировать? Портированный — был бы читабельным аналогом оригинального кода и можно было бы легко найти соответствия и оперировать ими, можно было бы легко изучать структуру. Транслрованный — просто мешанина однообразных символов с точки зрения человека. Про неоптимальность этого кода для целевой платформы — я уже тоже упоминал.
Да, это работает. Но, сделать с этим что-то вменяемое по целесообразной цене — нереально.
Программа состоит не только из циклов for. И есть ситуации когда то, что эффективно в оригинале, транслированное становится очень неэффективным. И есть конструкции, имеющиеся в оригинальной платформе, но эмулируемые на конечной. Или в Вашем понимании вся трансляция сводится к замене одного синтаксиса на другой? Если бы всё было так просто — не было бы такого количества языков, а была бы масса препроцессоров для одного.
Вы просто ставите акцент на то, что ВСЁ должно быть где-то в каком-то едином репозитории. Здесь Вы правы — в PHP такого явления нет и вероятно никогда не будет. Бардак и демократия — полностью в духе коммьюнити :-)
Я же эту точку зрения на необходимость чего-то единого — не разделяю. Весь нужный в моём проекте код находится в моём проекте — с конкретной версией, с которой проект протестирован, возможно даже с моими патчами, которым скорее всего нечего делать в оригинальном продукте. Исключение — модули PECL, которые нужно компилить.
Но всё это имеет мало отношения к тому, с чего началось обсуждение — наличие модулей и наличие в PEAR/PECL чего-то полезного.
Правильное решение наверно было бы сохранять последнее выставленное пользователем значение и все автоматические изменения после преобразований и отмен возвращать к нему.
Это каким-то образом мешает писать говнокод? Нет.
Это мешает писать глючные программы? Ни капли.
Тогда при чём тут жёсткая семантика?
Можно написать очень понятный и чёткий код, который и человек хорошо прочитает, и интерпретатор/компилятор хорошо оптимизируют.
А можно написать нечто ужасное. Вот итог работы автоматических трансляторов (особенно через несколько этапов трансляции), программ оптимизированных совсем не под конечную платформу — и есть такой ужас.
При этом без возможности нормально исправить баг вылезший на неродной платформе.
Моя сфера деятельности — веб-программирование. И код пронизанный спагетти, SQL-инъекциями, без тестов в принципе — я называл и буду называть плохим, что бы на тему относительности кто ни говорил )))
Да, бывают нюансы, бывают более важные обстоятельства — я сам это признаю и действую исходя из этого. Но «нюансы» и «обстоятельства» возведённые в систему, технический долг, который никто даже не планирует закрывать — это таки плохо, очень плохо.
В итоге это ведёт к потерям времени и результатов труда у большого количества людей, если продукт идёт в тираж. И я сам могу привести немаленький список подобных программ, с некоторыми из которых мне приходилось работать самому — плеваться на качество, но всё равно работать, поскольку вариантов исправить ошибки (элементарно достучаться до разработчика) или заменить на что-то другое — просто не было. А поставщик (контора, не конкретный программист) — свои деньги получил и был доволен, ему ничего не нужно менять в своей бизнес-модели — всё и так хорошо. И я, как умудрённый таким опытом пользователь, прекрасно понимаю, к чему приведёт то, что буду я писать уступая работодателю или представителю заказчика, которых не интересует конечный продукт, а интересует лишь тот этап, когда деньги переходят со счёта на счёт, возможно, кто-то получает свой откат. Для него — это единственный показатель. Но не для меня.
Так я вроде это и описал — возможно недостаточно однозначно, сорри, у меня уже полночь, а я занимаюсь получением удовольствия от своего дела и по выходным — глаза уже слипаются )
(Но однако как непривычно обходиться без слова «работа» ))
Разумеется, я не отрицаю, что что-то в Яндексе и Гугле таки сохраняется на диск. Но в целом — для большинства задач это им не нужно, хранение в памяти более чем достаточно и более чем удобно и надёжно.
И конечно эти тезисы про надёжность и удобство не относятся к системам работающим на одной-двух locost машинах — здесь совсем другие реалии.
Существует целый класс баз данных, которые работают исключительно с памятью. Подобный подход применяется далеко не только упомянутыми монстрами веба, но и в энтерпрайзе.
Я нахожу подходящий модуль или похожий проект, смотрю как он реализован и реализую в контексте своей задачи. В крайнем случае включаю в свой проект нужные мне классы — как-то так оно получается.
Разумеется, есть исключения — вроде того же geoip, который можно использовать только как цельное дополнение к движку php, либо такие вещи как фреймворки — если проект построен на ZF — там уже в комплекте столько всего, что искать что-то ещё обычно не приходится. ZF вообще некоторые называют «PEAR для Enterprise».
Так что, можно посмотреть в сторону Zend Framework или Symphony — там очень много всего и многие комоненты можно использовать отдельно, не внедряя фреймворк в свой проект целиком.
Файловая система также кешируется — это не проблема. До тех пор пока проект живёт на одной машине этот кеш работает исключительно великолепно.
10к человек в день — это ещё даже не нагрузка. В среднем 7 человек в минуту и при учёте разности плотности посещений в 3 раза — в пике один человек в три секунды. Здесь ещё огромный запас на то, чтобы количество хитов на каждого человека было порядка полусотни на не самом дорогом хостинге.
10к человек, которые ломятся на сайт одновременно? Это уже совсем другой разговор и другие технологии. 99,9% сайтов не испытывают подобной нагрузки.
Возьмём питон. Вот он транслированный в javascript: raw.github.com/replit/empythoned/master/dist/python.opt.js
Задача: впилить сюда интеграцию с браузером и DOM страницы.
Теперь Вы понимаете разницу между портировать и просто транслировать? Портированный — был бы читабельным аналогом оригинального кода и можно было бы легко найти соответствия и оперировать ими, можно было бы легко изучать структуру. Транслрованный — просто мешанина однообразных символов с точки зрения человека. Про неоптимальность этого кода для целевой платформы — я уже тоже упоминал.
Да, это работает. Но, сделать с этим что-то вменяемое по целесообразной цене — нереально.
Я же эту точку зрения на необходимость чего-то единого — не разделяю. Весь нужный в моём проекте код находится в моём проекте — с конкретной версией, с которой проект протестирован, возможно даже с моими патчами, которым скорее всего нечего делать в оригинальном продукте. Исключение — модули PECL, которые нужно компилить.
Но всё это имеет мало отношения к тому, с чего началось обсуждение — наличие модулей и наличие в PEAR/PECL чего-то полезного.
Это мешает писать глючные программы? Ни капли.
Тогда при чём тут жёсткая семантика?
Можно написать очень понятный и чёткий код, который и человек хорошо прочитает, и интерпретатор/компилятор хорошо оптимизируют.
А можно написать нечто ужасное. Вот итог работы автоматических трансляторов (особенно через несколько этапов трансляции), программ оптимизированных совсем не под конечную платформу — и есть такой ужас.
При этом без возможности нормально исправить баг вылезший на неродной платформе.
Да, бывают нюансы, бывают более важные обстоятельства — я сам это признаю и действую исходя из этого. Но «нюансы» и «обстоятельства» возведённые в систему, технический долг, который никто даже не планирует закрывать — это таки плохо, очень плохо.
В итоге это ведёт к потерям времени и результатов труда у большого количества людей, если продукт идёт в тираж. И я сам могу привести немаленький список подобных программ, с некоторыми из которых мне приходилось работать самому — плеваться на качество, но всё равно работать, поскольку вариантов исправить ошибки (элементарно достучаться до разработчика) или заменить на что-то другое — просто не было. А поставщик (контора, не конкретный программист) — свои деньги получил и был доволен, ему ничего не нужно менять в своей бизнес-модели — всё и так хорошо. И я, как умудрённый таким опытом пользователь, прекрасно понимаю, к чему приведёт то, что буду я писать уступая работодателю или представителю заказчика, которых не интересует конечный продукт, а интересует лишь тот этап, когда деньги переходят со счёта на счёт, возможно, кто-то получает свой откат. Для него — это единственный показатель. Но не для меня.
(Но однако как непривычно обходиться без слова «работа» ))