Розгорнути попередні цитати...

dmp, 20 листопада 2017 11:47:25

fam, 20 листопада 2017 11:32:09

и еще

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

Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.

Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?

хм.. а если сервер перестал справляться и  без "моего кода", то что произойдет?

попробуйте сами понять чем эти ситуации различаются.

Розгорнути попередні цитати...

fam, 20 листопада 2017 12:42:36

dmp, 20 листопада 2017 11:47:25

Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.

Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?

хм.. а если сервер перестал справляться и  без "моего кода", то что произойдет?

попробуйте сами понять чем эти ситуации различаются.

ничем, я думаю

Розгорнути попередні цитати...

dmp, 20 листопада 2017 12:45:55

fam, 20 листопада 2017 12:42:36

хм.. а если сервер перестал справляться и  без "моего кода", то что произойдет?

попробуйте сами понять чем эти ситуации различаются.

ничем, я думаю

ОК, я попробую объяснить, хотя выше ключевое слово уже назвали

Вообще довольно регулярно вижу, что программисты не верят в свои проекты, не задаются вопросом "а что будет если мой проект станет популярным?" Есть ли план что делать, если нагрузка будет резко расти? Пусть сегодня это проект на PHP+MySQL, но принимая то или иное техническое решение всегда полезно задаваться этим вопросом и держать план реагирования на рост под рукой.

Предположим имеем ваш PHP код и сервер базы данных на одном сервере, ну и при модификации базы данных скешировали в файл что-то там. Все работает замечательно.

Но тут вы получаете рост нагрузки. Что делаем первым делом? Логично разнести приложение и базу данных по разным серверам. База данных пыхтит отдельно, кеш с админкой на одном web сервере.

Все пока работает, но нагрузка растет и видно, что PHP приложение не справляется, логично что сделать? Правильно, запускаем еще один web сервер. Уже возникает проблема, файл к кешем создается на одном веб сервере, с админкой, а нужен еще и на втором. Ну вроде не страшно, скопировали файл и живем дальше. Стало немножко неудобно копировать каждый раз после модификации базы данных, но пережить можно.

Нагрузка еще выросла, вы запустили 10 серверов. Копировать файл руками вам надоело и вы стали его при модификации автоматически пихать на сервера. Пришлось немного написать кода, но все ведь работает!

Тут выяснилось, что вы сделали супер сервис и он нужен всем! Нагрузка выросла сильно и вы запустили 100 инстансов веб сервера. С процедурой копирования файла начались сложности, выяснилось, что не все 112 серверов работают одновременно, кто-то перегружается, а кто-то сломался. Выяснилось, что  push работает не очень здорово сам по себе, нужно еще делать запрос конфигурации из какого-то центрального хранилища при старте инстансов и еще как-то это совместить с процедурой деплоя свежих версий приложения.

Фак.

p.s. и тут начинает дымить сервер базы данных и вам требуется кешировать не десяток полей, а немного больше....



Останнє редагування: 20 листопада 2017 13:27:20 від dmp

Розгорнути попередні цитати...

fam, 20 листопада 2017 12:48:15

dmp, 20 листопада 2017 12:45:55

попробуйте сами понять чем эти ситуации различаются.

ничем, я думаю

ОК, я попробую объяснить, хотя выше ключевое слово уже назвали

Вообще довольно регулярно вижу, что программисты не верят в свои проекты, не задаются вопросом "а что будет если мой проект станет популярным?" Есть ли план что делать, если нагрузка будет резко расти? Пусть сегодня это проект на PHP+MySQL, но принимая то или иное техническое решение всегда полезно задаваться этим вопросом и держать план реагирования на рост под рукой.

Предположим имеем ваш PHP код и сервер базы данных на одном сервере, ну и при модификации базы данных скешировали в файл что-то там. Все работает замечательно.

Но тут вы получаете рост нагрузки. Что делаем первым делом? Логично разнести приложение и базу данных по разным серверам. База данных пыхтит отдельно, кеш с админкой на одном web сервере.

