The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register. September 19, 2019, 01:50:33 PM

Login with username, password and session length


Pages: [1]
  Print  
Author Topic: how to centralize class/scripts?  (Read 3941 times)
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« on: June 14, 2009, 07:26:57 PM »

I have been trying to figure something out.

I have 1 script used in many places. Or a class in many places.

i was trying to figure out a way to centralize it so that either everything uses the same 1 file, which of course could be via include to a "core" directory. Or, push updates. or pull updates on a schedule. or even store in a DB???

of course if all the websites reside on 1 box, the core-include directory works fine, but that does not scale (though to push updates to a few boxes is not a big deal).
Pushing means managing logins.
pulling means grabbing updates and having a potential external security hole.
pulling from a database, realtime, and only having a simple database query function that is distributed to each site sounds interesting, but dumb at the same time.

I am guessing core-directory is the best route? opinions?
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #1 on: June 14, 2009, 08:07:22 PM »

For my stuff I have an Apache instance that does NOT have PHP installed listening on a special port. Other machines can then call for things and they get the source delivered. A special script runs on the box and keeps a LUPDATE list on all files (also downloadable), so a slave can call for the lupdate file and compare against itself, then grab anything that is out of date. CRONd, runs once a minute. This is all behind my wall.

Outside a wall: Add a ringback ping with a table of acceptable clients, all done. Use either a mod_rewrite lookup table or simple regex in the httpd.conf and you've got what you need.

This of course makes an excellent addition to the DB plan you were discussing in the other thread.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #2 on: June 14, 2009, 08:26:51 PM »

i do the ringback on my remote nodes for me bh stuff.
but im thinking i will keep this simpler.

Since I really am going to only have 1 live webserver (at least for the foreseeable future) I can just do the common directory.
I can even then make those scripts accessible to clients readonly.


I think thats how I am going to go for now. I was mostly talking outloud to think it through.

as you can probably tell from my recent posts, i am in the middle of restructuring.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
kurdt
Lifer
*****
Offline Offline

Posts: 1153


paha arkkitehti


View Profile
« Reply #3 on: June 15, 2009, 12:13:13 AM »

You call that simple? Wink

My simple setup is this:
One central server
One fetcher script that runs every hour

I never thought of that non-PHP server with specific port. That's pretty nice actually. But with that solution you absolutely must use access tables and with my Linux knowledge that's a bit out of reach, for now. Would it be possible to use virtualhosts for this? But wouldn't it be the same thing if you would just save php files with some random extension? That way you could actually have PHP on the box Smiley I gotta check out what that LUPDATE does and what the hell is ringback.. this technical side is getting more and more time consuming Sad
Logged

I met god and he had nothing to say to me.
netmktg
Rookie
**
Offline Offline

Posts: 37



View Profile
« Reply #4 on: June 15, 2009, 12:23:42 AM »

But wouldn't it be the same thing if you would just save php files with some random extension?

That's exactly the first thing that came to my mind, but you beat me to it  Nerd
Logged
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #5 on: June 15, 2009, 06:18:56 AM »

I have a system class with a static method that calls and evals code from a DB for my really really common functions and my framework. bootstrapper or something.
Logged

hai
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #6 on: June 15, 2009, 06:33:24 AM »

I never thought of that non-PHP server with specific port. That's pretty nice actually. But with that solution you absolutely must use access tables and with my Linux knowledge that's a bit out of reach, for now.
No access tables - just a little regex to decide if I like the calling remote IP or not (in the httpd.conf, but could just as easily be done in an .htaccess) - it's way less tough than you think. If you'd like, I'll post an example.

...wouldn't it be the same thing if you would just save php files with some random extension?
Yes, but then you'd need to do some interpretation of the filename, which I fought to avoid. Essentially, my slave updater is a very simple app that simply looks at things on <this box> against a list of things on <that box> and if they are different, calls for them and stores them locally. No interpretation at all.

I gotta check out what that LUPDATE does and what the hell is ringback...
I used LUPDATE in capitals simply so that Nuts would know what I was talking about. I use the mtime of a file to keep a lupdate list - then if the local mtime is < the server mtime, I need to get it. Commonly called a last update, I personally have used lupdate for a long time.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #7 on: June 15, 2009, 06:35:11 AM »

I have a system class with a static method that calls and evals code from a DB for my really really common functions and my framework. bootstrapper or something.

