So unfortunately I'm a newbie to the application (web) development world. While I did graduate with a CS degree its theory funness hasn't helped out much. However I am trying to jump in feet first. My php application I build is simply sitting on a cheap hosting provider. In order to launch it I'd like to it to be able to scale well (fun buzz word).
However, as I said I'm totally new to it and I suck at git.
So as I've read I'm looking to host the mySql database and the php files on phpfog, my css and images on amazon S3, and then the email server as Amazon SES?
Is this the right frame of mind, and/or will this handle a flurry of (hoped for) traffic?
Thanks!
That's a lot of scaling in mind for just starting out. Keep it simple. Google Apps Standard gives you 10 accounts to work with, and you can a nice GMail interface as a bonus.
Keep your hosting simple for now, you don't need Amazon S3 for CSS and images yet. Silver pricing seems decent for just starting out at PHPFog. Remember you can always increase capacity later on.
Before you say "flurry of traffic", make sure you have a solid business plan. How will you market your product/service? Who are your competitors? What differentiates your product/service? Pretend like you're pitching this to a VC firm.
If you don't have a solid plan to work with, you're throwing too much money at infrastructure that you won't be using.
If you want to learn about the technical aspects of the infrastructure you're choosing, you probably should begin by learning about how it works. http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
will give you a nice overview on how scaling works on AWS and the cloud in general.
Related
In our project we have a front-end part with PHP and Apache, a MySQL database and some Mono servers that do some logic (chat, etc...)
It's all completed but before starting and buy the servers i want know how make them scalable and be fault tollerance. We want buy the servers on So You Start.
How can we proceed? What we must buy (possible cheap)? We thinked about a virtualization but we don't know how move.
Thank you in advance.
Amazon has a lot of very good documentation about how to architect their cloud services. I would suggest you start with a free (for 1 year) Usage Tier for learning AWS and testing your application. The free tier It enables you to setup a Unix and Windows instance as well as RDS (Relational Database Server) and email service. You can later add fail-over servers located in geographically dispersed locations. You can also scale easily by adding (and removing) instances as needed.
Start with this overview.
In AWS you can start small and then use AutoScaling with ELB and cloudfront to really scale up as needed.
http://dailytechscape.com
Recently my Web design firm got a big contract to build a website that will be media rich and needs to run on wordpress. The client wants it so because of the simplicity and familiarity with Wordpress they have.
The hosting will be undoubtedly with AWS EC2, and we are not torn into hosting the actual files on a separate instance or a S3 bucket. I have never worked with S3, but have some 2+ years experience with EC2. Users uploading images, videos, documents,...will be a big component of the website.
ANTICIPATED: Based on the market stydy done by another firm for the client, we expect in the upwards of 1000 unique visitors daily, of whom 5-10% would be uploading on the server/bucket.
AIM: A fast website with that kind of media richess
Any advice as to the choice of the server / infrastructure settings/choices?
Wordpress by default does however store all of its files in the local file system. You can get plugins to allow uploads to be stored in S3. Although with only 1000 uniques, it may not be necessary.
The biggest gain in speed is going to be with using caching systems (preferably caching to memory).
There are many options open to you, but with something like 1000 unique per day, you don't have much to worry about. If you want to take advantage of the CDN part of S3 then:-
Create a bucket in S3, with public CDN options enabled
Mount this bucket using S3 FUSE in Linux -> Guide here
http://juliensimon.blogspot.de/2013/08/howto-aws-mount-s3-buckets-from-linux.html
Ensure memory caching is enabled in Wordpress (W3 Cache)
Minify the CSS and JS files using W3 Cache (careful as this sometimes breaks the themes)
If site is not responsive enough consider using AWS CloudFront or CloudFlare
If the site much be online at all times then consider 2 instances with DNS roundrobin. Keep wordpress Sync'd using rsync. Ensure they both mount the same S3 bucket.
This should be more than enough.
Hope this helps.
1000 visitors a day is not really so large a strain on a server that I'd be too especially worried about it. If it were me, I'd make sure to use caching (like datasage recommended), and also looking into leveraging a CDN, especially since you're dealing with a lot of media. No matter what CDN you use, be it Cloudflare, MaxCDN, VideoPress, Amazon CloudFront, Akamai, or any one of many great content delivery network providers out there, I think you'll get a lot further with that than you will tweaking your server. If you want to do that too, I'd suggest caching and NGINX. Obviously minify CSS and JS too, before you deploy, but that's kinda obvious
I appreciate all the input as the concensus is that 1000 uniques / day is not much of a deal. Check
Need I to mention though that we'll build every single functionality ourselves as a main plugin to fully have control over the features. Many themes nowadays are stuffed with unnecessary junk which doesn't help the case we're trying to make. I will look at StuartB's solution more closely, but I certainly do appreciate all of your inputs.
I'm working on a small private site for a group of 10 people. It's essentially a tiny social network just for us. We currently also use Windows Live Messenger for real-time chatting but we're looking to create an alternative since the MSN clients out there for Mac, Linux and smartphones do not support the recently added group features in MSN, which we use.
I've been reading up a little on push technology to see how I'd go about creating a web based chat room that suits our very limited needs. I gather that Apache is not really suited for long polling at all, and that using something like APE would be a better idea. However, we're running on a fairly cheap but very good shared host so we simply don't have the ability to install any server side software.
To my question.
Since we are, after all, just a handful of users, and most of the time only half of us will be online, is is likely that simple PHP long polling could work? The chat is going to be open pretty much every day from early afternoon to late at night, but not all users will be active all the time. Still, on average probably five or six users will be online without leaving for a whole day, every day. When we're the most active, there will be times when a lot of messages are sent in a short period of time, but it's hard to estimate how many.
Would it be worth looking into the use of Websockets using the PHP server implementation of those and with a Flash fallback (for desktop use we're fine since we all use Chrome, basically, but we'd be happy to be able to use Android devices as well).
I also stumbled upon www.pusher.com and their free alternative looks quite suitable, with 20 connections and 100 000 messages per day (we won't nearly reach that much even in a week). Would you recommend we simply go down that road instead?
I know there are loads of questions here regarding push technology with PHP and Apache, but I haven't found anything addressing a situation where there will be such limited use of the application. Any tips and suggestions would be greatly appreciated. I pretty much know how I'd write the chat itself, I just need to know the best method to use, and if any of the above will work.
I am developing an iPhone app and would like to create some sort of RESTful API so different users of the app can share information/data. To create a community of sorts.
Say my app is some sort of game, and I want the user to be able to post their highscore on a global leaderboard as well as maintain a list of friends and see their scores. My app is nothing like this but it shows the kind of collective information access I need to implement.
The way I could implement this is to set up a PHP and MySQL server and have a php script that interacts with the database and mediates the requests between the DB and each user on the iPhone, by taking a GET request and returning a JSON string.
Is this a good way to do it? Seems to me like using PHP is a slow way to implement this as opposed to say a compiled language. I could be very wrong though. I am trying to keep my hosting bills down because I plan to release the app for free. I do recognise that an implementation that performs better in terms of CPU cycles and RAM usage (e.g. something compiled written in say C#?) might require more expensive hosting solutions than say a LAMP server so might actually end up being more expensive in terms of $/request.
I also want my implementation to be scalable in the rare case that a lot of people start using the app. Does the usage volume shift the performance/$ ratio towards a different implementation? I.e. if I have 1k request/day it might be cheaper to use PHP+MySQL, but 1M requests/day might make using something else cheaper?
To summarise, how would you implement a (fairly simple) remote database that would be accessed remotely using HTTP(S) in order to minimise hosting bills? What kind of hosting solution and what kind of platform/language?
UPDATE: per Karl's suggestion I tried: Ruby (language) + Sinatra (framework) + Heroku (app hosting) + Amazon S3 (static file hosting). To anyone reading this who might have the same dilemma I had, this setup is amazing: effortlessly scalable (to "infinity"), affordable, easy to use. Thanks Karl!
Can't comment on DB specifics yet because I haven't implemented that yet although for my simple query requirements, CouchDB and MongoDB seem like good choices and they are integrated with Heroku.
Have you considered using Sinatra and hosting it on [Heroku]? This is exactly what Sinatra excels at (REST services). And hosting with Heroku may be free, depending on the amount of data you need to store. Just keep all your supporting files (images, javascript, css) on S3. You'll be in the cloud and flying in no time.
This may not fit with your PHP desires, but honestly, it doesn't get any easier than Sinatra.
It comes down to a tradeoff between cost vs experience.
if you have the expertise, I would definitely look into some form of cloud based infrastructure, something like Google App Engine. Which cloud platform you go with depends on what experience you have with different languages (AppEngine only works with Python/Java for e.g). Generally though, scalable cloud based platforms have more "gotchas" and need more know-how, because they are specifically tuned for high-end scalability (and thus require knowledge of enterprise level concepts in some cases).
If you want to be up and running as quickly and simply as possible I would personally go for a CakePHP install. Setup the model data to represent the basic entities you are managing, then use CakePHP's wonderful convention-loving magic to expose CRUD updates on these models with ease!
The technology you use to implement the REST services will have a far less significant impact on performance and hosting costs than the way you use HTTP. Learning to take advantage of HTTP is far more than simply learning how to use GET, PUT, POST and DELETE.
Use whatever server side technology you already know and spend some quality time reading RFC2616. You'll save yourself a ton of time and money.
In your case its database server that's accessed on each request. so even if you have compiled language (say C# or java) it wont matter much (unless you are doing some data transformation or processing).
So DB server have to scale well. here your choice of language and DB should be well configured with host OS.
In short PHP+MySQL is good if you are sending/receiving JSON strings and storing/retrieving in DB with minimum data processing.
next app gets popular and if your app don't require frequent updates to existing data then you can move such data to very high scalable databases like MongoDB (JSON friendly).
In the next few weeks I'll be taking my site from the localhost (WAMP) and puting it on a new server. This will be the first site, on my first server, so basically...i'm a noob!
This must be an important moment for any independent web developer / small business so i'd love to hear about some experiences, mistakes and system default security holes that one should fix straight away...
I'm using php, mysql, cpanel and WHM, and looking for tips like "Turn off error reporting in PHP"
First and foremost if you are worried about security then you should use LAMP. As long as the Linux platform is using AppArmor or SELinux (Ubuntu and fedora respectively), then you are much better off than any version of Windows. I know this from first hand experience of developing exploit code for the two platforms.
Before you lock your system down, test your code for vulnerablites using Wapiti. Acunetix is also good, but expensive. This type of testing, especially sql injection testing must be done with dispaly_errors=On set in your php.ini
There is a lot that can go wrong with PHP Configuration that makes your system less secure. You should run PHPSecInfo and remove all red. dispaly_errors=Off is what you want, and phpsecinfo tests for it.
You should also use a web application firewall like Mod_secuirty.
It's actually quite a huge undertaking, but well worth the experience. Here are just one or two suggestions...
Site security also means being heavily involved in managing your sometimes scarce resources. Just as important is obeying any limits your host has, and guessing all possible ways your site users can push you over those limits, leaving you responsible to pay a hefty bill. IE downloading or uploading large files over and over, spamming email lists, repeatedly requesting pages using too many database connections and queries, etc. Get overusage limits and fees in writing from your host before you begin, and have response plans ready. Really, this part is like buying a cellphone service.
A lot would also depend on what features you'll have on your site. File uploads? Forum? Logins? Email? Etc? For example - If you're running a file-sharing site: along with upload/download rate limiting, I suggest you first check available disk space before permitting any file to be uploaded, or do regular audits so you're prepared to archive or delete old and unused files. It's a quick check just to make sure you're not caught by surprise a year down the road when you suddenly start getting disk full errors or get shafted by your host with a large bill.
There are literally a hundred more issues to consider. Gather up a complete overview - an itemized list - of all features and functions of your site. Google each one to get more ideas on handling security. Your host should also publish their own security considerations and have a handy manual for operating with all of their services. If they don't, well, I wouldn't personally feel comfortable with them.