ЖЖ-логия: опять проблемы
Nov. 4th, 2001 01:34 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaКомменты не работают, ага. И вообще все страницы, кончающиеся на .bml. А всё остальное работает вроде.
Всё, без запасного администратора где-нибудь в европейских часовых зонах нельзя больше жить. Постараюсь изо всех сил Брада в этом убедить, когда он проснётся.
P.S. Прогноз такой: комменты не будут работать примерно следующие 7 часов. Потом заработает всё.
Всё, без запасного администратора где-нибудь в европейских часовых зонах нельзя больше жить. Постараюсь изо всех сил Брада в этом убедить, когда он проснётся.
P.S. Прогноз такой: комменты не будут работать примерно следующие 7 часов. Потом заработает всё.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2001-11-04 11:20 am (UTC)Âñå ýòè ìåðû ñ äåæóðíûìè àäìèíàìè è äîïîëíèòåëüíûìè ñåðâåðàìè, ïî-ìîåìó, òîëüêî ðàñòÿãèâàþò àãîíèþ. Ìíå êàæåòñÿ, ðàçóìíûì âûõîäîì áûë áû ïåðåõîä ê ñèëüíî ðàñïðåäåëåííîé ñõåìå -- äåéñòâèå, àíàëîãè÷íîå òîìó, êîòîðîå ïðèâåëî äðåâíèå ÷àòñåðâåðà ê ïðåâðàùåíèþ â irc-ñåòè.
Âîïðîñ, ñîáñòâåííî, òàêîé -- core team ýòó èäåþ âîîáùå ðàññìàòðèâàåò?
no subject
Date: 2001-11-04 01:09 pm (UTC)no subject
Date: 2001-11-04 01:18 pm (UTC)no subject
Date: 2001-11-04 01:45 pm (UTC)no subject
Date: 2001-11-04 02:20 pm (UTC)no subject
Date: 2001-11-04 09:30 pm (UTC)no subject
Date: 2001-11-04 01:28 pm (UTC)no subject
Date: 2001-11-04 01:35 pm (UTC)no subject
Date: 2001-11-04 01:36 pm (UTC)Re:
Date: 2001-11-04 01:37 pm (UTC)no subject
Date: 2001-11-04 01:39 pm (UTC)no subject
Date: 2001-11-04 02:13 pm (UTC)I mean, it probably makes sense to go public, and to develop kinda open standard or something, at least for the network protocols in use. I also suppose it will require a complete redesign of the engine, like from scratch. And i think that the best way to develop this new engine is to go public either. From what i can
see, the existing livejournal development team is busy enough just keeping the thing alive. Thus, to build an open development community seems to be the only option.
My suggestion is to create some sort of discussion group where we could work out the specification for the new engine and the protocols, and then, when the specs are basically ready, we could just use the usual open source development model -- contributors, committers, etc.
Why not right now, I mean. LJ is already quite unstable and unreliable, and i'm afraid it's gonna be only worse.
Re:
Date: 2001-11-04 02:27 pm (UTC)no subject
Date: 2001-11-04 02:36 pm (UTC)no subject
Date: 2001-11-04 04:33 pm (UTC)I'm willing to come and contribute, at least to the issue mentioned above -- because i don't see how the project is going to survive without some really comprehensive distributed processing capability. For me, the main question is the core team policy about the issue. I can do my best to design server-to-server protocols and new engine architecture, but what is the core team opinion about it? If they are not going to implement these protocols, protocols are useless. If they are not going to comment real heavy on the supposed protocol specifications and new engine architecture, it's mostly useless too. If, for example, they are not going to split current or future user base between the existing servers and the new remote ones, the whole idea of new protocols/engines is absolutely useless.
That's why i'm asking, and that's, generally, what i'm asking about. What do you, guys, think about it? Please.
no subject
Date: 2001-11-04 04:48 pm (UTC)Can you present more clearly your vision of what a distributed platform means, in context of LJ?
Let's try to keep separate two different applications of distribution, so as to avoid confusion (as I've been trying to do in our philosophical discussions, and I apologise, BTW, for neglecting them somewhat during the last few days ;)):
1. Distribution to lighten the load off servers.
2. Distribution to enable very different kinds of LJ-code-based entities to interoperate.
What's different is the intent: in the first case the intent is to allow the main LJ site to grow, in the second it's to allow all kinds of LJ-code-based sites (not affiliated with lj.com, just using the open-source LJ code) to interoperate, use each other's users in friends views, etc.
The second kind is what Brad and I were talking about. You seem to focus on the first kind, I think: complete distribution and independence of LJ servers from each other is necessary to survival of LJ, in your opinion.
It may be true, but I don't see that as self-evident, currently. As you probably know, LJ *is* employing a lot of distribution currently, distributing database access over many servers and web access over many more servers. It's true that this distribution is not complete, i.e. there's a single database and there's a master machine holding all of it. But the master machine is not a bottleneck and historically hasn't been; almost all the problems LJ faced were *not* due to traffic or access bottleneck on the master machine. They were usually over replication issues, or web slave failures, etc.; stuff that can fail just as well if you have completely independent servers (since they still will have to replicate/share information, and web servers will still fail sometimes or be overloaded).
So, can you be more specific about what you see as necessary, in light of the above?
no subject
Date: 2001-11-04 05:32 pm (UTC)Tew, nevermind :) That's always very interesting but rarely deadly urgent.
1. Distribution to lighten the load off servers.
2. Distribution to enable very different kinds of LJ-code-based entities to interoperate.
...
You seem to focus on the first kind, I think: complete distribution and independence of LJ servers from each other is necessary to survival of LJ, in your opinion.
That's right, that's what i think.
It may be true, but I don't see that as self-evident, currently. As you probably know, LJ *is* employing a lot of distribution currently, distributing database access over many servers and web access over many more servers.
Yeah, i know that.
But the master machine is not a bottleneck and historically hasn't been; almost all the problems LJ faced were *not* due to traffic or access bottleneck on the master machine. They were usually over replication issues, or web slave failures, etc.; stuff that can fail just as well if you have completely independent servers (since they still will have to replicate/share information, and web servers will still fail
sometimes or be overloaded).
You already have probably tens of boxes running web frontends, right? If the things are going to develop the way they currently do, master machine will eventually become a bottleneck. The same tendency about traffic and everything. I mean, on the long enought time scale every singularity (like master server) will become a bottle neck.
Actually, i think that webslave failures also mean a bottleneck of some special kind: there probably *too many* webslaves, and thus they are harder to control perfectly. If, in other hand, we could have a bunch of relatively independent serving locations, under different authorities and stuff, each of these (smaller) locations would be much easier to control and maintain.
Probably i also should mention another kind of bottleneck situation: like a power failure or even planned maintenance procedures.
no subject
Date: 2001-11-04 10:37 pm (UTC)1. Slave mysql servers are unstable under the heavy load of sql requests ("select"s).
2. Frontend webservers run out of cpu || ram || maxproc || file descriptors while parsing sql replies and processing templates.