This is extraordinarily powerful, but also eliminates all potential benefit of APC caching and therefore, keeps PHP running at its unfastest pace. I try to eval absolutely as little as possible, instead choosing to include and require as much as possible to keep things dynamic and pre-compiled.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #8 on: June 15, 2009, 08:36:32 AM »

I have a system class with a static method that calls and evals code from a DB for my really really common functions and my framework. bootstrapper or something.

This is extraordinarily powerful, but also eliminates all potential benefit of APC caching and therefore, keeps PHP running at its unfastest pace. I try to eval absolutely as little as possible, instead choosing to include and require as much as possible to keep things dynamic and pre-compiled.

Pfft.

I see your leave-it-to-APC ways and raise you an "I'll take care of that myself, thanks."
http://us2.php.net/bcompiler

EDIT: my framework bootstrapped loader takes care of all the intermediary talking. I don't have to know what's cached where or why, I call the static method to load up a module and it knows what it's supposed to do.
Logged

hai
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #9 on: June 15, 2009, 09:50:17 AM »

Actually, compiled apps bug me.

The problem for me is the monolithic nature of a single compiled application. Everything that the app must know to run the entire show either must be compiled in, or loaded on the fly, or loaded at instantiation or or or ... I hate that. One of the things that attracted me to JBoss, Java and an EJB platform for a bit was the spontaneous notion of "no app" and instantaneous re-linking - the ability to create a brand new application on the fly that was already compiled, it just needed to be linked.

APC does this for me. Rather than the notion of Compiling The Application, I script and compilation is done in little pieces that are then recombined into any form of application I need on the fly. The net result is tiny page-specific apps that need to load/read very little, are very light and supre fast, and of single thrust or notion. Debugging is a breeze because there is literally, only the code required for (this page) in the application that is running. In fact, the very notion of a cohesive website is a facade - my applications literally produce a single page. They just happen to look so much alike that users think it's a single website Smiley

My previous framework is a single compiled app that exhibits the very things I rail against. 200K lines of code that know every single thing the "website" must know to operate correctly. Although beautiful from one perspective, it's a horrible pig from another. It has a huge bootstrapper/loader that does exactly what you're talking about and I hate it. It's also bad from a real performance perspective. I can't have a thousand instances of it running on a machine because there's just not enough memory or efficiency there. I've gotten a HUGE increase in both throughput, speed and raw machine capability through this little script/APC method.

Best yet: when I change something, rather than recompiling, APC notices that the mtime on the script is off with the object code, so it's recompiled the next time it's called - another one of the big benefits of the JBoss platform, brought to PHP. So I don't ever need to compile - if something is out of date it's recompiled for me. And (and here is a BIG and...) when I mess with something, it only messes THAT ONE THING up - the essence of OO coding for me. I can't tell you how many times I've seen a compiler fuck up, or a linker crash - and the ratio goes up dramatically with the size and complexity of the application.

Nope, compiled apps just don't work for me anymore.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #10 on: June 15, 2009, 10:45:35 AM »

That's what I do too.

APC compiles the stuff you need cached to bytecode. I just control the pieces that get compiled instead of letting APC control it.
Logged

hai
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #11 on: June 15, 2009, 01:59:10 PM »

Do you then do something as well to keep the bytecode live in memory? Because that's one of the major highlights as well: with APC the bytecode is live and ready to be linked in RAM all the time, rather even than an app that is compiled but must be instantiated.

Why does it bug you that APC handles compiling/caching? I'm not sure I see any benefit to doing that myself (and you know me, Mr. Configure/Make/Make Install Wink ) ... I don't see how controlling the compile link cycle in this instance gives me any more throughput or raw capability ... ?
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #12 on: June 16, 2009, 06:03:44 AM »

I don't care about controlling the caching, it's a necessity to make things work the way I wanted.

I wanted to be able to rapidly deploy an app to nearly any environment, and my clients and I have quite the mixed bag. I couldn't do APC because like I mentioned earlier, I bootstrap the framework from a remote database at runtime. Basically I'm just caching parts of the framework, and I just assigned it which parts to cache, etc. The stuff that has to be checked and/or dynamically built every time can't really be cached or it needs a short TTL.

Anyway, once compiled to bytecode the really heavyweight stuff that gets called all the time (my database comm layer class, for example) gets cached with memcached. The TTL on those pieces of eight is about 2 days.
Logged

hai
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #13 on: June 16, 2009, 08:01:10 AM »

memcached is also really powerful, I like it a lot. Before APC I used it as well.

Sounds like our requirements are drastically different which would explain a lot.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
Pages: [1]
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!