we have a system written in PHP stored on the production server. We have APC installed also.
Our system uses a special local repository on Mercurial and is periodically updated - some scripts are modified by developers, according to customer demands.
But as far as I understand, the APC cache will store the old versions of the files being modified? Does this mean, that the process of updating should look like this:
Pull the latest changes from repository.
Update the system.
Execute
the script in order to force APC clear it's cache.
I ask this because I don't understand the mechanism that APC uses. Does it calculate a checksum in order to see, if the scripts have been updated? Or it cannot handle such a situation and I will have to clear cache manually?
APC will by default check file for changes and update automatically.
No need to do anything manual.
On very high traffic apps It is possible to set it not to check for file changes but the time it takes APC to do the test is negligible so its probably not what you need.
Related
I wonder if there is a good way of deploying database changes made on a typo3 website (on dev) to a live website?
In Magento for example there are folders containg sql install statements (for the structure, new tables etc.) and data install scripts (inserting data into the tables).
These scripts are automatically executed when deployed to live.
Good ways of getting rid of manual database adaptions are welcome.
Thanks!
cweiske explained it well, for common admin it's enough to know that Install Tool has Database Analyser > Compare functionality, which is dedicated for handling DB schema differences.
TYPO3 extensions have their ext_tables.sql files which define the database structure they need.
When installing the extension, the necessary database structure changes are made by the TYPO3 extension manager. You can also apply the changes yourself by using the install tool -> database update.
So as long as your extensions have the correct table definitions, you're fine and can rely on TYPO3 to update the actual database.
A merge from a feature branch to trunk took over 45 minutes to complete.
The merge included a whole lot of jars (~250MB), however, when I did it on the server with the file:// protocol the process took less than 30 seconds.
SVN is being served up by Apache over https.
The version of SVN on the server is
svn, version 1.6.12 (r955767)
compiled Sep 3 2013, 17:49:49
My local version is
svn, version 1.7.7 (r1393599)
compiled Oct 8 2012, 20:42:17
On checking the Apache logs I made over 10k requests and apparently each of these requests went through an authentication layer.
Is there a way to configure the server so that it caches the credentials for a period and doesn't make so many authentication requests?
I guess the tricky part is making sure the credentials are only cached for the life of single svn 'request'. If svn merge makes lots of unique individual https requests, how would you determine how long to store the credential for without adding potential security holes?
First of all I'd strongly suggest you upgrade the server to a 1.7 or 1.8 versions since 1.7 and newer servers support an updated version of the protocol that requires fewer requests for many actions.
Second, if you're using path based authorization you probably want SVNPathAuthz short_circuit in your configuration. Without this for secondary paths (i.e. paths not in the request URI) as may happen for many recursive requests (especially log) when the authorization for those paths are run it runs back through the entire Apache httpd authentication infrastructure. With the setting instead of running the entire authentication/authorization infrastructure for httpd, we simply ask mod_authz_svn to authorize the action against the path. Running through the entire httpd infrastructure can be especially painful if you're using LDAP and it needs to go back to the LDAP server to check credentials. The only reason not to use the short_circuit setting is if you have some other authentication module that depends on the path, I've yet to see an actual setup like this in the wild though.
Finally, if you are using LDAP then I suggest you configure the caching of credentials since this can greatly speed up authentication. Apache httpd provides the mod_ldap module for this and suggest you read the documentation for it.
If you provide more details of the server side setup I might be able to give more tailored suggestions.
The comments suggesting that you not put jars in the repository are valuable, but with some configuration improvements you can help resolve some of your slowness anyway.
The merge included a whole lot of jars (~250MB)
That's your problem! If you go through your network via http://, you have to send those jars via http://, and that can be painfully slow. You can increase the cache size of Apache httpd, or you can setup a parallel svn:// server, but you're still sending 1/4 gigabyte of jars through the network. It's why file:// was so much faster.
You should not be storing jars in your Subversion repository. Here's why:
Version control gives you a lot of power:
It helps you merge differences between branches
It helps you follow the changes taking place.
It helps identify a particular change and why a particular change took place.
Storing binary files like jars provide you none of that. You can't merge binary files, and you can't track their changes.
Not only that, but version control systems usually use diffs to track changes. This saves a lot of space. Imagine a 1 kilobyte text file. In 5 revisions, six lines are changed. Instead of taking up 6K of space, only 1K plus those six changes are stored.
When you store a jar, and then a new version of that jar, you can't easily do a diff, and since jar format is zip, you can't really compress them either, store five versions of a jar in Subversion, and you store pretty close to five times the size of that jar. If a jar file is 10K, you're storing 50K of space for that jar.
So, not only are jar files taking up a lot of space, and they don't give you any power in storage, they can quickly take over your repository. I've seen sites where over 90% of a 8 gigabyte repository is nothing but compiled code and third party jars. And, the useful life of these binary files is really quite limited too. So, in these places, 80% of their Subversion repository is wasted space.
Even worse, you tend to lose where you got that jar, and what is in it. When users put in a jar called commons-beans.jar, I don't know what version that jar is, whether that jar was built by someone, and whether it was somehow munged by that person. I've see users merge two separate jars into a single jar for ease of use. If someone calls that jar commmons-beanutils-1.5.jar because it was version 1.5, it's very likely that someone will update it to version 1.7, but not change the name. (It would affect the build, you have to add and delete, there is always some reason).
So, there's a massive amount of wasted space with little benefit and almost no information. Storing jars is just plain bad news.
But your build needs jars! What should you do?
Get a jar repository like Nexus or Artifactory. Both of these repository managers are free and open source.
Once you store your jars in there, you can fetch the revision of the jar you want either through Maven, Gradel, or if you use Ant and want to keep your Ant build system, Ivy. You can also, if you don't feel like being that fancy, fetch the jars via an Ant <get/> task. If you use Jenkins, Jenkins can easily deploy the built jars for other projects to use in your Maven repository.
So, get rid of the jars. Merging will then be a simple diff between text files. Merging branches will be much quicker, and less information has to be sent over the network. If you don't want to switch to Maven, then use Ivy, or simply update your builds with the <wget> task to fetch the jars and the versions you need.
I have a wordpress mu-site. I need to set up a test-version of it so that the client can run test on the changes we make, test the plugins with new updates etc.
Anybody who has worked with wordpress know it's a bit off a hassle to move between servers and/or domain-names, due to the absolute paths used. Does anybody have a good solution how to create a stage-enviorment of wordpress?
Here's how I do it + some adjustments I want to make:
Two WP installs on identical environments - dev & production
They each have their own FQDN
Version control (SVN in this case) to handle merges from dev to production
When merging, I don't ever merge database changes. I only merge code, and modify any of the domain specific things during the merge (which really should only be in the DB.)
Recreate any DB changes needed during deployment
There are other ways to do it, but they often require changing the hosts file or access to internal systems. So if you want to be able to show an external client a site, then those methods aren't likely to work.
I also sometimes copy the DB back from production to dev, and just do a find & replace for the FQDN.
You can also dev locally and use the above listed method for staging only.
I want to set up a production and development environment for a wordpress website. The Wordpress site uses a lot of plugins. These plugins consist of php files which I upload to a directory within the main wordpress directory.
When activating and modifying the plugins, much of the configurations are stored in the mysql database. Developing on wordpress means much of my "code" and "changes" are stored in the database, as opposed to physical files that can be committed to and updated from a CVS repository. So instead of having a CVS keep track of my changes, I have to frequently and manually do mysqldumps of the database on production and import it into the development server.
Is there a better way to set up a development and production environment where much of the development changes are happening in the database?
Use CVS's hooks to perform the dump whenever you commit. I'm not familiar with how CVS does them, since I've only done it with SVN. However, from reading a bit of the manual, it seems pretty similar.
This section of the CVS manual explains what happens, script-wise, when you commit. Take a look at the section further down, "C.4.4.2 Keeping a checked out copy". You should be able to modify this example to put in your mysqldump command.
I would like to make a complete backup of my whole joomla 1.5 based site from time to time. How would this ideally be done? Are there any common pitfalls? Not that I only have ftp access to the hosting server. Is there a step by step tutorial somewhere? I am using latest Joomgallery and Kunena 1.0.9 (Legacy mode).
Maybe there is a good way to automate this?
There's two parts of the backup you have to worry about, the database and the files.
The first part is the database. It can be backed up using something like phpMyAdmin. If you don't have this available on your server already, it's not too hard to upload and get it going yourself. From there, you can just Export the entire database to a gzip file.
The second part is the code and uploaded files. The code base shouldn't change too often, so you could probably just make one backup of this. There's a number of ways. The simplest is to just download the entire folder via FTP, though if you're Linux, I'm sure someone will know a single command line to get all the changed files (rsync?).
The database is the main thing you have to worry about though: everything else should be able to be rebuilt just by reinstalling.
I think this: http://www.joomlapack.net/ is what you need. I use it myself and it works like a charm. Both for backups and for moving my Joomla installations from developer sites and to the real site.
get an FTP synchronisation tool and keep an up-to-date copy of your site locally. Then you could run the batch script
mysqldump -hhost -uuser -p%1 schema > C:\backup.sql
to create a backup of your mysql tables at various points in time.
edit
you would have to have MySQL Server installed on your local machine and path to its bin directory in you PATH, in order to run the mysqldump command without much hassle. -p%1 would take the command-line provided password, as you wouldn't want to store passwords in your batch script.
If you only have FTP access you are in a bit of a problem, as beside all files you'll also have to backup the database. Without accessing the database, a full-backup won't do you any good.
Whatever backup strategy you choose - be sure it can handle UTF-8 correctly. Joomla 1.5 stores all content with UTF-8, even when the database charset is set on 'iso-5589-1' - so when the backup solution is detecting the database charset, some characters like € or é will result in "strange" ¬ / é - not really what you'll want.
I absolutely endorse using Joomlapack - it works great. The optional remote tools allow you to initiate the backup from a Windows desktop machine - it performs the backup and downloads it. The remote has a scheduler, and you can also set it off to backup and download a list of sites.
Joomlapack also provides a file "kickstart.php" which you copy to your empty server account along with the backup, which automates the restore procedure. You do have to create an empty database with PHPMyAdmin or similar, and you are given the opportunity to supply the database parameters (host, database, username, password) during the process.
One pitfall I did run into with this though is that some common components can have absolute URLs in their configuration - e.g. SOBI2, Virtuemart. It's then just a matter of finding the appropriate configuration file, editing it and re-uploading it.
Another problem was one archive file (either ZIP or their JPA format) got a filename with a "?" character in it (from a Linux server) and this caused a bit of a problem trying to install it locally on a Windows WAMP stack - the extract process on the ZIP file failed, and it stopped the process completing cleanly.
I suggest using automatic backup service by http://www.everlive.net
Update:
Ok, here is some more information. EverLive.net is a website where you can create a free account. Enter your website details and you are ready to take your backups withe just one click. Restore is also possible in the same way.
Further you can use automatic backup option to take automatic backups at defined intervals. Other than that, you can use the website health check service to inform you if your website is not available.