Все пока работает, но нагрузка растет и видно, что PHP приложение не справляется, логично что сделать? Правильно, запускаем еще один web сервер. Уже возникает проблема, файл к кешем создается на одном веб сервере, с админкой, а нужен еще и на втором. Ну вроде не страшно, скопировали файл и живем дальше. Стало немножко неудобно копировать каждый раз после модификации базы данных, но пережить можно.

Нагрузка еще выросла, вы запустили 10 серверов. Копировать файл руками вам надоело и вы стали его при модификации автоматически пихать на сервера. Пришлось немного написать кода, но все ведь работает!

Тут выяснилось, что вы сделали супер сервис и он нужен всем! Нагрузка выросла сильно и вы запустили 100 инстансов веб сервера. С процедурой копирования файла начались сложности, выяснилось, что не все 112 серверов работают одновременно, кто-то перегружается, а кто-то сломался. Выяснилось, что  push работает не очень здорово сам по себе, нужно еще делать запрос конфигурации из какого-то центрального хранилища при старте инстансов и еще как-то это совместить с процедурой деплоя свежих версий приложения.

Фак.

спасибо за информацию. интересно.

одно но - всегда надо быть реалистом и решать задачи, исходя из ВОЗМОЖНЫХ реалий.

или лучше на всякий случай перейти на oracle заранее?

спасибо за информацию. интересно.

одно но - всегда надо быть реалистом и решать задачи, исходя из ВОЗМОЖНЫХ реалий.

или лучше на всякий случай перейти на oracle заранее?

Вы считаете успех вашего проекта невозможным? Так зачем им заниматься?

Oracle - не панацея, он ляжет под нагрузкой как и все остальные, возможно чуть позже, но и дороже.

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

Хорошим вариантом (имхо) является redis.

Вы считаете успех вашего проекта невозможным? Так зачем им заниматься?

я просто знаю, что даже если проекту и суждено стать самым лучшим в мире по своей тематике, то посещаемость вряд ли когда -то достигнет 20К/день

Если ваш проект станет на столько популярным у вас будут ресурсы решать возникающие задачи, проектов которые реально могут перерасти возможности обычного PostgreSQL на максимально заряженном серваке от обычного вендора аля SuperMicro реально немного.

Засіб

Прекрасно можно на PHP/Hack писать большие проекты с красивым кодом и гавно кода на Python, Ruby, JS
написано тож не мало.

Розгорнути попередні цитати...

fam, 20 листопада 2017 11:27:37

Alexey Checkin3, 20 листопада 2017 11:23:39

опыта лет через 5 ты согласишься с теми, кто писал что ты не тем занимаешься А может и раньше.

выше я об опыте писал. Не обольщаюсь, но уверен, что некоторые советы даны теми, ктот родился на свет в пределах этого опыта.

просто обычно все должно быть максимально просто, дабы легко разобраться в последствии в том числе другому челу. У тебя уже есть база, вот там стоило и хранить. Исключений в таком случае обычно мало (типа требования заказчика). Никаких проблем при хранении этого твоего добра в базе - не возникало, кроме мифической дополнительной нагрузки на базу

Ладно короче, по второму кругу идем, бросаю

Чечкин, Вы правы. В том, что надо все держать в базе. ПризнаЮ.

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

в фреймворке это никак не выходило, хотя облазил соотв. обсуждения (но, может, и проглядел что-то, допускаю).

нужен был, фактически, аналог константы, типа определенной с помощью define('ABC', 'la-ala.....').

и только сейчас, решив еще раз подумать над рекомендациями, допер сделать в конструкторе контроллера простое, как колумбово яйцо: define ('MYFUCKUNGDATA', $this->MCommon->ExtractMyFuckingDat aFomMySQL());

фсё.

теперь могу обращаться к этому делу, откуда угодно - в контроллере, модели, представлении, и т.д. без дополнительных операций.

спасибо.